[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB2 "drivemap -s" replaces GRUB "map()" and "liveswap"

From: adrian15
Subject: Re: GRUB2 "drivemap -s" replaces GRUB "map()" and "liveswap"
Date: Thu, 11 Dec 2014 00:48:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0


1) How map command worked in Grub Legacy

1.1) Running:

map (hd0) (hd1)
map (hd1) (hd0)

did nothing more than defining an array in memory with that mapping.

1.2) Booting:

Later only when there were no commands or you found boot string (from a grub config file) or when you typed boot string manually.

Two things were performed:

BIOS calls were invoked so that the actual mapping was done.
Boot continued.

2) MSDOS  / Windows being on the first hard disk

Windows 95 / 98 and MSDOS always wanted to be the first OS on the first hard disk. This could be changed if they thought they were in the first disk instead of the second one. Yes, you are right by using map commands.

3) Pre UUID era and grub menu.lst files

Back in the days when grub.cfg files did not exist and we used menu.lst not only partitions started at 0 instead of 1 but you could not use UUID (Yes, Ubuntu and other distros sort of hacked UUIDs into grub legacy but it was not perfect).

The Red Hat guys and company (Whatever CentOS was before CentOS) had an option to specify which was the hard disk order in Grub (and I think that SuSE too). In Debian and Ubuntu the installer did not have a such clear option.

So, let's suppose that you had two hard disks and your distro detects ok your Linux hard disk being the first one and uses (hd0,2) for accessing your sda3 partition.

What does happen if you want to boot from CDROM and the BIOS vendor does not know what he is doing and ... somehow your first hard disk becomes the second one and viceversa?

Grub does not know how to find the kernels to load.

4) Pre UUID era and USB

What if you boot a GRUB disk from a USB disk? What's the first hard disk? The USB one, of course, because it's the first to boot.

You might infer the rest of the history, you try to load grub menu.lst from your internal hard disk but as it's the second hard disk it cannot load the kernel.

5) Liveswap

What if you could invoke the BIOS calls so that your first hard disk and second hard disk are swapped right now so that your menu.lst works as always?

That's liveswap!

6) Usbshift

What if you could invoke the BIOS calls so that your usb booted hard disk or pendrive is setup as the last hard disk and the rest of the them are shifted to the left.

That's usbshift.

Before: usb0 hdd0 hdd1 hdd2
After: hdd0 hdd1 hdd2 usb0

7) Post UUID era - GNU/Linux

Both grub2 and Linux kernel use UUIDs nowadays and the hard disk order no longer matters.

8) Post UUID era - Windows

Liveswap could be useful nowadays if you cannot boot your Windows ok because it's not finding itself as the first hard disk. But usually you won't need it because Windows no longer depends on BIOS calls to boot.

9) Post UUID era - USB

Usbshift could be also handy for booting Windows from a usb without the need of specifing manually the drivemap commands.

10) Post virtualization era

Being there so many virtual pcs there is not so much need of dealing with two hard disk scenarios. So, this is not a problem like it was in the old days.

11) If you are interested you can find Super Grub Disk's fork of grub in dev_grub folder in its source code which can be found at this torrent:

This source code implements among many other things usbshift and liveswap. I did not use any VCS back in the time, so you will have to manually diff to 0.97 version from Debian or the upstream one I guess.

Anyways as I have said you can probably write them from scratch based on the mini algorithm describing them.

12) Does a normal user need liveswap or usbshift functionality in grub2?

12.1) If drivemap does what I have explained liveswap does then it already has it. 12.2) There's a command to parse old menu.lst files. It might be handy for it.
12.3) It should not be needed because of menu.lst (Now we use UUID).

13) Back in the days people was impressed that the liveswap and usbshift commands worked. I suspect that invoking these BIOS calls is not very recommended because of execution runtime switchs (Sorry I don't like the right word, it's something about changing from protected code to non protected or similar and I think it involved some assembly code).

14) Mellissa: If you have not installed Super Grub Disk grub manually you probably have used the wiki page as a reference and grub has just ignored the wrong command liveswap.

What I mean is that if you use map just before a boot entry it does its job, the only place where liveswap is needed is when you want grub to interpret differently its configuration files based on a new BIOS boot order.

15) I think that grub2 uses more and more its own methods for accesing files instead of asking for them to the BIOS. So, these special commands would make less sense.

16) Super Grub2 Disk is based on Grub2 so it already includes drivemap. No need to include it. Another thing is if the Super Grub2 Disk scripts do a good job of booting a Windows installation if it's in a first hard disk or if it's in a second hard disk. You can test it and report feedback to us on e.g. our forum.

17) In the last Grub2 2.02 there are some commands that change what the devices are being read by Grub2 but without changing its names.

E.g. hd0, hd1 are still the first and second hard disk but not being read by using BIOS calls but using the internal Grub2 PATA driver.

I don't remember the command but I issued a bug about it.

That might be another way of implementing the command if we did not care about Windows finding itself as the first OS but only about the grub configuration files (hd0 being read as hd1 and viceversa) but as I said above in most cases it does not matter at all.

18) Mellissa: What's your specific usecase for using drivemap command ?

Hopefully all this long text gives you context on these lost commands: usbshift and liveswap. And, who knows, you might find some of their ideas as being useful nowadays and implement them ;).


El 10/12/14 a las 11:10, Mellissa Dalby escribió:
Hi Andrei,
You are correct.
Drivemap worked as expected.

Thanks very much for pointing me to the new command.

They should add it to the Super Grub Disk project.

On Dec 9, 2014, at 14:06, Andrei Borzenkov <address@hidden> wrote:

В Tue, 9 Dec 2014 13:52:44 -0500
Mellissa Dalby <address@hidden> пишет:

Hi Andrei,
The "map()" and "liveswap" commands were working in the legacy GRUB (version 
0.97 I think).
They somehow make it possible to work around BIOS limitations in older systems 
that prevent the GRUB Bootloader from vectoring off to another hard disk to 

/dev/sda1       /boot   GRUB
/dev/sda2       /   LINUX boots OK

/dev/sdb1      Windows no boot!

Grub entries using "map()" and "liveswap":

map (hd0) (hd1)
map (hd1) (hd0)

I have never heard about liveswap, but drivemap command in grub2 should
do what you need.

drivemap -s (hd0) (hd1)

Somehow fools the BIOS into believing /dev/sdb1 is actually /dev/sda1.

I don't know how it does that because I never fetched the legacy GRUB source 

On Dec 9, 2014, at 13:23, Andrei Borzenkov <address@hidden> wrote:

В Tue, 9 Dec 2014 05:51:22 -0500
Mellissa Dalby <address@hidden> пишет:

Hi GRUB community,
GRUB has become my Bootloader of choice.
I do like the development progression of GRUB2 but I STILL NEED "map()" and

Could you explain what they do? Any links to description or

to support existing hardware.

PLEASE consider adding it to GRUB2.

Help-grub mailing list

Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]