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