Zac Medico wrote:
> On 04/09/2012 11:09 AM, Steven J Long wrote:
>> One thing that has bothered me with the mooting of an initramfs as the
>> new rescue system that rootfs has traditionally been, is at the we are
>> told at the same time that the initramfs can be very minimal. If so, how
>> does it provide the same capabilities as rootfs (for those of us who can
>> localmount without udev-configured devices)?
>
> We've had some discussion on this before [1], and I've suggested to copy
> the content of livecd/usb recovery disk onto a spare partition so that
> you can boot into that if necessary. The advantage of using this
> approach is that it eliminates the burden of maintaining the "/ is a
> self-contained boot disk that's independent of /usr" use case.
>
It's a nice idea, and could also be done without an initramfs, ofc. You
mention configuring "initramfs to mount that as the root if something goes
wrong with your real root."
Thing is, for most desktop/laptop installs, if something goes wrong mounting
root from hard-disk, it's likely that booting into another partition will go
wrong too. It's pretty rare to get errors just on rootfs, that aren't to do
with the whole drive, and aren't fixed by fsck on a stable fs like ext3. (If
you do, you have to go to backups ofc, and would be wise to suspect the
whole drive.) At least, that's been my experience using separate partitions
for everything.
In that circumstance, if a rescue shell weren't available, (you're able to
boot the kernel or the the spare partition can't be booted to) I would just
boot the latest sysresccd that was around, if not able to download from
another box. If it were really that bad, I'd likely want to reinitialise any
failing partition, and would probably want a recent minimal install disk.
Boot up problems which need admin-work on Gentoo, ime, tend to be about
system upgrades not playing nicely, rather than the kernel unable to boot at
all (once you know which drivers you need for eg PCI/SATA drives built-in,
you usually are able to get at least root consistently, on an older kernel
if you're upgrading.)
Again, being able to boot into the machine, and have the rootfs at hand for
say dispatch-conf and rc-update, works nicely. A rescue partition would
effectively work the same as a live-disk, in that you'd need to do all the
chrooting etc afaics, and would need to be maintained to stay current.
I suppose you could script that, but again, it just seems like a lot of
bother to implement an "alternative" that doesn't actually gain anything
over the traditional setup (plus making sure that partitions are mounted
before udev starts.)
As for the burden of ensuring that binaries installed to /{s,}bin don't link
to libs in /usr, why not just automate a QA check for that, and let
developers decide whether a fix is necessary? After all, core packages that
do that even when configured with prefix and execprefix = /, aren't so
portable, and Gentoo has always championed "doing the right thing" wrt
helping upstream fix portability issues.
I realise "core" is subjective, but it amounts to "what our lovely devs
decide on for us" which is part of the reason you choose a distro, and the
trust you place in its developers.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
