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.
(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, 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.
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.
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!
As you can no doubt deduce, I'm NOT a fan of unnecessarily long path
names. =:^)
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 /.
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.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
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.
