On Thu, 22 Dec 2011 10:50:02 +0100, md@Linux.IT (Marco d'Itri) wrote: > On Dec 22, Philip Hands <phil@hands.com> wrote: > > > In reality, the folks on the status quo side probably only care about > > their servers, and are quite happy to have their laptops slightly > > restricted in the combinations that are possible, while the people > > arguing for change just want some way to not be forced to do the extra > > work when it seems mostly pointless. > It's not just this, in some cases this "extra work" is significant > enough to not be practical or even possibile. > And if you do not pretend to boot without /usr being available, new > features like everything-in-/usr become possible. > > The main objections so far can be summarized as "I like to do thing my > way and changes make me unconfortable". Thanks for dismissing me like that -- It really makes me want to try to take your point of view into account. > As it has been discussed, the reasonable need for a rescue environment > can be satisfied in a much better way with a standalone rescue initramfs > which is not dependent even on the root file system (if you can break > /usr then you can break / as well). I used to use mondo-rescue for ensuring that systems were rescue-able. The problem is that on production systems one quite often never gets given the chance to test if the rescue system still works, so I ended up abandoning the use of mondo because it happened to me often enough that the hardware had been replaced under the OS, and some change that was required to support the new hardware didn't make it into the rescue images. I'd imagine the same is true of a rescue initramfs -- and I'm still not going to be allowed to do test reboots to find out what's broken, which means I cannot rely on those rescue methods being available when I really need them -- quite often I do use rescue media, and the other options that keep being suggested, but if one is under time pressure, it is very quick to determine if the root partition is still viable, and if it is one at least knows that it is the same software that succeeded to boot the system the last time it was running (unless you broke it right then). That allows you to focus on fixing the problem, rather than having to worry that you're adding new problems by using different versions of utilities, or kernels with differing features enabled. I must say it was pretty disappointing when repairing a system that a client had neglected for two or more releases to discover that the ext3 filesystem I'd created with a current rescue disk had created a filesystem with features that the old system's kernel didn't understand, so that it was unbootable after the restore. In that case a separate / didn't help anyway, of course, but it does indicate that rescue media are not always the answer. > > Could we not have a package that checks if a system is going to be > > unbootable under the circumstances in question (i.e. it has /usr on > > nfs4, or whatever) and refuse to install on such a system, lets call > > that package 'early-boot-usr'. > > > > Then for the people that are having to put in extra effort into > > packaging things that want to assume that /usr is there from early boot, > > they just need to depend on early-boot-usr. > Yes, we will need something like this. But sooner or later udev will > depend on it, so I fear that it will not solve your problem. Why? If you can spend a few seconds explaining why udev seems to have this creeping dependency doom then perhaps we can get to the root of the problem, and perhaps split udev into the bits that really are needed early in the boot, and other stuff that can await the functionality that it seems we're constantly adding to it. If for instance udev needs this because there's some clever software in /usr that allows USB 3G modems to have the CD emulation bit turned off, so that some moron can mount /usr over NFS over 3G, well I really don't give a damn. On my servers, if someone plugs in a USB _anything_ then it will be because they chose the wrong server in the co-lo centre, and I want my server to do precisely nothing in response (ok, unless it was a USB keyboard ... maybe). Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
Attachment:
pgpOOOIzXniDr.pgp
Description: PGP signature