[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: from / to /usr/: a summary

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

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.


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: pgp4gNLOAF72s.pgp
Description: PGP signature

Reply to: