| |||||||||||||
Systemd incompatible with mounted /usrSystemd incompatible with mounted /usrPosted Mar 3, 2011 20:06 UTC (Thu) by mezcalero (subscriber, #45103)In reply to: Systemd incompatible with mounted /usr by nix Parent article: Quotes of the week
But why? Just *why* all this work?
I can only keep repeating myself: separate /usr is not a benefit in itself. If you want to do that to mount it read-only, then you are simply aiming too low, and you should rather work on making / read-only. And you know what? We actually have been working hard on fixing the remaining problems to make this possible. And even enable it by default one of those days.
My recommendation: try to investigate how things really are, and think about them for a while. And then make a smart comment, instead of just calling us idiots. Thank you.
(Log in to post comments)
separate /usr isn't just about r/o or NFS Posted Mar 21, 2011 16:08 UTC (Mon) by gvy (guest, #11981) [Link]
Ever got filesystem corruption (doesn't really need rw, a lucky bad block might suffice)?
My recommendation: try to understand why smart people have been doing things that way before, and think about this for a while. And then try to fix the broken attitude of declaring working things useful for others broken only because you are working hard on solving entirely different thing.
The better folks I know do work on corner cases. "Mainstream" like McDonald's usually just don't bother. If Fedora is all about GNOME desktop only (as discussed already) then this attitude fits pretty well, of course.
separate /usr isn't just about r/o or NFS Posted Mar 21, 2011 16:32 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
If you want to fix the corner cases, you are welcome to. The current issues are no Fedora specific in any way. Your favor distro has it too. As has been pointed out, systemd is merely the messenger.
smells Richard Hughes, btw Posted Mar 30, 2011 21:00 UTC (Wed) by gvy (guest, #11981) [Link]
> If you want to fix the corner cases, you are welcome to.
Last summer it was a filesystem deadlock. Hope you won't face it now :)
> Your favor distro has it too.
> As has been pointed out, systemd is merely the messenger.
And the instructor seems to have a stance that dumping that all on a user is more sane than going after those who are ignorant enough to introduce that crap in the first place (remember RH#534047?).
Now that's weird. I wouldn't waste time on Mr. Hughes but Lennart is, or at least was for many years (judging as a packager), much different.
r/o root and /etc/udev/rules.d/*persistent*rules Posted Apr 1, 2011 11:22 UTC (Fri) by gvy (guest, #11981) [Link]
> If you want to do that to mount it read-only, then you are simply aiming
> too low, and you should rather work on making / read-only. (diggin' within /lib/udev) BTW it's interesting how you're going to do with persistent rules which are essentially the cache (thus belonging to /var, not /etc) but may be crucial to bringing up the stuff to mount said /var, be it a network interface or FC-connected storage (a tape library over here used to perform a streamer dance until fixated that way).
Not a nitpick, it's quite interesting, actually.
Systemd incompatible with... Posted Oct 3, 2012 9:20 UTC (Wed) by gvy (guest, #11981) [Link]
Seems that the mantra has changed, and now Linux kernel is barely compatible with udev: https://lkml.org/lkml/2012/10/2/303
Lennart, would you please admit that being deaf to users is what hurted KDE4/GNOME3 efforts *big* time and stop advocating Kay no matter what? You're trying to break system layer which isn't easy enough to work around (like switching to XFCE or staying with WindowMaker).
I do understand that Red Hat might have some vision on future init but pushing the result down the throat won't help down the road.
Thank you for all the effort and good code, once upon a time many of your project were my favourite upstreams due to concise info and clean maintenance.
Systemd incompatible with... Posted Oct 4, 2012 0:33 UTC (Thu) by nix (subscriber, #2304) [Link]
Earlier link: <http://www.spinics.net/lists/netdev/msg185742.html>.
I boggle. Lots and lots of modules need firmware when they initialize. They always have, they always will. Decreeing that 'they should not' doesn't change the reality that they *do*.
Systemd incompatible with... Posted Oct 4, 2012 15:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
No, that's a sane requirement. Requesting firmware in module_init() can lead to deadlocks, if userspace can't process the request. It happened to work before because most of time userspace usually just reads firmware from a disk/initramfs.
So it makes sense to do something about it, however definitely not in the way udev developers do it.
Systemd incompatible with... Posted Oct 4, 2012 0:39 UTC (Thu) by bronson (subscriber, #4806) [Link]
Oof, I'm hoping Kay didn't actually release somewhat broken code without an idea of how he would fix it, but that seems to be what he's saying...?
This looks like an interesting story.
Systemd incompatible with... Posted Oct 4, 2012 1:14 UTC (Thu) by nix (subscriber, #2304) [Link]
So it appears.
I'm damn glad that Linus and Al appear to agree with the rest of us who value stability in re the ongoing udev trainwreck. I don't *want* a new init system, I don't want to have to make invasive changes to my system on every udev upgrade, I just want something that manages a hotplug /dev for simple cases like usb mass storage plugged in after boot, lets me customize it by adding symlinks, tweaking permissions and the like, and otherwise gets out of the way.
udev used to do this when gregkh maintained it and for a while after, but currently is so far from this that is just not true. The last udev release that added a feature that I actually valued was about 130, but since then almost every release has been terrifying and introduced heaps of incompatible changes for no reason other than that it can, many releases have required invasive changes to the way my system is booted and break backward compatibility so that if I try to downgrade after a successful upgrade *that* will fail to boot, it's halfway to mandating systemd usage... no no no, bring back a udev with maintainership that understands how boot-critical software should be maintained, please. (That is to say, carefully and with great attention paid to backward compatibility and break-free upgrades without the poor distributors and/or upgraders having to whip themselves into a frenzy to do it.)
(Yes, I know I can just run an old udev. That's what I'm doing. But running unmaintained older versions of critical software required for boot because you can't trust the maintainers not to break your boot on every release is not good. Not good at all. Among other things, eventually programs will presumably start requiring a newer libudev...)
Systemd incompatible with... Posted Oct 4, 2012 9:46 UTC (Thu) by Eckhart (guest, #74500) [Link]
> I just want something that manages a hotplug /dev for simple cases like usb mass storage plugged in after boot
… except that it does not make sense to differentiate between "before boot" and "after boot" at all
Systemd incompatible with... Posted Oct 11, 2012 11:00 UTC (Thu) by nix (subscriber, #2304) [Link]
Really? People keep saying this but I really don't think it's true. 90% of the devices on every system I own, including all the 'difficult' ones like the ones that are part of RAID arrays and the networking and the framebuffers and the like, are non-hot-pluggable or hotplugged so rarely that I don't care if I have to do something special to make the system pick them up (much less than once a year).
Just about the only hotplugged stuff is USB devices and the block devices that generally hang off them... and udev has worked perfectly well in *that* case for many years. So the cause of the continuing disruptive churn is completely opaque to me. It certainly doesn't benefit me one bit.
Systemd incompatible with... Posted Oct 11, 2012 14:20 UTC (Thu) by Jonno (subscriber, #49613) [Link]
Technically all PCIe devices are "hot plugged", at some indeterminate period after it gets power, which it get simultaneously with the main system. If the main OS assumed that all PCIe devices was available at start, that would lead to all kinds of race condition.
The same goes for USB (of course) and SATA, and likely a host other systems...
As an anecdote, I had an oldish SATA device that suddenly stopped being bootable, but worked perfectly once booted from CD.
It turned out that the drive firmware had a boot time of O(n²) where n was the number of bad block relocations. Thus as the drive got old, it began to turn up after BIOS handed over to GRUB, and GRUB didn't have hot plug support :(.
I "solved" the problem by configuring BIOS to always do a full memory check at boot, slowing it down by 5-10 seconds, making booting work 9 cases out of 10. I have since replaced the disc, but it goes to showing that even devices you think are static aren't really...
Systemd incompatible with... Posted Oct 11, 2012 19:03 UTC (Thu) by nix (subscriber, #2304) [Link]
See, there's a major difference between 'technically' and 'in practice' here. Maybe my PCIe and SATA buses are theoretically hotplugged, but not once in the entire history of any of my systems with any of these buses has any device ever appeared while the OS was running, nor has one ever gone away except on one occasion when a disk failed (so hardly a hotplug event). Nor have I ever heard of systems other than really really high-end boxes (that I could not possibly afford) that can hotplug PCIe (though I have seen machines with external SATA connectors -- always unoccupied in my experience, but possibly useful in emergencies or to connect external drive enclosures, I suppose).
So any recomplication of the system to allow for those possibilities is wasted, from my perspective; and any administrative overhead imposed on me as a system administrator due to changes required by such recomplication is a cost sans benefit, that I would rather not pay.
Systemd incompatible with... Posted Oct 11, 2012 19:42 UTC (Thu) by raven667 (subscriber, #5198) [Link]
Maybe I just don't understand but doesn't the fact that these busses are possible to hot-plug and the fact that when it comes to enumeration and probing they behave like hot-plug in that they show up on the bus whenever they become ready mean that the driver systems that handle these devices have to handle the hot-plug case. The infrastructure has to be there to support it so I don't see how you can get rid of the complexity of dealing with these devices as hot-pluggable. It seems a simplification to just handle everything as a hot-plug case, rather than trying to maintain separate static and hot device initialization. infrastructure
Systemd incompatible with... Posted Oct 11, 2012 19:55 UTC (Thu) by raven667 (subscriber, #5198) [Link]
That was kind of a crappy comment. Maybe it would be better to say that "in practice" the hardware treats power-on enumeration like a series of hot-plug events which is why it makes sense for the kernel to handle it that way too. "in theory" maybe you could close your eyes and treat the system as static but there would be cases where that would cause you to get wedged that hot-plug wouldn't.
Systemd incompatible with... Posted Oct 12, 2012 15:31 UTC (Fri) by nix (subscriber, #2304) [Link]
I suppose that's true, if it is common to have PCIe devices that take so long to come up that they haven't started by the time POST has finished. That's not true of any system I own, but since all my systems are desktops and desktops are famously slow to POST...
(Do laptops use PCIe yet? Presumably they do: it's got more power-saving features in it than PCI has.)
I don't actually object to the hotplug-everywhere world, as long as it doesn't break anything much it seems like it might add generality without cost. Unfortunately over the last forty or fifty udev releases (as measured by version numbers) this has not generally been true: every upgrade has, as mentioned elsewhere, been frightening and well above 50% would have broken booting if I hadn't done other things to prevent it. (Those breakages that were due to outright bugs in udev did get fixed fast, but most of them were due to explicit incompatibilities that required sysadmin action. And every one of those was a cost without a benefit. Classic example: udev 174, without advance warning or stated rationale of any kind, moved udevd from /sbin into /lib/udev without leaving behind a compatibility symlink, breaking booting uless you fixed your boot scripts. Because, you know, so many Unix daemons live in subdirectories of /lib or /usr/lib. Oh, wait, none whatsoever do, except for udev. Then udev 175 moved it again (into /usr/lib), and moved udevadm as well, breaking the boot *again* unless you compensated for it. The udev maintainers' motto appears to be "backward compatibility is for other people".)
Systemd incompatible with... Posted Oct 12, 2012 15:54 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> (Do laptops use PCIe yet? Presumably they do: it's got more power-saving features in it than PCI has.)
Oh I'm sure that all the internal busses are PCIe and if there is an external ExpressCard slot, that's hot-plug PCIe. When it comes to power management I imagine that some devices drop out and show up on the bus in a hot-plug fashion when they are powered off/on.
> moved udevd [...] without leaving behind a compatibility symlink, breaking booting ...
That's pretty screwed up in any event. I find the logic and evidence compelling for collapsing / into /usr but that is no excuse for not putting in appropriate compatibility measures, measures which should be totally straightforward and transparent.
> The udev maintainers' motto appears to be "backward compatibility is for other people"
That's an unfortunate motto of much (though thankfully not all!) of userspace, it's one area where having source available has lead people to believe that rebuilding and recompiling the world is acceptable so API/ABI compatibility don't matter.
Systemd incompatible with... Posted Oct 6, 2012 1:03 UTC (Sat) by jackb (subscriber, #41909) [Link] I remember the transition from static device nodes to devfs because there were problems with static devices, then shortly afterwards we moved to udev because devfs was fatally, unfixably flawed, then devtmpfs + udev for some reason which isn't particularly clear, now there's a mention in LKML of moving udev into the kernel source tree. Now wondering if we're ever going back to static device nodes, just to really come back full circle.
Systemd incompatible with... Posted Oct 6, 2012 1:08 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
many people never stopped using static device nodes. For systems that don't have the hardware changing on them, a static /dev works very well.
not everything is a laptop with random USB device of the day getting hot-plugged into it.
|
|||||||||||||