Bug 15191 - /boot/grub/device.map disregarded
Summary: /boot/grub/device.map disregarded
Status: RESOLVED WORKSFORME
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 4
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-03 12:16 CET by Ole Reier Ulland
Modified: 2015-07-03 19:27 CEST (History)
2 users (show)

See Also:
Source RPM: grub-0.97-39.mga4
CVE:
Status comment:


Attachments

Description Ole Reier Ulland 2015-02-03 12:16:39 CET
The computer in question is a Dell Dimension 8300, 32 bit, with a ATI RADEON 9200 PRO graphic card and 2 GB RAM. It has two HDDs, one HDD with Mageia 4.1, swap and data, and one HDD with Diagnostics partition, Windows XP and data.

SATA, Grub bootloader, sdb, hd0
Root, 0x83, ext4
Swap, 0x82, Linux swap
Data, 0x7, NTFS

IDE, Windows bootloader, sda, hd1
Dell Diagnostics, 0xde, Dell Utility
Windows, 0x7, NTFS
Data, 0x7, NTFS

When I swap the notations in /boot/grub/device.map it makes no difference at all. Linux gives the SATA disk, with Linux, the name sdb, and the IDE disk, with Windows, the name sda. /boot/grub/device.map holds (hd0) /dev/sda and (hd1) /dev/sdb. Still fdisk -l tells me that /dev/sda is the Windows disk and /dev/sdb is the Linux disk.

It looks to me like only when I reinstall the bootloader /dev/grub/device.map is read at all, and then only to correct the content. Because when I reinstall the bootloader the notations are changed back by that operation.

I have tried to change in /boot/grub/install.sh:

root (hd0,0)
setup --stage2=/boot/grub/stage2 (hd0)

into:

root (hd0,0)
setup --stage2=/boot/grub/stage2 (hd0,0)

The only change made was that this time the installation did not alter the contents of /boot/grub/device.map, it is still contrary to the information given by fdisk -l.

Reproducible: 

Steps to Reproduce:
Comment 1 Filip Komar 2015-02-03 12:59:24 CET
Disk numeration is different in "native" grub which appears when booting and grub "emulation" when grub is called from install or CLI or mcc.

Try following in "native" grub to see if your numeration is correct/expected:
find /etc/mageia-release

Answer will be something like:
(hdX, Y)

See bug 5076 and some useful forum threads like https://forums.mageia.org/en/viewtopic.php?f=7&t=1741&start=25#p27479.

CC: (none) => filip.komar

Comment 2 Ole Reier Ulland 2015-02-03 13:14:29 CET
grub> find /etc/mageia-release
 (hd1,0)

I hope that is helpful, because I do not understand what is going on. Is there something I can do to get all parts of Mageia to agree on which HDD is which?
Comment 3 Barry Jackson 2015-02-03 13:37:35 CET
(In reply to Ole Reier Ulland from comment #2)
> grub> find /etc/mageia-release
>  (hd1,0)
> 
> I hope that is helpful, because I do not understand what is going on. Is
> there something I can do to get all parts of Mageia to agree on which HDD is
> which?

Install grub2?
(best done from MCC->boot)
If it fails to add a correct entry for WinXP to the menu then you can add a manual entry to /boot/grub2/custom.cfg.
I have a similar mixed PATA/SATA 32bit system with Mageia, XP and Win 98 working this way with no problems due to updates, since /boot/grub2/custom.cfg is unaffected.

CC: (none) => zen25000

Comment 4 Filip Komar 2015-02-03 14:39:52 CET
(In reply to Ole Reier Ulland from comment #2)
> grub> find /etc/mageia-release
>  (hd1,0)

Your SATA disk is obviously seen as hd1 in grub so your IDE is _not_ hd1. Assuming you did run that command from "native" grub and not from the terminal (called grub shell). You should fix your device.map accordingly.
Comment 5 Ole Reier Ulland 2015-02-03 17:52:36 CET
In a terminal as root I wrote:

grub

then I got

grub>

I suppose that is grub shell then. "native" grub is then in rescue mode by a installation DVD?

menu.list says,

kernel (hd0,0)/boot...

and still,

grub> find /etc/mageia-release
 (hd1,0)

I have written that I have switched in device.map, but that has no effect on which hdx is which sdy.
Comment 6 Barry Jackson 2015-02-03 21:18:21 CET
You may find this interesting - from 2008 ;)
Read from here:
https://qa.mandriva.com/show_bug.cgi?id=44424#c17
Comment 7 Ole Reier Ulland 2015-02-05 11:31:15 CET
I do understand that I did not read the difference between "nativ" og "emulated" grub well enough, my bad.

But I have never had any problems with "menu.lst" when it comes to booting Mageia. The challenge is booting Windows and Dell Diagnostics. If there was a command in "native" grub that could tell me where to find Windows that could be nice, (1) is there? but at the same time the error message indicating the file system notation tells me that the correct Windows partition is attempted to be booted, but for some reason is does not work because grub does not recognize "0x7", which is NTFS, and labels it as a file system type unkown to grub, see bug 15190.

(2) Is there any difference between giving commands in "native" grub and in "menu.lst"?

(3) Are results of commands given in "native" grub lost when the computer is restarted?

I have had the understanding the "device.map" is only there to tell Mageia which of hdx to call which sdy, after it is up and running. But I am getting the feeling that this might not be the case, or (4) what is the purpose of "device.map"? because I have not been able to detect any difference in "device.map" have any impact on anything.

If the sdy's is not just a name system chosen to be used by Mageia for the actual hdx name system used by grub. (5) What is the sdy name system?

I have asked five questions in this message.
Comment 8 Filip Komar 2015-02-05 12:13:04 CET
This deviate from bug report more and more. Please use mailing list, irc or forum for support.

Last support answers from me here:
1. AFAIK not directly. You can see file system type tough.
2. AFAIK no.
3. AFAIK yes.
4. AFAIK it's used in grub shell and grub-install in some conditions.
5. Grub legacy and kernel see them differently.
Comment 9 Filip Komar 2015-05-05 08:22:43 CEST
Any news?

Keywords: (none) => NEEDINFO

Comment 10 Ole Reier Ulland 2015-07-03 18:38:05 CEST
Since grub clearly can not work in this case, I use grub2.
Comment 11 Filip Komar 2015-07-03 19:27:53 CEST
I guess we can close it then. Please reopen if need be.

Keywords: NEEDINFO => (none)
Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME


Note You need to log in before you can comment on or make changes to this bug.