Another case of WONTFIX
gheskett at wdtv.com
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
> > 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):
> 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.
"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: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde