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

Re: Red Hat is moving from / to /usr/

Philip Hands <phil@hands.com> writes:

> On Wed, 7 Dec 2011 09:00:35 +0000, Simon McVittie <smcv@debian.org> wrote:
>> On Wed, 07 Dec 2011 at 01:43:34 +0100, Marco d'Itri wrote:
>> > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf
>> > 
>> > Discuss.
>> As far as I can make out, their position is that a separate /usr is now only
>> supported if you mount it from the initrd - which to be honest seems a
>> reasonable way to keep existing separate-/usr systems working, without
>> defeating the "/ is small" justification for a separate /usr by gradually
>> migrating more and more of /usr into the root filesystem.
>> It doesn't really address the "/ as recovery system" use of a separate /usr
>> if your root filesystem can't boot unaided, but I'm far from convinced that
>> a separate /usr makes / significantly more reliable, and an entirely
>> separate installation (Debian Live on removable media, or a smaller Debian
>> install in a separate partition that isn't normally even mounted) makes an
>> even more reliable recovery system.
> The problem with such rescue partitions is that if anything about your
> setup is peculiar, then they are likely to rot in a way that ensures
> that they will no longer support new features of the installed kernel on
> the machine to be rescued.  Likewise, if you've had to build a custom
> kernel to support your hardware, then default rescue media may well not
> help you.
> RedHat can probably safely ignore that, because their users are not
> quite as inventive as ours, and they're only really trying to address
> the middle of the bell-curve anyway.  That leaves us with
> disproportionately more odd use cases, because they're not being catered
> for by the commercial distros.
> Also, as far as I've seen the default method for fixing RedHat systems
> is to pop in a rescue disk (at least when I was an RHCX that was
> certainly the suggested approach in their exams for many of the failure
> modes). If that is the default solution anyway, then making it
> impossible to use other recovery methods is not so much of a leap.
> Personally, I think that resorting to rescue media is something of an
> admission of defeat, but I'm probably a bit odd ;-)
> I seem to occasionally find myself in situations where the machine
> that's failed is the one that you'd use for downloading or burning the
> rescue media, or for building the custom kernel needed for the hardware,
> so that I'd have real pain if my only solution was getting hold of a
> matching rescue disk.  People using ARM seems likely to make this
> situation more likely, as there seem to be way to many flavours of ARM.
> Having said all that, it would be nice if we made the default setup
> include a rescue partition, with hooks to ensure that kernels are
> updated on the rescue partition (preferable after the system
> successfully boots with the new kernel, say), and it's generally kept
> happy and ready for use.
> Cheers, Phil.

I have a bug open about a grml.deb that adds a grml boot entry to the
systems bootloader. With that you would always have an uptodate live CD.


Reply to: