dual boot : fed1 and fed2 no go
Joe(theWordy)Philbrook
jtwdyp at ttlc.net
Wed May 26 12:53:12 UTC 2004
-----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 at ttlc.net>>
: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-----
More information about the fedora-list
mailing list