[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GRUB2 "drivemap -s" replaces GRUB "map()" and "liveswap"
From: |
Mellissa Dalby |
Subject: |
Re: GRUB2 "drivemap -s" replaces GRUB "map()" and "liveswap" |
Date: |
Thu, 11 Dec 2014 05:46:53 -0500 |
Hi Adrian,
Wow, thanks for the excellent explanation of how it works.
Yesterday I tried the command:
drivemap -s (hd0) (hd1)
and it worked OK for me.
It looks like it was a lack of understanding of GRUB2 causing me to fail.
My use case is I have an older (2007 Pentium D) system at work on which I
installed Fedora 20 on a separate disk.
I need to maintain the existing Windows XP system for development of one of the
company products.
Until Andrei explained the drivemap command to me, I could not boot to the
Windows disk without using my old (0.97) Super Grub Disk.
Now I have everything working with your help.
Thanks!
> On Dec 10, 2014, at 18:48, adrian15 <address@hidden> wrote:
>
> 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/
- GRUB2 support for "map()" and "liveswap", Mellissa Dalby, 2014/12/09
- Re: GRUB2 support for "map()" and "liveswap", Andrei Borzenkov, 2014/12/09
- Re: GRUB2 support for "map()" and "liveswap", Mellissa Dalby, 2014/12/09
- Re: GRUB2 support for "map()" and "liveswap", Andrei Borzenkov, 2014/12/09
- Re: GRUB2 support for "map()" and "liveswap", Mellissa Dalby, 2014/12/09
- Re: GRUB2 support for "map()" and "liveswap", Mellissa Dalby, 2014/12/09
- GRUB2 "drivemap -s" replaces GRUB "map()" and "liveswap", Mellissa Dalby, 2014/12/10
- Re: GRUB2 "drivemap -s" replaces GRUB "map()" and "liveswap", adrian15, 2014/12/11
- Re: GRUB2 "drivemap -s" replaces GRUB "map()" and "liveswap",
Mellissa Dalby <=