Distribution quote of the week

[Posted December 7, 2011 by ris]

Give everyone at least 10 years headstart to migrate existing systems away from having a separate /usr partition and for people to stop making a separate /usr on new installs.

If you do this in Debian now a large portion of systems will self destruct because /usr is a separate partition and you will be tarred and feathered.

-- Goswin von Brederlow

I can see that the US Thanksgiving holiday is over and people are gearing up for various end of the year holidays.. the email volume of patches and such have gone up. Thankfully most of the arguments seem to have gone down for a while.

-- Stephen Smoogen

to post comments

Distribution quote of the week

Posted Dec 8, 2011 5:04 UTC (Thu) by pr1268 (guest, #24648) [Link] (23 responses)

I've a question for Red Hat in regards to what Goswin von Brederlow's quote talks about:

WHY???

Distribution quote of the week

Posted Dec 8, 2011 6:13 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (11 responses)

To be clear, it is Fedora Project and not Red Hat that is considering the move. It has been recently approved for Fedora 17 by Fedora Engineering Steering Committee, a fully elected body.

For more details, refer to https://fedoraproject.org/wiki/Features/UsrMove

Distribution quote of the week

Posted Dec 8, 2011 16:09 UTC (Thu) by nix (subscriber, #2304) [Link] (10 responses)

And now is being forced down everyone else's throats unless they want to audit everything that installs to / for signs that its authors are drinking the Fedora kool-aid. Great.

Distribution quote of the week

Posted Dec 8, 2011 16:26 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (9 responses)

What rubbish. Symlinks are maintained for compatibility. Nobody is forcing anything. Especially other distributions. This is free software after all.

Distribution quote of the week

Posted Dec 8, 2011 19:17 UTC (Thu) by nix (subscriber, #2304) [Link] (8 responses)

"This is free software", only now all the other distros have to look at everything for which RH is the upstream and which is critical for boot and figure out how many of those things now require / and /usr to be on the same filesystem or require hacking to fix it -- hacks which upstream will surely reject, so they need to be forward-ported for eternity. It's not like the symlinks for compatibility will work if / and /usr are on different filesystems and /usr is not mounted in early boot when a lot of this stuff is needed. You know, like almost every Unix system for the last thirty years.

Unless what you're proposing here is that everyone else follow on and eliminate /usr as a separate filesystem -- which ignores the installed base of systems -- your suggestion is vacuous.

But, hey, why pay attention to little things like the installed base or little things like other distributions perhaps not wanting to scrutinize every single commit in the software they get from other distros in case bombshells like this are thrown in. We use Fedora, we don't care what effect our decisions have on other distributions. (Several upstream maintainers of critical software who happen to work for major distributors have this attitude -- in each case picking a different distribution as the one you 'should' use if you want to use their software -- and it is utterly odious.)

Distribution quote of the week

Posted Dec 9, 2011 9:23 UTC (Fri) by jschrod (subscriber, #1646) [Link] (7 responses)

> You know, like almost every Unix system for the last thirty years.

Ahem, like, Solaris, the most used Unix(tm) system, where /bin is symlinked to /usr/bin since many many years? Which other Unix systems do you mean? HP-(S)UX? Are there people still using it in relevant numbers? AIX? Should we then take smitty and AIX's configuration concept as a guide as well?

The split of / and /usr has been arbitrary since quite some time. It's much more important to work on being able to mount / read-only or over the net (with a local /etc partition), IMNSHO.

While I dislike the attitude of the systemd developers quite often, in this case (and in the introduction of /run) they're right. Actually, they bring it in line with one other major Unix system out there, not seperate it from Unix-land.

Distribution quote of the week

Posted Dec 9, 2011 9:38 UTC (Fri) by dlang (guest, #313) [Link] (6 responses)

having /bin be a symlink to /usr/bin is very different from making /sbin be a symlink to /bin

after the system is running, both /bin and /usr/bin can be mounted using the tools in /sbin

the issue here is that /sbin is supposed to be all you need to get the system to the state that will allow you to then mount other filesystems (and fix them if needed)

eliminating /sbin breaks this.

now if they were going to move everything from /bin to /sbin, that would not break any of this, it would just bloat /sbin (which I don't see as a real problem with modern disk sizes)

This is sheer fantasy...

Posted Dec 9, 2011 10:14 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

the issue here is that /sbin is supposed to be all you need to get the system to the state that will allow you to then mount other filesystems (and fix them if needed)

This is strange fantasy - I'm not sure if it was ever true. Without /bin/sh most systems can reach the state where they can mount anything else.

Sure, it's possible that at some point Solaris have enough tools in /sbin to actually start the system in emergency more, but I doubt that very much.

And in any case this discussion is entirely theoretical because today /sbin is symlink to /usr/sbin in Solaris...

This is sheer fantasy...

Posted Dec 9, 2011 10:39 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

And even on Solaris 9, where /sbin was still a real directory on the root filesystem (but /bin and /lib were symlinks to /usr/bin and /usr/lib), the contents of /sbin would certainly not be enough by themselves to fix a system whose separate /usr volume had been mangled.

This is sheer fantasy...

Posted Dec 9, 2011 17:29 UTC (Fri) by drag (guest, #31333) [Link] (2 responses)

> This is strange fantasy - I'm not sure if it was ever true.

It was true. A very long time ago it was true.

Back when the easiest way to get your PC running Linux was to first boot your PC into Windows and use Window's "device manager" to take notes on your hardware configuration so that you could then get a working kernel config going.

Since then, of course, things have changed.

I was around back then, you know...

Posted Dec 10, 2011 7:08 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

Back when the easiest way to get your PC running Linux was to first boot your PC into Windows and use Window's "device manager" to take notes on your hardware configuration so that you could then get a working kernel config going.

I'm pretty sure back then you had no need for anything is /sbin to boot your system: you only needed files in /boot (well, initially they were placed in the root of the filesystem) and one program (initially sash, later busybox) on a floppy drive. I'm pretty sure you can do the same today and even with Fedora's "grand unification" it should still be possible. Except for a floppy drive: often contemporary systems just don't include the necessary hardware...

I was around back then, you know...

Posted Dec 10, 2011 8:05 UTC (Sat) by drag (guest, #31333) [Link]

> I'm pretty sure back then you had no need for anything is /sbin to boot your system: you only needed files in /boot (well, initially they were placed in the root of the filesystem) and one program (initially sash, later busybox) on a floppy drive. I'm pretty sure you can do the same today and even with Fedora's "grand unification" it should still be possible. Except for a floppy drive: often contemporary systems just don't include the necessary hardware...

That seems to agree with the reasoning to get rid of /sbin /bin, etc in modern times.

The initrd will have everything you need to mount a remote /usr/ directory. You can use busybox with initrds, for example.

Distribution quote of the week

Posted Dec 10, 2011 8:56 UTC (Sat) by jschrod (subscriber, #1646) [Link]

I think it would be more worthwile to have a good selection of repair tools in initrd/initramfs. When /usr is not mountable or defect, / might not be mountable either.

In fact, that happened to a colleague of mine just a few days ago when he hosed his workstation's md configuration. /boot was still found by grub, of course, but nothing could be mounted. Any tools in /sbin were not worth a bit, we needed a rescue dvd. Repair tools in initrd whould have helped.

Distribution quote of the week

Posted Dec 8, 2011 10:35 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (6 responses)

I believe that this document on freedesktop.org helps to understand the motivation. I find this paragraph particularly intriguing:

One thing in advance: systemd itself is actually completely fine with /usr on a separate file system that is not pre-mounted at boot time. However, the common basic set of OS components of modern Linux machines is not, and has not been in quite some time. And it is unlikely that this is going to be fixed any time soon, or even ever.

I'm still confused...

Posted Dec 10, 2011 3:54 UTC (Sat) by pr1268 (guest, #24648) [Link] (5 responses)

I'm still confused... If ~~Red Hat~~ Fedora is moving everything over to /usr, then wouldn't that make the hideous breakage as reported on Freedesktop.org even worse? Or, is Fedora trying to "convince" distros to move everything to /usr/{bin,sbin,WHATEVER} to influence the systemd folks to fix the bug?

FWIW My Slackware 13.37 system currently has 134 files in /usr/bin symlinked to their corresponding equivalents in /bin (although there is a many-to-one relationship of some files, e.g. bunzip2, bzcat, and bzip2 all symlink to ../../bin/bzip2).

Moving binaries to /usr/bin

Posted Dec 10, 2011 4:19 UTC (Sat) by jrn (subscriber, #64214) [Link]

I suspect the idea is that if all binaries are in /usr/bin, one doesn't have to fuss about where the binaries are. :) And if /usr is mounted early enough, why not? (There are some other benefits, like /usr being easier to set up than / as a read-only filesystem.)

I don't know of any systemd bugs in this area, other than a strange altruistic propensity to warn in its log about /usr not being mounted early enough for the sake of other packages like udev.

I'm still confused...

Posted Dec 10, 2011 22:39 UTC (Sat) by james (guest, #1325) [Link] (3 responses)

At the moment, the situation is:

initrd mounts /
initrd switches to /
userspace in / looks in /usr before /usr is mounted
BUG!

Under this proposal:

initrd mounts /
initrd mounts /usr
initrd switches to /
userspace in / looks in /usr
the bug is hidden; /usr was mounted before "real" userspace ever got started.

So this means that you can have a separate /usr if you're prepared to have an initrd, or you can use your own kernels without initrds if you put /usr on the same filesystem as /.

I'm still confused...

Posted Dec 11, 2011 5:27 UTC (Sun) by raven667 (subscriber, #5198) [Link] (2 responses)

And I think this bears repeating, the first case where /usr is on a separate partition and stuff breaks during boot if it's not mounted is the _current_ case, not the case being introduced by the proposed change. There has been some effort over the previous years to audit the boot process and move binaries from /usr to / to fis this when the issue is detected but this has been scattershot and incomplete.

The proposal to just move everything to /usr and make sure it is always mounted directly after / _fixes_ this problem once and for all. The fact that this also fixes another set of thorny cases is just gravy, the fact that this has been successfully done on other big UNIX systems is a great endorsement. This doesnt have anything to do with systemd trying to eat your baby, It just exposed more pre-existing cases that were broken in the current setup.

I'm still confused...

Posted Dec 11, 2011 17:54 UTC (Sun) by jrn (subscriber, #64214) [Link] (1 responses)

> This doesnt have anything to do with systemd trying to eat your baby, It just exposed more pre-existing cases that were broken in the current setup

Did systemd actually provoke any worse behavior? I had assumed it was just warning about this class of bugs for kicks.

I'm still confused...

Posted Dec 12, 2011 4:08 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Systemd starts services as needed which probably created several service start orders that, while perfectly valid, hadnt been tested in practice and broke.

Distribution quote of the week

Posted Dec 9, 2011 17:53 UTC (Fri) by cdmiller (guest, #2813) [Link] (3 responses)

Why? From the FAQ on freedesktop.org they state trying to make /usr shareable in a sane way, however the true reason appears to be an accommodation for systemd. Systemd gives up if /usr is on a separate partition. Perhaps a whole new systemd OS is needed. Just roll all of /bin, /sbin etc. into systemd and get it over with. Embedded and highly network centric systems need not apply.

Distribution quote of the week

Posted Dec 11, 2011 9:28 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Heh.

>Just roll all of /bin, /sbin etc. into systemd and get it over with. Embedded and highly network centric systems need not apply.

That's almost exactly what Busybox does. And it's mostly used on embedded systems.

Distribution quote of the week

Posted Dec 11, 2011 17:08 UTC (Sun) by raven667 (subscriber, #5198) [Link]

What a party pooper, letting logic and sense get in the way of a good rant.

Is it just me or has everyone gotten a lot more curmudgeonly on LWN recently?

Distribution quote of the week

Posted Dec 11, 2011 22:09 UTC (Sun) by Fowl (subscriber, #65667) [Link]

> That's almost exactly what Busybox does. And it's mostly used on embedded systems.

Like routers. (sorry, couldn't resist!)