[Bug 907457] New: perl-bootloader: pbl-8400.2 Core::GRUB2::GrubDev2UnixDev.252: Error: did not find a match for hd0 in the device map
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Bug ID: 907457 Summary: perl-bootloader: pbl-8400.2 Core::GRUB2::GrubDev2UnixDev.252: Error: did not find a match for hd0 in the device map Classification: openSUSE Product: openSUSE Factory Version: 201411* Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Basesystem Assignee: snwint@suse.com Reporter: mpluskal@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 615222 --> http://bugzilla.opensuse.org/attachment.cgi?id=615222&action=edit pbl.log When updating openSUSE-Factory, following error appears: pbl-8400.2 Core::GRUB2::GrubDev2UnixDev.252: Error: did not find a match for hd0 in the device map Error however seems to be harmless. # cat /boot/grub2/device.map (hd1) /dev/sda # cat /boot/grub2/device.map.old (hd1) /dev/sda (hd0) /dev/sdb (hd2) /dev/sdc -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Steffen Winterfeldt <snwint@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mchang@suse.com Flags| |needinfo?(mchang@suse.com) --- Comment #1 from Steffen Winterfeldt <snwint@suse.com> --- You 'forgot' to mention that you also changed your disks in between. But it's not clear why the 2nd disk doesn't show up in device.map. Anyway, the file is created by grub2 but not strictly necessary, afaik. So we might just make this message a warning. Michael, what do you think? Can we ignore this? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #2 from Martin Pluskal <mpluskal@suse.com> --- (In reply to Steffen Winterfeldt from comment #1)
You 'forgot' to mention that you also changed your disks in between. Well actually I only created partition table on /dev/sdb, otherwise disks are same as when system was installed.
I also forgot to mention that installation was from USB flash - therefore when system was installed, there were sda,sdb and sdc present
But it's not clear why the 2nd disk doesn't show up in device.map.
Anyway, the file is created by grub2 but not strictly necessary, afaik. So we might just make this message a warning.
Michael, what do you think? Can we ignore this?
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #3 from Martin Pluskal <mpluskal@suse.com> --- Created attachment 615247 --> http://bugzilla.opensuse.org/attachment.cgi?id=615247&action=edit y2logs -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |snwint@suse.com Flags| |needinfo?(snwint@suse.com) --- Comment #4 from Michael Chang <mchang@suse.com> --- During install, the usb disk was assigned sda while the installation was to sdb '/dev/disk/by-id/scsi-1PHISON_USB3' => '/dev/sda', '/dev/disk/by-id/ata-SanDisk_SDSSDRC032G_125216400243' => '/dev/sdb' '/dev/disk/by-id/ata-ST2000DM001-1CH164_Z1E524FW' => '/dev/sdc' The initial device.map (hd1) /dev/sda (hd0) /dev/sdb (hd2) /dev/sdc Until the USB got removed, the sdb becomes sda and the problem happened. 2014-11-25 19:43:10 <1> pbl-yaml-3915.1 Library::DefineUdevMapping.428: udevmap = '/dev/disk/by-id/ata-ST2000DM001-1CH164_Z1E524FW' => '/dev/sdb' '/dev/disk/by-id/ata-SanDisk_SDSSDRC032G_125216400243' => '/dev/sda' and above device.map translated it to (hd1) ... And since sdb had no partition, it's not listed in "partitions" output in the first place and therefore got ignored. The trouble was caused by using kernel device name in device.map because it is floating by nature. The installation seems not affected as it's referring to /etc/grub_installdevice which uses by-id device name. But if you tried other options in yast2 bootloader, for ex, reinstall mbr boot code would not work as long as the hd0 device is now missing or wrong in device.map. My question is how legacy-grub handles such kernel device name changes and how can device.map react to it .. ? Steffen do you know ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Steffen Winterfeldt <snwint@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(snwint@suse.com) | --- Comment #5 from Steffen Winterfeldt <snwint@suse.com> --- As long as you're sticking to persistent device names like by-id, you should be fine. If you think the only issue here is using kernel device names instead of persistent ones I'll close this bug as invalid. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Martin Pluskal <mpluskal@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |locilka@suse.com --- Comment #6 from Martin Pluskal <mpluskal@suse.com> --- (In reply to Steffen Winterfeldt from comment #5)
As long as you're sticking to persistent device names like by-id, you should be fine.
If you think the only issue here is using kernel device names instead of persistent ones I'll close this bug as invalid.
Why would you consider misleading/unnecessary error printed out INVALID? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #7 from Steffen Winterfeldt <snwint@suse.com> --- Because it happens on an unsupported setup. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #8 from Martin Pluskal <mpluskal@suse.com> --- (In reply to Steffen Winterfeldt from comment #7)
Because it happens on an unsupported setup.
Since when is installation from usb unsupported? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #9 from Steffen Winterfeldt <snwint@suse.com> --- That's not what I said. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #10 from Martin Pluskal <mpluskal@suse.com> --- (In reply to Steffen Winterfeldt from comment #9)
That's not what I said.
OK, what exactly is unsupported here? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #11 from Martin Pluskal <mpluskal@suse.com> --- (In reply to Martin Pluskal from comment #10)
(In reply to Steffen Winterfeldt from comment #9)
That's not what I said.
OK, what exactly is unsupported here?
Also why do you assume that this unsupported situation was created by user intervention? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #12 from Steffen Winterfeldt <snwint@suse.com> --- I didn't say that neither. Although the default is by-id. Can you come down a bit? All I said is that _if_ this is a case of kernel names vs. by-id I close this bug. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #13 from Lukas Ocilka <locilka@suse.com> --- What I see from the beginning is this --- cut --- Error: did not find a match for hd0 in the device map --- cut -- An error, which turns out not to be an error (?) as the system can still recover from that well. In that case it should just be a warning. On the other hand, if system is installed from USB (which is a supported scenario and BTW very common in these days), then our system should not be surprised by "not finding it" later. The bug is real and thus not invalid, that's what Martin is trying to say and that's what he objects to. All in all, some change is needed and the bug is not invalid. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #14 from Steffen Winterfeldt <snwint@suse.com> --- I never said it is, but it might be. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #15 from Michael Chang <mchang@suse.com> --- On pc-bios platform, perl bootloader historically uses hd0 grub device provided by device.map as the MBR device to install. The device.map was created by YaST during installation time, iirc. So this can be yast related ?? The issue here can be fixed if by-id names is used in device.map. I vaguely remember in openSUSE it should had been using by-id name in device.map, but I'm not really sure and I'll check it. And how to correct such errors via maintenance update ? User has to correct the device.map manually to reflect their (setup) changes anyway, so in this regard it looks like "won't fix" or invalid. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #16 from Martin Pluskal <mpluskal@suse.com> --- (In reply to Michael Chang from comment #15)
On pc-bios platform, perl bootloader historically uses hd0 grub device provided by device.map as the MBR device to install. The device.map was created by YaST during installation time, iirc. So this can be yast related ??
The issue here can be fixed if by-id names is used in device.map. I vaguely remember in openSUSE it should had been using by-id name in device.map, but I'm not really sure and I'll check it.
And how to correct such errors via maintenance update ? Who is talking/requesting maintenance update here? User has to correct the device.map manually to reflect their (setup) changes anyway, so in this regard it looks like "won't fix" or invalid.
It is my understanding that device.map containing kernel device name should not be created at all - but apparently this has happened, and since system was installed about two weeks ago, it is not unreasonable to expect that whatever caused it is still present. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 --- Comment #17 from Michael Chang <mchang@suse.com> --- (In reply to Martin Pluskal from comment #16)
(In reply to Michael Chang from comment #15)
And how to correct such errors via maintenance update ? Who is talking/requesting maintenance update here?
No one. Just to clarify the request here.
User has to correct the device.map manually to reflect their (setup) changes anyway, so in this regard it looks like "won't fix" or invalid.
It is my understanding that device.map containing kernel device name should not be created at all - but apparently this has happened, and since system was installed about two weeks ago, it is not unreasonable to expect that whatever caused it is still present.
I'm now looking into this as this is not what I expected also. Meanwhile, a better fix for me is to think a better solution to not creating device.map for knowing mbr device. Can we replace current approach with a mbrdisk=/dev/disk-by-id/ ... in /etc/default/grub_installdevice ? Grub2 doesn't require (hdX) names as root device, as it searches file system uuid and bios disk order really doesn't matter for it. It only affects device to embed bootloader images (that is the device to be used in grub2-install) and also reinstall mbr or such. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jreidinger@suse.com Flags| |needinfo?(jreidinger@suse.c | |om) --- Comment #18 from Michael Chang <mchang@suse.com> --- Anyway, the device.map is initially set by yast from the BootStorage.device_mapping. Josef, do you have any idea ? Is the kernel device name expected ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Josef Reidinger <jreidinger@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jreidinger@suse.c | |om) | --- Comment #19 from Josef Reidinger <jreidinger@suse.com> --- (In reply to Michael Chang from comment #18)
Anyway, the device.map is initially set by yast from the BootStorage.device_mapping.
Josef, do you have any idea ? Is the kernel device name expected ?
Thanks.
yast2-bootloader uses mount_by option to use persistent names. So if fstab contain by-id then device.map should be also by-id. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpluskal@suse.com Flags| |needinfo?(mpluskal@suse.com | |) --- Comment #20 from Michael Chang <mchang@suse.com> --- Hi Martin, Can you attach your /etc/fstab for reference ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Martin Pluskal <mpluskal@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mpluskal@suse.com | |) | --- Comment #21 from Martin Pluskal <mpluskal@suse.com> --- (In reply to Michael Chang from comment #20)
Hi Martin,
Can you attach your /etc/fstab for reference ? Thanks.
Well machine has been re-installed since issue occured, but according to yast log it was following after installation: UUID=401da6ed-9159-40a9-a080-31f6638c3a66 swap swap defaults 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc / btrfs defaults 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /home btrfs subvol=home 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /opt btrfs subvol=opt 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /srv btrfs subvol=srv 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /tmp btrfs subvol=tmp 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /usr/local btrfs subvol=usr/local 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/crash btrfs subvol=var/crash 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/lib/mailman btrfs subvol=var/lib/mailman 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/lib/named btrfs subvol=var/lib/named 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/lib/pgsql btrfs subvol=var/lib/pgsql 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/log btrfs subvol=var/log 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/opt btrfs subvol=var/opt 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/spool btrfs subvol=var/spool 0 0 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/tmp btrfs subvol=var/tmp 0 0 and also according to logs last version was: AsciiFile.cc(save):101 saving file /etc/fstab AsciiFile.cc(save):92 deleting file /etc/crypttab AsciiFile.cc(reload):62 loading file /etc/fstab AsciiFile.cc(logContent):119 content of /etc/fstab AsciiFile.cc(logContent):121 UUID=401da6ed-9159-40a9-a080-31f6638c3a66 swap swap defaults 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc / btrfs defaults 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /opt btrfs subvol=opt 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /srv btrfs subvol=srv 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /tmp btrfs subvol=tmp 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /home btrfs subvol=home 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /usr/local btrfs subvol=usr/local 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/crash btrfs subvol=var/crash 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/lib/mailman btrfs subvol=var/lib/mailman 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/lib/named btrfs subvol=var/lib/named 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/lib/pgsql btrfs subvol=var/lib/pgsql 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/log btrfs subvol=var/log 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/opt btrfs subvol=var/opt 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/spool btrfs subvol=var/spool 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /var/tmp btrfs subvol=var/tmp 0 0 AsciiFile.cc(logContent):121 UUID=3346482b-e201-4f14-bf36-f8fa7f16acbc /.snapshots btrfs subvol=.snapshots 0 0 AsciiFile.cc(logContent):121 /dev/storage/volume /srv/images xfs defaults 1 2 -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com