Another case of WONTFIX

Wed Apr 13 00:06:45 BST 2011

On Tuesday, April 12, 2011 06:51:52 PM Duncan did opine:

> gene heskett posted on Tue, 12 Apr 2011 10:02:39 -0400 as excerpted:
> > A friend on another unrelated mailing list just posted this link:
> > 
> > <http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken>
> > 
> > Which tells me that having /usr on a separate partition, as most of us
> > oldtimers do that have been victims of LVM and had a system demolished
> > by its total lack of recovery tools does.
> 
> FWIW, not everyone's switching to systemd just yet.  Gentoo isn't.  It
> appears Fedora (so probably RedHat eventually) and OpenSuSE are, and
> Ubuntu, but I'm not sure about Debian itself or Arch, and Slackware
> strikes me as conservative enough to probably not be switching
> immediately, either.
> 
> Meanwhile, the device-mapper portion of the LVM package (and the related
> kernel options) does seem to be required now as a dependency of udisks,
> the automount component successor to hal, and kde4, from 4.6 which
> switched from hal, uses it for the device notifier, etc, but that does
> NOT mean the LVM side has to be used, and in fact, traditionalists
> like you and me probably aren't terribly unhappy to see automount
> functionality break in any case.  I know I'm not, altho it can be
> convenient for optical, but I actually prefer it stay off for USB
> connected thumb-drives and disks, etc.  FWIW, I build my own kernel
> and have felt no compunction to turn on device-mapper there yet, so
> user-space dependency or not, anything requiring the kernel side is
> simply broken on my system, and that's likely to remain the case for
> awhile.
> 
> > Now, while I hate to do it, it looks like I may be forced to put /usr
> > back on / at my next install.
> > 
> > My present system gives a df output of:
> > [root at coyote sbin]# df
> > Filesystem            Size  Used Avail Use% Mounted on
> > /dev/sda8              29G  7.2G   21G  27% /
> > /dev/sda1             395M  314M   62M  84% /boot
> > /dev/sda5              29G   18G   12G  62% /home
> > /dev/sda3              97G   12G   80G  13% /opt
> > /dev/sda6              29G  215M   28G   1% /root
> > /dev/sda9              29G  237M   28G   1% /tmp
> > /dev/sda10            673G   48G  591G   8% /usr
> > /dev/sda7              29G  9.3G   19G  34% /var
> > /dev/sdc1             917G  478G  393G  55% /amandatapes
> 
> FWIW (optional runtime md/raids turned off and their filesystems,
> including /boot, unmounted):
> 
> $>>df
> Filesystem            Size  Used Avail Use% Mounted on
> rootfs                4.8G  2.9G  2.0G  60% /
> /dev/root             4.8G  2.9G  2.0G  60% /
> rc-svcdir             1.0M   80K  944K   8% /lib64/rc/init.d
> /dev                  2.0M  456K  1.6M  23% /dev
> shm                    20M     0   20M   0% /dev/shm
> /dev/md3p2            256M   45M  212M  18% /l
> /dev/md4               16G   11G  5.2G  68% /h
> /dev/md7p1            1.0G  109M  916M  11% /lg
> /dev/md7p2             12G  1.6G   11G  13% /nw
> /tmp                  6.0G   12K  6.0G   1% /tmp
> 
> > My question for this list is:  Could this be the root cause of all my
> > kde4 configuration losses at reboot time?
> 
> Unlikely.  By the time x/kde comes up, /usr and etc should be solidly
> functional and appear as just another part of the filesystem tree.
> 
That was also my reasoning, but the starving man will gladly steal the 
straw that is supposed to break the camels back.

> (I say unlikely because as you can see, I don't have /usr mounted
> separately here.  Tho subdirs such as /usr/local are -- it's a the /l
> mount above, with a symlink from /usr/local, and /usr/src is similarly a
> symlink, tho into an optional partition on an md/raid-0 which isn't
> active in the above.  But /usr/share, a critical kde component, is on /
> itself, as is anything that the package-manager installs stuff to (as I
> mentioned earlier).)

And (/usr) which IS on a separate partition here.  But rsync is busily 
copying stuff about as we "speak". 

> > And, could the separate /home also have something to do with this, for
> > the same reason?
> 
> Absolutely not.  *WAY* too many distros support if not default to a
> separate /home.

My feelings too.  But the fedoras have virtually insisted /usr be on /, 
which is one of the reason I finally packed my bags and moved to pclos.

> I have a separate /home here too.  (Again, /h above, symlinked from
> /home just in case...)  I suspect I've had occasional minor problems as
> a result, mostly related to early failures with k-get-hot-new-stuff
> (the kde extension that allows downloading additional plasmoids, for
> instance, from kde-look), but those are bugs and are eventually fixed
> -- by 4.5 the problems with KGHNS were gone.

Good.

> > The above is another non-negotiable item, just like /var which is
> > separated and will remain so as long as the logs are on it.
> > 
> > One possible fix might be to mount a 'log' partition at /var/log, but
> > would not the read-only status in case things go tits down in the deep
> > end of the pool, carry over and lock the system out of writing logs in
> > this scenario? That needs an authoritative answer, because I might
> > just go so far as to put it on a separate drive although that
> > multiplies my failed drive exposure to do so.
> 
> The separate /var vs /var/log we discussed earlier.  Bottom line,
> assuming reasonable sizing, you're very unlikely to have any problems
> with a separate /var/log that you don't already have with a separate
> /var.  A possible exception might be most-likely-local scripts that
> rename (instead of moving, rename assumes same filesystem) logs in
> /var/log to a backup location under /var but not under /var/log, as
> part of some logrotate scheme.  But that being most likely a local
> solution (too many people have a separate /var/log for it to remain
> long as a community-wide solution), you'd deal with it locally.

Generally.  I haven't been at all bashful about calling vim to work over a 
logrotate script for almost that same reason, plus I've added to them to 
rotate the logs of some of the stuffs I run for convenience, like fetchmail 
and procmail, neither of which install their own log rotation scripts.

> FWIW, again, the /lg listed above is symlinked from /var/log.  If
> there were problems with a separate /var/log, the fact that it's
> a symlink here wouldn't make them less complex, for sure!

Agreed, although I can't say that I've ever had a problem with ln or lndir 
in that regard.  It Just Works(TM).

> As you can no doubt deduce, I'm NOT a fan of unnecessarily long path
> names. =:^)

Neither am I, but my /usr/pix dir, or /usr/movies, would call me a liar. :) 

> But if anything's going to cause problems, those symlinks IN ADDITION TO
> separate mount-points should do so, and they work well enough that I've
> been using that config for some years, here.  Tho as I said I can't
> be sure for /usr itself since here, it's on /.

And is going to be so here by this time tomorrow unless taxes & CWP renewal 
wipe out the day.

> Of course, I'm running Gentoo, not the ordinary binary distribution I
> seem to recall you saying you use.  It's possible there's some
> distro-specific bits that may cause issues, but little or nothing kde
> related as shipped from kde-upstream, the main concern on this list.

Good.

Thanks Duncan, and dinner is ready I hear from the other end of the house.   
And you can call me a lot of things as long as its not too late for dinner. 
;-)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<http://tinyurl.com/ddg5bz>
<http://www.cantrip.org/gatto.html>
A journey of a thousand miles begins with a cash advance.
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.