Prev: virtual box permissions ?
Next: ls has stopped using the ISO date format
From: lrhorer on 6 Jun 2010 18:10
lrhorer wrote:

>
> I upgraded a box from "Lenny" to "Squeeze", but the update of
> GRUB to
> GRUB2 failed.

I've cobbled together a procedure which I think will work and which is
(I hope) safe:

1. Comment out the entries for /dev/md1 in /etc/fstab
and /etc/mdadm/mdadm.conf, and reboot the system.

2. Mount /dev/hda1 to /boot.

3. Upgrade GRUB, which should now understand both /etc/fstab
and /boot/grub/menu/lst.

4. Reboot to make sure it works.

5. Edit /boot/grub/grub.cfg and /boot/grub/device.map to let GRUB2 know
it should be booting from an array and to make sure it is loading the
RAID1 module.

6. Umount /boot and create a new 1.0 superblock RAID1 array using only
/dev/hda1 and a missing member. Mount the new array as /boot.

7. Add the new array info into /etc/mdadm/mdadm.conf and
change /etc/fstab back to mount /dev/md1.

8. Run update-initramfs to copy the new configuration into initrd.

9. Reboot and make sure GRUB2 can now boot into the new array.

10. Add /dev/hdb1 into the new array, and re-sync the array.

11. Update /etc/mdadm/mdadm.conf with the full array info, getting rid
of the missing member, and remove the reference to the old array
altogether.

12. Run the GRUB update routine to remove the chain-load from GRUB
legacy.

13. Run update-initramfs to copy the final configuration into the initrd
(if GRUB update doesn't already do it.)

I should be able to easily back out of the procedure at any point up to
step 10 if something goes wrong. I'm a bit fuzzy around step 5. Since
GRUB needs to know how to read an array, it needs the RAID module
available *BEFORE* it reads /boot/grub/device.map. Should I run
grub-install at this point in order to load the module into the boot
loader in the MBR? Some other utility? What switches need to be used?
Since the loaded man pages refer to GRUB legacy, I'm a little unsure.

Comments? Suggestions?


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/XK-dnSCvtL57ipHRnZ2dnUVZ_sGdnZ2d(a)giganews.com
From: lrhorer on 6 Jun 2010 18:50
>>> You can't load modules for grub-probe.
>>>
>>> But you can for grub-install.
>>>
>>> The default modules that I have in a Sid VM for an install without
>>> mdraid or lvm are:
>>> minicmd, true, loadenv, extcmd, test, sh, normal, charset, terminal,
>>> crypto, boot, part_msdos, ext2, fshelp, biosdisk
>>>
>>> I have no idea whether they are hard-coded or there is a file
>>> somewhere that can be edited to control to which ones grub-install
>>> defaults.
>>
>> That doesn't help.  Until grub2 is unpacked and configured, neither
>> grub-probe nor grub-install (for GRUB 2) will exist.  I can't pass
>> parameters to a binary that doesn't exist.  Passing them to the same
>> respective file for GRUB legacy won't help, either.
>
> If you don't have grub-install, you are missing grub-common, upon
> which grub-pc depends.

Yes, of course. The point you seem to be missing is that until
the
package is upgraded, those won't exist, and until they exist, I can't
upgrade the package.

>> It doesn't matter since `dpkg --configure grub-pc` overwrites it with
>> the default every time before it gets to the point where it might be
>> used.
>
> Who cares? You don't have to use "dpkg --configure...".

If you have more specific suggestions, I welcome them. Telling
me what
I don't have to do is really not helpful. Note I am not particularly
intersted in completely over-writing GRUB legacy until I know GRUB 2 is
working: I very much like the Debian upgrade approach of chain-loading
GRUB2 from GRUB legacy until one is certain everything is working. I'm
running Debian "Squeeze", upgraded from "Lenny". I have a RAID1 array
which is mounted as /boot once the system exits initrd. GRUB legacy
reads one or the other RAID1 member as if it were an ordinary partition
and boots accordingly.

From menu.lst:

title Debian GNU/Linux, kernel 2.6.32-3-amd64 Disk 1
root (hd0,0)
kernel /vmlinuz-2.6.32-3-amd64 root=/dev/md2 ro quiet
initrd /initrd.img-2.6.32-3-amd64

title Debian GNU/Linux, kernel 2.6.32-3-amd64 Disk 2
root (hd1,0)
kernel /vmlinuz-2.6.32-3-amd64 root=/dev/md2 ro quiet
initrd /initrd.img-2.6.32-3-amd64

title Debian GNU/Linux, kernel 2.6.32-3-amd64 (single-user
mode)
root (hd0,0)
kernel /vmlinuz-2.6.32-3-amd64 root=/dev/md2 ro single
initrd /initrd.img-2.6.32-3-amd64


From /etc/fstab:

proc /proc proc defaults 0 0
/dev/md1 /boot ext2 defaults 0 2
/dev/md2 / ext3 defaults 0 1
/dev/md3 none swap sw 0 0

From /etc/mdadm/mdadm.conf:

ARRAY /dev/md0 level=raid6 num-devices=9 metadata=01.2 name=Backup:0
UUID=431244d6:45d9635a:e88b3de5:92f30255
ARRAY /dev/md1 level=raid1 num-devices=2 metadata=01.0 name=Backup:1
UUID=d6a2c60b:7345e957:05aefe0b:f8d1527f
ARRAY /dev/md2 level=raid1 num-devices=2 metadata=01.2 name=Backup:2
UUID=d45ff663:9e53774c:6fcf9968:21692025
ARRAY /dev/md3 level=raid1 num-devices=2 metadata=01.2 name=Backup:3
UUID=51d22c47:10f58974:0b27ef04:5609d357


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster(a)lists.debian.org
Archive:
http://lists.debian.org/XK-dnSGvtL4bjpHRnZ2dnUVZ_sGdnZ2d(a)giganews.com


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/XK-dnSOvtL5YvZHRnZ2dnUVZ_sGdnZ2d(a)giganews.com
From: Tom H on 7 Jun 2010 08:00
On Sun, Jun 6, 2010 at 5:30 PM, lrhorer <lrhorer(a)satx.rr.com> wrote:
>>>> You can't load modules for grub-probe.
>>>>
>>>> But you can for grub-install.
>>>>
>>>> The default modules that I have in a Sid VM for an install without
>>>> mdraid or lvm are:
>>>> minicmd, true, loadenv, extcmd, test, sh, normal, charset, terminal,
>>>> crypto, boot, part_msdos, ext2, fshelp, biosdisk
>>>>
>>>> I have no idea whether they are hard-coded or there is a file
>>>> somewhere that can be edited to control to which ones grub-install
>>>> defaults.
>>>
>>> That doesn't help.  Until grub2 is unpacked and configured, neither
>>> grub-probe nor grub-install (for GRUB 2) will exist.  I can't pass
>>> parameters to a binary that doesn't exist.  Passing them to the same
>>> respective file for GRUB legacy won't help, either.
>>
>> If you don't have grub-install, you are missing grub-common, upon
>> which grub-pc depends.
>
> Yes, of course.  The point you seem to be missing is that until the
> package is upgraded, those won't exist, and until they exist, I can't
> upgrade the package.

I am not missing any point. If you have grub-pc 1.98 installed without
grub-common 1.98 installed, grub2/grub-pc is broken, hence the error
when running "dpkg...". If you are worried about breaking grub1 after
installing grub2, you should know that, when you install grub2, you'll
be asked whether you want to chainload grub2 from grub1 or install
grub2 to the mbr. That doesn't guarantee that grub1'll not be broken,
but it's better than overwriting grub1's stage 1 loader immediately.


>>> It doesn't matter since `dpkg --configure grub-pc` overwrites it with
>>> the default every time before it gets to the point where it might be
>>> used.
>>
>> Who cares? You don't have to use "dpkg --configure...".
>
>        If you have more specific suggestions, I welcome them.  Telling me what
> I don't have to do is really not helpful.

Good luck with your problem...


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/AANLkTikT7_AMuoVekR2MPg85RU6AsH3i7vB_jGKWoINl(a)mail.gmail.com
From: lrhorer on 9 Jun 2010 03:40
Tom H wrote:

> On Sun, Jun 6, 2010 at 5:30 PM, lrhorer <lrhorer(a)satx.rr.com> wrote:
>>>>> You can't load modules for grub-probe.
>>>>>
>>>>> But you can for grub-install.
>>>>>
>>>>> The default modules that I have in a Sid VM for an install without
>>>>> mdraid or lvm are:
>>>>> minicmd, true, loadenv, extcmd, test, sh, normal, charset,
>>>>> terminal, crypto, boot, part_msdos, ext2, fshelp, biosdisk
>>>>>
>>>>> I have no idea whether they are hard-coded or there is a file
>>>>> somewhere that can be edited to control to which ones grub-install
>>>>> defaults.
>>>>
>>>> That doesn't help.  Until grub2 is unpacked and configured, neither
>>>> grub-probe nor grub-install (for GRUB 2) will exist.  I can't pass
>>>> parameters to a binary that doesn't exist.  Passing them to the
>>>> same respective file for GRUB legacy won't help, either.
>>>
>>> If you don't have grub-install, you are missing grub-common, upon
>>> which grub-pc depends.

Grub-install is there. The installation moves forward *UNTIL*
grub-probe fails. Also, I mis-spoke. I thought dpkg deletes the
installation files when an install fails, but it does not, so even
though the configuration fails, the binaries are still there.

>> Yes, of course.  The point you seem to be missing is that until the
>> package is upgraded, those won't exist, and until they exist, I can't
>> upgrade the package.
>
> I am not missing any point. If you have grub-pc 1.98 installed without
> grub-common 1.98 installed, grub2/grub-pc is broken, hence the error
> when running "dpkg...".

The error is because grub does not understand how to upgrade the
system. This is well documented, and there are a number of open bug
reports on the problem and related issues, including one submitted by
me. Grub-common 1.98 is installed, because it is part of grub-common
and because grub-common is prerequisite for grub-pc.

Running grub-install (which is no doubt what dpkg does) fails at
precisely the same point that dpkg does.

grubb-common is installed, but not fully configured (big surprise
there):

Backup:~# dpkg --list grub-pc
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Description
+++-====================================-====================================-========================================================================================
iF grub-pc 1.98-1
GRand Unified Bootloader, version 2 (PC/BIOS version)

The closest I have been able to come to a successful install still gives
me:

/usr/sbin/grub-probe: error: no mapping exists for `md1'.
You attempted a cross-disk install, but the filesystem
containing /boot/grub does not support UUIDs.


> If you are worried about breaking grub1 after
> installing grub2, you should know that, when you install grub2, you'll
> be asked whether you want to chainload grub2 from grub1 or install
> grub2 to the mbr.

I am well aware. I have upgraded a number of systems from GRUB legacy
to GRUB 2, just not one with a RAID array for /boot.

Oh, BTW, exactly how would you expect grub to install to the MBR of a
RAID array? A RAID array doesn't have an MBR. The *MEMBER* disks
do,but GRUB needs to install its boot loader to the MBR of more than
one disk - in this case both members of a 2 disk RAID1 array. Perhaps
this can be done manually by running grub-setup (or something) for each
array member. I don't know. Do you? If so, you have been anything
but forthcoming. At the same time that GRUB loads itself to multiple
member disks, it needs to expect to load from only one array,
regardless of from which drive it boots. BTW, I did try grub-install
with numerous different options, but it gives me very similar errors no
matter what I try. Too much in the way of trial and error is not a good
idea. If by some chance GRUB properly writes to the MBR of one or both
member disks, but then also writes to the file system of what it thinks
is an ordinary drive, it could corrupt the array.

> That doesn't guarantee that grub1'll not be broken,
> but it's better than overwriting grub1's stage 1 loader immediately.

Didn't I just say that?

>>>> It doesn't matter since `dpkg --configure grub-pc` overwrites it
>>>> with the default every time before it gets to the point where it
>>>> might be used.
>>>
>>> Who cares? You don't have to use "dpkg --configure...".
>>
>> If you have more specific suggestions, I welcome them.  Telling me
>> what I don't have to do is really not helpful.
>
> Good luck with your problem...

Is there some reason you feel compelled to give me an attitude, rather
than offer advice?


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/14udnZ5Xyoheo5LRnZ2dnUVZ_jSdnZ2d(a)giganews.com
First  |  Prev  | 
Pages: 1 2
Prev: virtual box permissions ?
Next: ls has stopped using the ISO date format