separate /usr/broken with udev extras
All,
Wehave the following bug report on gentoo linux regarding udev and and external dependencies on a system with a separate /usr partition.
http://bugs.gentoo.org/show_bug.cgi?id64235
Comment #1, in particular, is of interest to me, because I think we could solve this on gentoo if we had event types that told us when these failures happened. Right now, it seems that all ofthese failures are marked nomatch by udev, could they be marked as failed instead?
Thanks,
William
failures occurred or
Quoted 9 lines · William Hubbs
Wehave the following bug report on gentoo linux regarding udev and and external dependencies on a system with a separate /usr partition.
http://bugs.gentoo.org/show_bug.cgi?id64235
Comment #1, in particular, is of interest to me, because I think we could solve this on gentoo if we had event types that told us when these failures happened. Right now, it seems that all ofthese failures are marked nomatch by udev, could they be marked as failed instead?
Udev does not support missing tools which are referenced from rules, that's just an error that is logged.
Today we can not expect a successful bootup with /usr empty and 'half' of the needed tools missing. Most of the basic stuff, including udev itself has usually nothing in /usr, but the number of tools needing things from /usr is growing all the time, and it's unrealistic to fix/change them all. Too many tools do not support to be started with an empty /usr, and it's not as simple a fixing udev to re-run the events.
Please mount /usr from initramfs before 'init' is started, or if the setup is simple enough, at least before udev and other services start.
We just gave up supporting the split of tools in / vs. /usr. It does not make much sense today anymore, all tools should be available during bootup.
Related to this, you might want to read:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Kay
Quoted 1 line · Kay Sievers
We just gave up supporting the split of tools in / vs. /usr. It does
You did, as shown many times other distributions surely did not.
I don't even know /how/ I could stop supporting a standalone /usr: some distributions actually support upgrading a system to the next release, and this cannot require repartitioning.
Signature · 2 lines
ciao, Marco
Quoted 4 lines · Marco d'Itri
Quoted 1 line · Kay Sievers
We just gave up supporting the split of tools in / vs. /usr. It does
You did, as shown many times other distributions surely did not.
Good luck!
I'm looking forward to things like patches for the D-Bus config moving to the rootfs. :)
Quoted 3 lines
I don't even know /how/ I could stop supporting a standalone /usr: some distributions actually support upgrading a system to the next release, and this cannot require repartitioning.
Some stuff is broken for years for all non-simple services. The real fix is just a cp -ax away, I guess. :)
As mentioned, the distro's fix is to mount /usr from initramfs, and that's the only realistic option for /{bin,lib} vs. /usr/{bin.lib} split, with the ever-growing use of tools from /usr during bootup.
The random split of tools tools in /{bin,lib} vs. /usr/{bin.lib} makes no sense today, what /{bin,lib} was for UNIX is the initramfs for Linux today.
We are actually currently planning to move all tools from the rootfs to /usr, where they belong and sort out the chaotic split of install locations. There will be only compat symlinks left in / then.
Kay
Quoted 8 lines · Marco d'Itri
Quoted 1 line · Kay Sievers
We just gave up supporting the split of tools in / vs. /usr. It does
You did, as shown many times other distributions surely did not.
I don't even know /how/ I could stop supporting a standalone /usr: some distributions actually support upgrading a system to the next release, and this cannot require repartitioning.
Right, I have had a separate /usr on all of my installed systems for years, and I don't know of a reason having this shouldn't be supported.
I would rather see us work on fixing the tools so that it can still be done.
William
Quoted 4 lines · William Hubbs
Quoted 3 lines · Marco d'Itri
Quoted 1 line · Kay Sievers
We just gave up supporting the split of tools in / vs. /usr. It does
Quoted 8 lines
Quoted 5 lines
You did, as shown many times other distributions surely did not.
I don't even know /how/ I could stop supporting a standalone /usr: some distributions actually support upgrading a system to the next release, and this cannot require repartitioning.
Right, I have had a separate /usr on all of my installed systems for years, and I don't know of a reason having this shouldn't be supported.
Claiming as a distro that booting up with and empty /usr, with 'half' of the tools missing, is just wishful thinking, and it the end not more than a lie. In reality It works reliably only for limited requirements regarding device config. I see all these bugs for many years now.
Quoted 2 lines
I would rather see us work on fixing the tools so that it can still be done.
Honestly, I don't think that will ever happen. It's just too much stuff to fix and change.
Very basic server-like setups will just continue to work as they did before. But more and more of the new stuff will just fail in non-interesting ways.
All things that expect the new stuff to run properly, need to get an initramfs that can mount /usr before init is started, or need to copy /usr back to the rootfs. There is no other realistic option, really.
Kay
Quoted 7 lines · Kay Sievers
Some stuff is broken for years for all non-simple services. The real fix is just a cp -ax away, I guess. :)
As mentioned, the distro's fix is to mount /usr from initramfs, and that's the only realistic option for /{bin,lib} vs.
/usr/{bin.lib}split, with the ever-growing use of tools from /usr during bootup.
Quoted 7 lines
The random split of tools tools in /{bin,lib} vs.
/usr/{bin.lib}makes no sense today, what /{bin,lib} was for UNIX is the initramfs for Linux today.We are actually currently planning to move all tools from the rootfs to /usr, where they belong and sort out the chaotic split of install locations. There will be only compat symlinks left in / then.
Why not go the other way and move things that udev needs from /usr to /?
That would be an easier transition imho than moving everything to /usr.
William
Quoted 6 lines
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 12 lines · William Hubbs
Quoted 11 lines · Kay Sievers
Some stuff is broken for years for all non-simple services. The real fix is just a cp -ax away, I guess. :)
As mentioned, the distro's fix is to mount /usr from initramfs, and that's the only realistic option for /{bin,lib} vs.
/usr/{bin.lib}split, with the ever-growing use of tools from /usr during bootup.The random split of tools tools in /{bin,lib} vs.
/usr/{bin.lib}makes no sense today, what /{bin,lib} was for UNIX is the initramfs for Linux today.
Quoted 7 lines
Quoted 3 lines
We are actually currently planning to move all tools from the rootfs to /usr, where they belong and sort out the chaotic split of install locations. There will be only compat symlinks left in / then.
Why not go the other way and move things that udev needs from /usr to /?
That would be an easier transition imho than moving everything to /usr.
Because many of these tools have dependencies on libs in /usr, or config in /usr/share. It's a game we can not win realistically, we will need to move too much stuff to /, which makes the entire idea of splitting / and /usr in the first place moot.
What's not needed today is stuff in /. We can think of /usr a /System. The entire system is installed in one single directory, and that can be mounted r/o, or even shared between many hosts/guest. The stuff on the rootfs is always host-only then.
Kay