[gentoo-user] Re: InitRAMFS - boot expert sought
The 29/03/12, J. Roeleveld wrote: On Wed, March 28, 2012 12:49 am, Mark Knecht wrote: snipped Do nothing. Just read, watch, learn but most important don't do updates. Just wait. Patience is a virtue! I wonder how many threads we'll get with I haven't updated my Gentoo for over a year, how do I best do the upgrade? from people following this advice? I think there is a better thing to do. Use an initramfs. This is not hell! ;-) -- Nicolas Sebrecht
Re: [gentoo-user] Re: InitRAMFS - boot expert sought
On Fri, March 30, 2012 9:23 am, Nicolas Sebrecht wrote: The 29/03/12, J. Roeleveld wrote: On Wed, March 28, 2012 12:49 am, Mark Knecht wrote: snipped Do nothing. Just read, watch, learn but most important don't do updates. Just wait. Patience is a virtue! I wonder how many threads we'll get with I haven't updated my Gentoo for over a year, how do I best do the upgrade? from people following this advice? I think there is a better thing to do. Use an initramfs. This is not hell! ;-) I'm not saying it is or isn't. I just don't understand why not upgrading for a while is given as an option considering the issues people will encounter when they try upgrading a Gentoo installation that hasn't been updated in a long time. -- Joost
[gentoo-user] Re: InitRAMFS - boot expert sought
The 29/03/12, Alan McKinnon wrote: On Thu, 29 Mar 2012 00:20:04 +0100 David W Noon dwn...@ntlworld.com wrote: The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. Which begs the obvious question, Why on earth is udev launching daemons in EARLY BOOT? udev launches nothing. udev scripts do. These scripts are not part of udev. -- Nicolas Sebrecht
Re: [gentoo-user] Re: InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 14:05:30 +0200, Nicolas Sebrecht wrote: Why on earth is udev launching daemons in EARLY BOOT? udev launches nothing. udev scripts do. These scripts are not part of udev. That is true, but udev provides no control over when these scripts are run. udev starts in early boot, because /some/ of its function is needed then, and it then tries to run rules for all detected hardware. This is a flaw in udev. -- Neil Bothwick In possession of a mind not merely twisted, but actually sprained. signature.asc Description: PGP signature
Re: [gentoo-user] Re: InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 14:05:30 +0200 Nicolas Sebrecht nsebre...@piing.fr wrote: The 29/03/12, Alan McKinnon wrote: On Thu, 29 Mar 2012 00:20:04 +0100 David W Noon dwn...@ntlworld.com wrote: The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. Which begs the obvious question, Why on earth is udev launching daemons in EARLY BOOT? udev launches nothing. udev scripts do. These scripts are not part of udev. OK, semantics. Let me re-phrase: Why is a third party script, running in the context of the udev universe, indiscriminately allowed to launch daemons at early boot time? I don't think I agree with Neil in that this is a udev design flaw (as any fix will be worse than the flaw). Instead it looks to me like a classic case of You are free to do anything you want but if you break it you keep the pieces. If you do something stupid, it's not my problem and you're on your own. I see nothing wrong with udev applying some reasonable constraints such as clearly documenting at what point in the boot process udev is in a position to arbitrarily run anything. Earlier than that point, anything does not actually apply. -- Alan McKinnnon alan.mckin...@gmail.com
RE: [gentoo-user] Re: InitRAMFS - boot expert sought
From: Alan McKinnon [mailto:alan.mckin...@gmail.com] OK, semantics. Let me re-phrase: Why is a third party script, running in the context of the udev universe, indiscriminately allowed to launch daemons at early boot time? I don't think I agree with Neil in that this is a udev design flaw (as any fix will be worse than the flaw). Instead it looks to me like a classic case of You are free to do anything you want but if you break it you keep the pieces. If you do something stupid, it's not my problem and you're on your own. This is, unfortunately, the biggest drawback to having a commercial entity in charge of doing the software development: this kind of attitude stops applying. Gentoo's developers, for example, would really like for people to use Gentoo, and work hard to make Gentoo useable, but if you start with the threats of I'm gonna stop using your OS unless you fix this RIGHT NOW! they'll probably just roll their eyes and ignore you. RedHat has a *commercial* interest in people using RedHat, even the non-commercial versions, and if their *customers* start filing bugs like I cannot make my Bluetooth keyboard work with my nfs mounted /usr that plays a ring tone through alsa when I mount it, they are much more motivated to fix it. I see nothing wrong with udev applying some reasonable constraints such as clearly documenting at what point in the boot process udev is in a position to arbitrarily run anything. Earlier than that point, anything does not actually apply. I don't think it's a design flaw, as much as it's a possible point of improvement for udev. It would be useful if udev could somehow distinguish between early and late devices. This doesn't eliminate the problem entirely: nothing is stopping you from, say, telling udev that mounting /usr requires /usr/mountme. But if you did something that silly, it would obviously be your fault. I think there are some options for how udev could be better here, it's just that they all seem to be a lot of risk; as much risk or more as just saying don't do that or use an initramfs. Off the top of my head: * udev could enforce that point you mention, and allow device scripts to explicitly say defer trying to configure me until after $KEYPOINT has been reached. * udev could keep track of dependencies between devices or device scripts and allow one to say don't run me until $DEVICE is also present * udev could keep track of prerequisite triggers for device scripts, and allow one to say don't run me until /usr/bin/alsaconf exists, but run me as soon as that appears. * udev could keep track of failed devices, and include a command-line switch like --reprocess; the init process could launch udev, allow whatever fails to fail, mount /usr, then tell udev to try again. As I understand it, the architecture of udev (and the kernel) makes many of these difficult; udev events are processed individually, isolated from each other. It has no concept of things like when I'm done configuring devices or devices that are waiting to be configured after this one. Though keeping track of failed devices seems like it would not be terribly difficult, as long as you could distinguish btween devices that are fatal failures vs. transient ones. Again, I'm not faulting the udev team for not doing those things. They either do a lot of work to update the behavior of udev to support a configuration they think is invalid and broken, or they simply tell people to stop using the invalid or broken configuration. If there were a clear consensus that the configuration was not, in fact, broken, then I could possibly see where they might be expected (from a /community/ perspective, clearly they have no /formal/ obligations to any of us) to put in that effort. But the consensus seems largely weighted towards agreeing with them, or at least not caring either way. --Mike
Re: [gentoo-user] Re: InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 22:55:42 +0200, Alan McKinnon wrote: I don't think I agree with Neil in that this is a udev design flaw (as any fix will be worse than the flaw). Instead it looks to me like a classic case of You are free to do anything you want but if you break it you keep the pieces. If you do something stupid, it's not my problem and you're on your own. I see nothing wrong with udev applying some reasonable constraints such as clearly documenting at what point in the boot process udev is in a position to arbitrarily run anything. Earlier than that point, anything does not actually apply. The reason I think it is a flaw is that udev is capable of doing some very clever stuff with nothing more than a simple device rule, but such clever stuff has no place in early boot. On the other hand, it also does basic stuff, like creating device nodes, that certainly does belong in early boot. The problem is that udev provides no way to distinguish between the early boot essentials and the clever stuff. Only a small subset of its work should be done when it is first started, possibly by tagging those rules, or simply postponing any rules with a RUN command. Or maybe a separate command (or invocation of the same command) that just creates device nodes, and any specified symlinks, much like mdev does, then kick in the full version later. However, as I type this, I can think of all sorts of arguments about what should be run early and what not. I'm beginning to understand why the devs decided if you want all this clever stuff, you'll just have to make /usr available. -- Neil Bothwick Windows Error:01F Reserved for future mistakes. signature.asc Description: PGP signature
