[Karmic] update-grub creates incorrect entry for FreeDOS

[Roland Hughes]

After most recent update update-grub finally completes. When I run it I see the following:

roland@logikaldesktop:~$ sudo update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.31-3-generic
Found initrd image: /boot/initrd.img-2.6.31-3-generic
Found memtest86+ image: /boot/memtest86+.bin
Found FreeDOS on /dev/sdb1
done

The problem is it creates the following entry:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "FreeDOS (on /dev/sdb1)" {
 set root=(hd1,1)
 search --no-floppy --fs-uuid --set 3137-16f9
 drivemap -s (hd0) ${root}
 chainloader +1
}
### END /etc/grub.d/30_os-prober ###

Neither Grub nor Karmic are seeing the SATA drives in the same order as the BIOS. FreeDOS was installed on the first hard drive, which is a SATA 250. The other two hard drives are SATA 1TB. Both grub and Karmic are seeing the drives as 1TB, 250, 1TB. Sorry, I don't have a different sized SATA to install so we can easily identify which drive Grub/Karmic are seeing first.

The order is completely consistent.

As a result of this discombobulation, FreeDOS cannot be booted. It is trying to map the drives via the BIOS and the Grub mapping really hoses things.

roland@logikaldesktop:~$ lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10

roland@logikaldesktop:~$ apt-cache policy grub-pc
grub-pc:
  Installed: 1.96+20090725-1ubuntu2
  Candidate: 1.96+20090725-1ubuntu2
  Version table:
 *** 1.96+20090725-1ubuntu2 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

[Steven Harms (sharms)]

Thank you for taking the time to report this bug. Can you try this out on Karmic Alpha 6 and see if it is still an issue?

[Roland Hughes (original-seasoned-geek)]

I tried it yesterday, after applying all updates, still an issue.

SATA drives are not identified in correct order.

On Sunday 27 September 2009 12:26:54 pm Steven Harms wrote:
> Thank you for taking the time to report this bug. Can you try this out
> on Karmic Alpha 6 and see if it is still an issue?
>
> ** Changed in: grub2 (Ubuntu)
> Status: New => Incomplete
>

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.logikalsolutions.com

[Colin Watson (cjwatson)]

Looks to me as if we're trying to map a partition to a drive, which doesn't seem likely to work very well.

[Roland Hughes (original-seasoned-geek)]

The problem is the nearly random choice for the first SATA drive in your list.
If you identified the drives the same way the BIOS (or DOS for that matter) (or
Linux prior to this kernel) did, the first boot drive would be the same first
boot drive as mapped by the BIOS. All would be right with the world.

On Sunday 27 September 2009 03:45:14 pm Colin Watson wrote:
> Looks to me as if we're trying to map a partition to a drive, which
> doesn't seem likely to work very well.
>
> ** Changed in: grub2 (Ubuntu)
> Status: Incomplete => Triaged
>
> ** Changed in: grub2 (Ubuntu)
> Importance: Undecided => Medium
>

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.logikalsolutions.com

[Colin Watson (cjwatson)]

As I've explained elsewhere, in general it's impossible to determine
BIOS ordering from outside the BIOS (or at least once you get into a
non-real-mode operating system). Our intent is to search and destroy all
places where GRUB relies on BIOS ordering.

I'm fairly sure you disagree with me here. That's fine - I'm not out to
get the whole world to agree with me. My approach is based on bitter
practical experience trying and failing to get your approach to work
reliably everywhere.

[Roland Hughes (original-seasoned-geek)]

You know, I hear statements like that, then I look at FreeDOS, PCDOS-2000, and
yes, even that pathetic Windows product, and they can all do it.

On Sunday 27 September 2009 05:15:59 pm Colin Watson wrote:
> As I've explained elsewhere, in general it's impossible to determine
> BIOS ordering from outside the BIOS (or at least once you get into a
> non-real-mode operating system). Our intent is to search and destroy all
> places where GRUB relies on BIOS ordering.
>
> I'm fairly sure you disagree with me here. That's fine - I'm not out to
> get the whole world to agree with me. My approach is based on bitter
> practical experience trying and failing to get your approach to work
> reliably everywhere.
>

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.logikalsolutions.com

[Roland Hughes (original-seasoned-geek)]

If Grub does not respect the BIOS, then there is no need for Grub to bother
putting any other OS on the menu. We will all simply have to use LILO or some
other boot manager.

All other OSs on all other machine respect the BIOS when it comes to device
ordering. Even OS/2 did that, which is why it had a bootmanager package which
installed on its own 1.2Meg partition.

On Sunday 27 September 2009 05:15:59 pm Colin Watson wrote:
> As I've explained elsewhere, in general it's impossible to determine
> BIOS ordering from outside the BIOS (or at least once you get into a
> non-real-mode operating system). Our intent is to search and destroy all
> places where GRUB relies on BIOS ordering.
>
> I'm fairly sure you disagree with me here. That's fine - I'm not out to
> get the whole world to agree with me. My approach is based on bitter
> practical experience trying and failing to get your approach to work
> reliably everywhere.
>

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.logikalsolutions.com

[Colin Watson (cjwatson)]

I'm not going to engage in a discussion with this tone. I will simply
keep the bug on the list and address it in due time.

[Roland Hughes (original-seasoned-geek)]

It's not a matter of tone.

I'm simply pointing out that most other multi-os boot engines/menus/etc.
identify the drives in the same order as the BIOS and will even respect any
BIOS remapping which has occurred. Grub does not. Anyone with multiple SATA
drives and DOS, Windows, or other BIOS respecting OSes on them will have to
use a boot manager other than Grub if they ever want to use those operating
systems after installing Ubuntu.

On Monday 28 September 2009 01:46:36 am Colin Watson wrote:
> I'm not going to engage in a discussion with this tone. I will simply
> keep the bug on the list and address it in due time.
>

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.logikalsolutions.com

[Roland Hughes (original-seasoned-geek)]

Actually, while we are on this topic, you should dig up a copy of OS/2 Warp
4.5 and take a look at the boot manager IBM had shipping with it. Even on
small things IBM tended to provided professional grade solutions. The 1.2Meg
boot partition for the boot manager was actually genius.

What is the primary flaw of most boot managers today, including grub?

They aren't optically isolated from OS media problems. Windows based boot
managers, and grub are useless if their preferred OS boot partition gets
shanked. Grub error 17 is both infamous and world renowned.

Few things are more frustrating than having gone to all of the trouble of
creating a special "backup/recovery tools" type partition on a different disk
specifically so you could fix problems then not be able to boot it because the
scrambled partition you need to fix happens to have files for the boot manager.

When the boot manager has its own partition, that partition can be on a
different drive for added security and stability.

I cannot tell you the number of times I've seen Grub Error 17 between Ubuntu
and OpenSuSE.

On Monday 28 September 2009 02:03:23 am seasoned_geek wrote:
> It's not a matter of tone.
>
> I'm simply pointing out that most other multi-os boot engines/menus/etc.
> identify the drives in the same order as the BIOS and will even respect any
> BIOS remapping which has occurred. Grub does not. Anyone with multiple
> SATA drives and DOS, Windows, or other BIOS respecting OSes on them will
> have to use a boot manager other than Grub if they ever want to use those
> operating systems after installing Ubuntu.
>
> On Monday 28 September 2009 01:46:36 am Colin Watson wrote:
> > I'm not going to engage in a discussion with this tone. I will simply
> > keep the bug on the list and address it in due time.
>

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.logikalsolutions.com

[Colin Watson (cjwatson)]

Linux doesn't enumerate devices in any particular order, and so GRUB
simply does not have the necessary information to reproduce BIOS drive
ordering. The boot loader installer is reliant on the operating system
to acquire information about drive ordering.

[Roland Hughes (original-seasoned-geek)]

Anybody with 2 or more SATA drives will not be able to install this version of
Ubuntu.

On Monday 28 September 2009 03:47:24 am Colin Watson wrote:
> Linux doesn't enumerate devices in any particular order, and so GRUB
> simply does not have the necessary information to reproduce BIOS drive
> ordering. The boot loader installer is reliant on the operating system
> to acquire information about drive ordering.
>

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.logikalsolutions.com

[tz (thomas-mich)]

I've confirmed this and reported a variant (though not duplicate).

/etc/grub/30_osprobe will NOT find a true DOS (in this case Win98) on a usb key which I use for multiboot.
(it also finds all the partitions on the system I happen to be on but really don't want).

So the more general problem is that the OS probe/generation is badly broken in Grub2 - and there is little if any documentation at the expected sites.

This is what blkid gives for the partition:

/dev/sdb1: SEC_TYPE="msdos" LABEL="DOSBOOT" UUID="40F0-5A79" TYPE="vfat"

To boot, I eventually figured out that I needed one line:

chainloader (hd0,1)+1

within the menu section. There may be a way to use the search thingy to get the UUID, but this was a trivial edit in grub 1.

Yes, it uses the BIOS enumeration. There is nothing I can find that properly translates it within Grub. The BIOS typically puts the boot device first. Linux or other OSes will do in a different ordre

The CLI and commands are partially documented at: http://members.iinet.net/%7Eherman546/p20.html - it is the best source.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Launchpad Janitor (janitor)]

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]