Tom H wrote: > On Sun, Jun 6, 2010 at 5:30 PM, lrhorer <lrho...@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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/14udnz5xyoheo5lrnz2dnuvz_jsdn...@giganews.com