Another case of WONTFIX

Tue Apr 12 23:20:10 BST 2011

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.

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