Another case of WONTFIX

gene heskett gheskett at
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:
> > 
> > <>
> > 
> > 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.

> > 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.


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)
A journey of a thousand miles begins with a cash advance.
This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list