Re: Update GRUB to GRUB2 / Lenny to Squeeze
Tom H wrote:
> On Sun, Jun 6, 2010 at 5:30 PM, lrhorer <lrhorer@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?
Reply to: