| 1 |
I had smashing success migratingraid volumes to a new motherboard by |
| 2 |
building a readonly loopback boot-cd rootfs volume, and using |
| 3 |
|
| 4 |
cp -sr /mnt/rescue /mnt/newroot |
| 5 |
|
| 6 |
before building stage2,3; with minor /etc grumbling, the system |
| 7 |
bootstrapped flawlessly while still borrowing a few sensitive static |
| 8 |
utils where combinations of kernel, gcc and libc could otherwise wreak havoc |
| 9 |
|
| 10 |
I'm very happy with new GUID-based volume mounting and more stable raid |
| 11 |
tools, but a CF-based or initrd root available when /lib goes to hell is |
| 12 |
an absolute must for supporting fault tolerance. |
| 13 |
|
| 14 |
|
| 15 |
Chris Gianelloni wrote: |
| 16 |
|
| 17 |
>On Tue, 2005-05-17 at 10:33 -0700, Donnie Berkholz wrote: |
| 18 |
> |
| 19 |
> |
| 20 |
>>-----BEGIN PGP SIGNED MESSAGE----- |
| 21 |
>>Hash: SHA1 |
| 22 |
>> |
| 23 |
>>Chris Gianelloni wrote: |
| 24 |
>> |
| 25 |
>> |
| 26 |
>>>A much better approach would be for there to be a rescue build, |
| 27 |
>>>completely independent of the stages, since it doesn't need to mirror |
| 28 |
>>>them in any way. It should be extracted (self-extracted?) to something |
| 29 |
>>>like /rescue and executed from there, being completely self-contained. |
| 30 |
>>>This keeps it from stomping on system files and breaking |
| 31 |
>>>collision-protect or doing anything else nasty like hosing configuration |
| 32 |
>>>files (ever made the mistake of extracting a stage onto a live |
| 33 |
>>>filesystem?) when unpacked. |
| 34 |
>>> |
| 35 |
>>> |
| 36 |
>>This sounds a lot like saying, use an initrd, but when you pivot roots |
| 37 |
>>to the live filesystem, leave it mounted somewhere. |
| 38 |
>> |
| 39 |
>> |
| 40 |
> |
| 41 |
>Kinda... This wouldn't require a reboot, though. When the user is done, |
| 42 |
>they simply rm -rf /rescue and their system is clean again. |
| 43 |
> |
| 44 |
> |
| 45 |
|
| 46 |
-- |
| 47 |
gentoo-dev@g.o mailing list |
Archives