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

[adrian15]

Hi!

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.

Example:
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:

http://linuxtracker.org/index.php?page=downloadcheck&id=34a256ec86bee876434cdf375e7591bf8d23d464

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 ;).

adrian15

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 
> > > boot.
> > >
> > > For EXAMPLE:
> > > /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)
> > > liveswap
> >
> > 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 
> > > code.
> > >
> > >
> > >
> > >
> > > > 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
> > > > > "liveswap"
> > > >
> > > > Could you explain what they do? Any links to description or
> > > > implementation?
> > > >
> > > > > to support existing hardware.
> > > > >
> > > > > PLEASE consider adding it to GRUB2.
>
> _______________________________________________
> Help-grub mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-grub

--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/