On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote: > On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote: > > On Mon, December 17, 2012 22:31, Greg KH wrote: > > > On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote: > > >> Olav Vitters <[email protected]> wrote: > > >> >On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote: > > >> >> As I said in an earlier email, Lennart Poettering claims that it > > >> >> does > > >> >> not work. We are discussing some of the things necessary to make it > > >> > > > >> >work. > > >> > > > >> >Just to repeat: > > >> >In this thread it was claimed that a separate /usr is not supported by > > >> >systemd/udev. > > >> > > > >> >A case which works with latest systemd on various distributions. I > > >> >checked with upstream (not Lennart), and they confirmed it works. I > > >> >can > > >> >wait for Lennart to say the same, but really not needed. > > >> > > > >> >I assume this will again turn into a "but I meant something else". > > >> > > >> Olav. > > >> > > >> Lennart has stated that he considers a seperate /usr without init* > > >> broken. > > > > > > Yes, as do I, and so do a lot of other developers. > > > > It is only "broken", because upstream decided to move everything into /usr > > that was previously in /. > > No, not at all, please see the web page that describes, in detail, the > problems that has been going on for quite some time now, with the /usr > and / partitions and packages. > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > One good solution to this issue is to move everything into /usr, and > that's something that has wonderful benifits in the long run, and is > something that I expect all Linux distros to eventually implement. > Those that don't, will suffer because of it. > > Again, see the web page for why moving stuff into /usr is a good idea > for the reasons behind this. > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
Example: /usr Network Share When /usr is on a network share, why not add a / on network as well? I have multiple systems and as they all have different uses, they all have different software installed. Example: Multiple Guest Operating Systems on the Same Host See answer to previous example. How many environments actually currently exist where a shared /usr is being used? > > >> This has worked correctly in the past. > > > > > > Define "past" please. > > > > Recent past, like a few months ago no errors during boot and the system > > running stable. > > You have gotten lucky, see the above links for why. ALSA, LVM and HPLIP work perfectly with /usr on LVM without an initramfs. I have sound, the LVM partitions are detected and mounted correctly and I can use the full functionality of any HP printer I get access to. Those three are listed as being broken. > > Please provide a simple way to let me see that it is broken on systems > > that do not use bluetooth keyboards. > > Again, see the above link for how to do this. See above, 3 items that I use daily (apart from hplip, don't need printing and scanner daily) are listed as broken, but work without error. In what way should they be broken and how can I find out? > > The requirement of having userspace working to have input devices working > > seems to be related to bluetooth, not to USB or PS/2 keyboards. > > Not at all, see the above link. Ok, a few other devices are mentioned, the only one I need to mount /usr in that list is LVM, which starts correctly already. > > And using a bluetooth connection to access a NFS share is, in my humble > > opinion, a corner case that requires additional work to make it work. > > One person's "corner case" is another person's default operating mode. Yes, but the "corner case" I just mentioned is one that won't work without a init*. My use-case has been stable for years. > > > Note, it's still broken, I have yet to see any upstream fixes to resolve > > > all of the issues that are involved here with "fixing" this up. > > > > Reverting back to an older version makes it work. > > Because of how we package udev? If it's packaging, then why are we having this discussion and do we need a fork to fix udev? > > Using "mdev" also works. > > mdev is not recommended for desktop or server systems, but feel free to > use it if you want. I might not be recommended, but it does proof that a seperate /usr is not broken. The way udev doesn't handle it is. > > > Yes, as always, for some subset of users, you can be lucky and it will > > > work for them, but those systems are getting rarer and rarer these days, > > > as the rest of upstream (not systemd here) are moving on and not doing > > > anything to change their behavior for this topic. > > > > Why rarer? Any system I can buy in a random shop will work using a > > seperate /usr, provided the software is installed sanely. > > Again, see above for why this is not true. Only because udev-upstream declares such systems broken. > > By moving everything into /usr, this brokenness is forced upon users. > > Not at all, but that's a separate topic than what we are talking about > here. True, but that move is done by the same individual(s). (Based on the name at the bottom of both those pages you referenced) > > >> The direction udev development is going, according to Lennart, is to > > >> make that impossible and he refuses to fix this regression. > > > > > > Again, this has NOTHING to do with udev or systemd, as has been pointed > > > out numerous times. I understand your _wish_ that it would have > > > something to do with it, but that will not change the facts, sorry. > > > > Then what does it have to do with? > > When it was made public that it is considered "broken", the news came from > > udev-upstream. This was before most systems encountered any breakage. > > That is because things were failing silently for some people, and not so > silently for others. Now udev warns about this type of situation, > shooting the messenger is usually a bad idea. Not planning to shoot the messenger. But when upstream takes the easy way out by declaring seperate /usr broken when that has been working correctly for years and then forcing additional parts onto peoples systems that they do not need or want will not be accepted with a smile. > > >> I am really happy with this project and intend on testing it once > > >> requests for this appear in the eudev mailing list. > > > > > > Good luck, the root problems still remain, and nothing that eudev ever > > > does can resolve that, sorry. > > > > > > Can this topic finally be put to rest please? There is a whole web page > > > devoted to this topic, why do people blindly ignore it? > > > > Where is this page? > > I've read the page written by Lennart. Is there a decent (as in, going > > into detail why it is broken and what it is caused by) analysis about the > > "problem"? > > See above for the links and the details. Those I already read before. These show the following timeline: 1) Lets move everything into /usr 2) Wait, with everything in /usr, we can't mount /usr. Lets declare a seperate /usr to be broken. 3) To solve 2, lets force everyone to use an init* that contains the stuff that should have stayed in /. > > > Again, a separate /usr without an initrd has NOTHING to do with systemd > > > or udev, with the minor exception that Gentoo's packaging of those > > > programs _might_ have an issue, but that is Gentoo's issue, NOT > > > upstream's issue. > > > > > > If anyone involved with eudev, or is involved with the Gentoo Council > > > thinks that the previous paragraph is incorrect, they are flat out > > > wrong. > > > > I have yet to hear about a clear explanation why a seperate /usr is broken > > apart from the use of bluetooth keyboards. (Which are still in the > > minority when I check local shops/webstores) > > Again, see above for specifics. See above why I feel those 2 links are insufficient as an explanation. -- Joost
