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