-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It would appear that on May 25, Kevin J. Cummings did say: > Joe(theWordy)Philbrook wrote: > > Well John, I can't say I've read all "forty-five page"s of the doc, > > (didn't count them either) But when I let grub install itself for FC2 > > I told it to add entries for each of my linux. And they all looked like > > your fedcore entry... And ALL of them got that error... I also noticed > > that the rootnoverify & chainloader lines were used for the non linux > > win98 partition (which worked for win98) And that convinced me to > > quickly scan "info grub" for a few clues, then used the working FC2 > > entry as a guide to rebuild the other linux entries with some help from > > my old lilo.conf for details like kernel names and clues what to append > > to the kernel for it... After which the only thing I still can't boot > > with grub is my DrDos hdc1 partition...<sigh> > > From my reading of the grub info file, the following should boot your DrDos > partition, provided that: > > 1) your DrDos boot loader is still in the /dev/hdc boot sector > 2) DrDos can boot from the 3rd hard drive (MS-Dos systems were notorious for > requiring the boot drive to be their "C:" drive).... > > title DRDOS > rootnoverify (hd2, 0) > chainloader +1 > > Good luck! You might have to swap hda,hdb with hdc,hdd in order for DrDos to > be bootable again. But, there should be no problem booting Linux from the > second controller. Grub should be able to handle that OK.... I'm currently > booting my system from /dev/hdb2, but grub is installed in /dev/hda. Yeah but /dev/hdc isn't my 3rd HARD drive, /dev/hdb is one of my cd drives. Since lilo can boot DrDos using table=/dev/hdc (providing I use it's "0x80 0x81" style drive mapping) I'm presuming that It meats your # 1 & 2 preconditions? other=/dev/hdc1 label="DrDos" table=/dev/hdc map-drive=0x80 to=0x81 map-drive=0x81 to=0x80 :r /boot/grub/device.map # this device map was generated by anaconda (fd0) /dev/fd0 (hd0) /dev/hda (hd1) /dev/hdc Except for the hd2 part, your example is just about what anaconda started with (which failed to even get DrDos's startup message, while the version in the quoted grub.conf below with the drive mapping at least gets to the starting message which says something like "Starting Caldera Dos..." before it hangs. (the DrDos version I have is 7.02 which was owned by Caldera slim when I bought the cd) Since it gets that far, I'm thinking grub MUST be trying to boot the right partition. So I'm at a loss what else to try. (does lilo do something different with it's drive mapping?) What other bit of grub set up "magic" could possibly apply to booting DrDos from the 1st partition of the 2nd hard drive? Also note the partition IS bootable according to fdisk Disk /dev/hdc: 61.4 GB, 61492838400 bytes 255 heads, 63 sectors/track, 7476 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdc1 * 1 261 2096451 6 FAT16 /dev/hdc2 262 3586 26708062+ 5 Extended /dev/hdc3 3587 5531 15623212+ 83 Linux /dev/hdc4 5532 7476 15623212+ 83 Linux /dev/hdc5 262 366 843381 83 Linux /dev/hdc6 367 427 489951 83 Linux /dev/hdc7 428 792 2931831 83 Linux /dev/hdc8 793 1400 4883728+ 83 Linux /dev/hdc9 1401 1522 979933+ 83 Linux /dev/hdc10 1523 3470 15647278+ 83 Linux /dev/hdc11 3471 3586 931738+ 82 Linux swap But thanks for the suggestion, I appreciate any help I can get. Note in the entire grub.conf quoted below, the only entry that fails to boot is DrDos (And I double checked yesterday, the lilo floppy I made with the lilo.conf file entry I quoted above can still boot into DrDos, so it's not that I've damaged the dos partition itself somehow.) Also note, the position of the "rootnoverify (hd1,0)" line in my DrDos entry is different from the version I first posted because I saw an example on getting a windows system to boot from the 2nd hard drive that placed it after the drive mapping, rather than before it. I didn't see how it would matter, but "it's hard telling, not knowing". So I tried it, the results didn't change... (how significant is the order of the lines following the "title" line in a grub.conf entry anyway???) I've been working under the assumption that the chainloader line must (when it's used) be the last line of the entry? Well anyway, here is that grub.conf, Thanks - -- | ~^~ ~^~ | <?> <?> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp@xxxxxxxx>> :r /boot/grub/grub.conf # grub.conf generated by anaconda AND edited by root... # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd1,3) # kernel /boot/vmlinuz-version ro root=/dev/hdc4 # initrd /boot/initrd-version.img #boot=/dev/hda default=1 timeout=100 splashimage=(hd1,3)/boot/grub/splash.xpm.gz title theWin98se rootnoverify (hd0,0) chainloader +1 title DrDos map (hd0) (hd1) map (hd1) (hd0) rootnoverify (hd1,0) chainloader +1 title theWanderlust (2.6.5-1.358) root (hd1,3) kernel /boot/vmlinuz-2.6.5-1.358 ro root=/dev/hdc4 rhgb quiet initrd /boot/initrd-2.6.5-1.358.img title theJourney root (hd1,2) kernel /boot/vmlinuz-2.4.22-1.2188.nptl ro root=/dev/hdc3 hdb=ide-scsi vga=normal initrd=/boot/initrd-2.4.22-1.2188.nptl.img title theVoyage root (hd0,2) kernel /boot/vmlinuz-2.4.21-0.13mdk ro root=/dev/hda3 devfs=mount hdb=ide-scsi acpi=off vga=normal initrd=/boot/initrd-2.4.21-0.13mdk.img title theVoid root (hd0,3) kernel /boot/vmlinuz._suse ro root=/dev/hda4 devfs=mount hdb=ide-scsi enableapic vga=normal initrd=/boot/initrd._suse title theBigTmp root (hd1,9) kernel /boot/vmlinuz-2.4.18-6mdk ro root=/dev/hdc10 devfs=mount hdb=ide-scsi vga=normal initrd=/boot/initrd-2.4.18-6mdk.img ############################################################## # You can find my public gpg key at http://pgpkeys.mit.edu/ # ############################################################## -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtJLfRZ/61mwhY94RAm+rAKCoLyRdTfgWKAtI3cDc3ReKN3lH1wCgrCmC i8nDcNuhqTFMoZo5GCZQAmQ= =mezY -----END PGP SIGNATURE-----