http://bugzilla.opensuse.org/show_bug.cgi?id=907457 Steffen Winterfeldt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mchang@suse.com Flags| |needinfo?(mchang@suse.com) --- Comment #1 from Steffen Winterfeldt --- 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 #3 from Martin Pluskal --- 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 Steffen Winterfeldt changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(snwint@suse.com) | --- Comment #5 from Steffen Winterfeldt --- 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 --- Comment #7 from Steffen Winterfeldt --- 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 #9 from Steffen Winterfeldt --- 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 #11 from Martin Pluskal --- (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 #13 from Lukas Ocilka --- 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 #15 from Michael Chang --- 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 #17 from Michael Chang --- (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 Josef Reidinger changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jreidinger@suse.c | |om) | --- Comment #19 from Josef Reidinger --- (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 Martin Pluskal changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mpluskal@suse.com | |) | --- Comment #21 from Martin Pluskal --- (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.