FreeDOS won't boot with Grub

Prior to the last re-install of OpenSuSE 11.1 64-bit I installed FreeDOS on a primary FAT-32 partition on the first hard drive. I then re-installed OpenSuSE 11.1 and restored some data partitions. Now, when I try to boot FreeDOS, the boot, starts and then fails when looking for the shell in C:blahblahblah.

I’ve tried some of the switches from within Yast for making the partition active, mapping, etc. Not feeling a lot of love.

On IDE I have my DVD master and ls-120 slave.
SATA drives:

OpenSuSE is happy happy joy joy with things, but FreeDOS has issues.

I believe part of the problem is the fact that one of the 1TB drives appears ahead of the 250 in the OpenSuSE hardware list, but not in the BIOS. I don’t know why, but OpenSuSE seems to sort these funny.

volume.mount_point = ‘/db_data’
volume.label = ‘’
info.product = ‘Volume (ext3)’
linux.sysfs_path = ‘/sys/devices/pci0000:00/0000:00:07.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb8’

volume.mount_point = ‘/windows/C’
volume.label = ‘FREEDOS’
info.product = ‘FREEDOS’
linux.sysfs_path = ‘/sys/devices/pci0000:00/0000:00:08.0/host4/target4:0:0/4:0:0:0/block/sdc/sdc1’

It’s not a massive issue, but it would be nice to actually get this working. There are times when I would like to boot into DOS to run things. No, the two DOS options under OpenSuSE don’t work for those things. One has great control of floppy drives, but lousy everything else. The other only provides access to floppy drives which are already mounted by OpenSuSE. Neither work well for installation or other procedures which require floppy changes and a fully functional system.

How about posting /boot/grub/menu.lst?

roland@linux-j7oz:~> sudo cat /boot/grub/menu.lst
root’s password:

Modified by YaST2. Last modification on Tue Jun 30 10:05:07 CDT 2009

default 0
timeout 8
gfxmenu (hd0,2)/boot/message
##YaST - activate

###Don’t change this comment - YaST2 identifier: Original name: linux###
root (hd0,2)
kernel /boot/vmlinuz root=/dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1KLA02487-part3 resume=/dev/disk/by-id/ata-WDC_WD10EACS-00ZJB0_WD-WCASJ1139194-part5 splash=silent showopts
initrd /boot/initrd

###Don’t change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe – SUSE LINUX
root (hd0,2)
kernel /boot/vmlinuz root=/dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1KLA02487-part3 showopts ide=nodma apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe
initrd /boot/initrd

title FreeDOS
rootnoverify (hd0,0)
chainloader +1

linux-j7oz:/home/roland # fdisk -l

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000553e3

Device Boot Start End Blocks Id System
/dev/sdb1 1 243 1951866 82 Linux swap / Solaris
/dev/sdb2 244 121601 974808135 5 Extended
/dev/sdb5 244 2675 19535008+ 82 Linux swap / Solaris
/dev/sdb6 2676 20668 144528741 83 Linux
/dev/sdb7 20669 81456 488279578+ 83 Linux
/dev/sdb8 81457 121601 322464681 83 Linux

Disk /dev/sdc: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0005713f

Device Boot Start End Blocks Id System
/dev/sdc1 1 1020 8193118+ b W95 FAT32
/dev/sdc2 3825 30401 213479752+ f W95 Ext’d (LBA)
/dev/sdc3 * 1021 3824 22523130 83 Linux
/dev/sdc5 3825 30401 213479721 c W95 FAT32 (LBA)

Partition table entries are not in disk order

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000cf7ab

Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 83 Linux

I noticed like you that the FREEDOS disk is mapped to sdc. And from the GRUB menu.lst it looks like hd0 is sdb. As I recall, FREEDOS wants to be on the primary disk. You may have to play around with some GRUB directives to make hd0 map to that 250GB disk at boot time, just for that OS.

Grub directives aren’t going to fix this. I believe it is a bug in OpenSuSE. The only reason for OpenSuSE to place that 1TB drive in the front is that it holds the SWAP areas. It shouldn’t do this. It should respect the BIOS order, but for whatever reason it isn’t.

I think I need to do an image backup, resize stuff on the 250 to make room for a SWAP partition, then remove the other SWAP partitions. I’m guessing that will fix all problems.

Ubuntu didn’t have this problem. It is specific to OpenSuSE and seems to be related to SWAP. I was always taught to put TMP and SWAP type areas on different spindles to boost over-all system performance. It appears someone in OpenSuSE development always wants the SWAP drive first in the list.

I’ve tried every possible combination of mapping and making things active.

But when you are booting from cold there is no openSUSE running. The mapping is set in grub from the file in /boot/grub. It maybe just that the openSUSE boot installer sets whatever order it deems appropriate, which may not be what you want for FREEDOS. Have you tried some map directives for that stanza?

PS: Try this suggestion, from info grub:

– Command: map to_drive from_drive
Map the drive FROM_DRIVE to the drive TO_DRIVE. This is necessary
when you chain-load some operating systems, such as DOS, if such
an OS resides at a non-first drive. Here is an example:

      grub> map (hd0) (hd1)
      grub> map (hd1) (hd0)

 The example exchanges the order between the first hard disk and the
 second hard disk. See also *note DOS/Windows::.

I saw that documentation as well. I believe I tried it at one point, but don’t remember. I know I’ve tried every option you could do directly from YAST.

While this is all well and good, the basic problem is that a tiny portion of Linux must actually be running, and causing the drive swapping. If it wasn’t, Grub couldn’t access menu.lst or the other files it needs which reside in the root device.

I know this much, if you choose BOTH map and make active, you never get grub to appear again.

I will see if I have time tomorrow to back this beast up (not a simple task with 2TB of storage) and migrate the swap to the 250, then install a new bootloader. My guess is the root of this poblem is a bug in OpenSuSE which shows up when swap is on a different drive than root.

I deliberatly placed all of my boot areas on the 250 to avoid this specific problem.

No, there is no “tiny portion of Linux running”. GRUB knows enough about filesystems to read the files directly. Have a look at /boot/grub. You will see various stage1.5 files. These are the secondary bootloaders that GRUB installs, depending on what filesystem holds the boot files, to access the kernel of whatever OS is to be booted. Unless you are chainloading another bootloader.

So it’s purely a GRUB or GRUB setup issue. Linux is not involved at boot time.

BTW those map commands are meant to be put in the FREEDOS stanza, not in the global section. If you put them in the global section then obviously they will wreck the booting of the other OSes. You can test them out from the grub interactive CLI as shown in info grub.

Well, this has been a significant waste of my evening. Lots of backing up, lots of restoring, no fixy.

Yes, there is a “tiny piece of Linux” running with Grub. It is the same piece used by Partition Commander 10, System Rescue Disk 1.2.0, and quite a few other things. It is that tiny piece which allows access to the SATA drives and allows things to boot from beyond cylinder 1024.

The SATA portion of that code is broken. It does not respect the BIOS drive order. Every product I tried which had some form of Linux image boot put the drives in the same order. Out of frustration I swapped the cable ends between the second (250) and the third (1TB) drive and rebooted. BIOS has 250 as third drive in SATA chain. Grub, OpenSuSE, Partition Commander 10, and System Rescue CD 1.2.0 ALL have the 250Gig SATA as the first boot drive.

The BIOS identifies SATA drives in FIFO order. This little piece of code identifies SATA drives in LIFO order. There is no amount of “mapping” which is going to “fix” this for FreeDOS which is trying to identify the boot device via an INT21 or BIOS call.

People who have only one SATA drive don’t have the problem. If I had another SATA drive of a different size I could prove this bottom up thing beyond a shadow of a doubt.

bug bug bug bug bug

Test it yourself. Install 3 different SATA drives all with different sizes. To keep things simple, put them in ascending size order connection wise so they show up that way in the BIOS. Verify order in BIOS, boot a live CD of System Rescue CD 1.2.0 or OpenSuSE 11.1 64-bit. Open the partition tool in either and take a look at how the drives show up. I guess you could also use fdisk -l.

bug bug bug bug bug

It’s not a tiny bit of Linux. GRUB is a project independent of Linux that works for many different OSes. Some of the code may be similar to code elsewhere, after all there are only so many variations on how to do the same job.

The 1024 cylinder limit is about 15 years old. Any BIOS with this limit would probably be on a Pentium-II at newest. However I cannot say whether GRUB needs to do anything special for SATA drives. There is also no such thing as a “SATA chain”. Each drive has its own connection to the controller. No master/slave stuff. But certainly there is an enumeration order.

If you believe you have found a bug, whether in the openSUSE version, which has been modified to do the splash screen and other things, or in the upstream version, by all means report it at

It is a little piece of Linux. Grub may be considered an independent project but it started with the same code. Saying it isn’t a “little piece of Linux” is like tobacco companies claiming “ciggies are not addictive”. While it may fit well with the PR campaign, it simply isn’t true.

The 1024 cylinder limit has more to do with the addressing mode of the drive than the age of the BIOS. It still exists in today’s BIOS when the older IDE addressing methods are used. It is a physical limit of the addressing method.

Here is a pretty decent writeup on it:
Large Disk HOWTO: History of BIOS and IDE limits

This is definitely a BUG in the base line. It must be fixed in both Grub and the Linux kernel.

You should have been a lawyer for SCO… :sarcastic:

A lawyer!?!?!?!

I guess it could have been worse, you could have said I worked for Microsoft.

SCO was stupid. All they had to do was horde their cash and wait for Novell to get in bed with Microsoft again. Novell goes out of business every time they do that.

Former DR-DOS user here.