Bug 1090524 - Failed grub2/install message in grub2-i386-pc %posttrans script
Failed grub2/install message in grub2-i386-pc %posttrans script
Status: RESOLVED WORKSFORME
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Bootloader
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Josef Reidinger
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-23 10:36 UTC by Duncan Mac-Vicar
Modified: 2019-02-22 10:08 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Duncan Mac-Vicar 2018-04-23 10:36:08 UTC
I am seeing this message for a long long time everytime I do zypper dup. It may be harmless, but it may be useful for you to know it happens, or may be my system configuration triggers it. Feel free to close it if you think it is ok that it happens (I still think it is misleading).

    dracut: *** Stripping files ***
    dracut: *** Stripping files done ***
    dracut: *** Generating early-microcode cpio image ***
    dracut: *** Constructing GenuineIntel.bin ****
    dracut: *** Store current command line parameters ***
    dracut: Stored kernel commandline:
    dracut:  rd.lvm.lv=system/swap
     rd.lvm.lv=system/root
    dracut:  resume=/dev/mapper/system-swap
    dracut:  root=/dev/mapper/system-root rootfstype=ext4 rootflags=rw,relatime,data=ordered
    dracut: *** Creating image file '/boot/initrd-4.16.2-1-default' ***
    dracut: *** Creating initramfs image file '/boot/initrd-4.16.2-1-default' done ***

Output of grub2-i386-pc-2.02-21.1.x86_64.rpm %posttrans script:
    update-bootloader: 2018-04-23 08:44:18 <3> update-bootloader-1038 run_command.274: '/usr/lib/bootloader/grub2/install' failed with exit code 1, output:
    <<<<<<<<<<<<<<<<
    target = i386-pc
    /dev/disk/by-id/scsi-SATA_Samsung_SSD_840S1AXNSAF418336R: not a block device
    >>>>>>>>>>>>>>>>
Comment 1 Michael Chang 2018-04-30 08:28:48 UTC
Probably the update-bootloader was complaining /dev/disk/by-id/scsi-SATA_Samsung_SSD_840S1AXNSAF418336R did not present on your system. Could you please check that ?
Comment 2 Duncan Mac-Vicar 2018-04-30 13:23:02 UTC
You are right:

# ls /dev/disk/by-id/scsi-SATA_Samsung_SSD_840S1AXNSAF418336R
ls: cannot access '/dev/disk/by-id/scsi-SATA_Samsung_SSD_840S1AXNSAF418336R': No such file or directory

/etc # ag Samsung_SSD
default/grub_installdevice
1:/dev/disk/by-id/scsi-SATA_Samsung_SSD_840S1AXNSAF418336R

default/grub_installdevice.old
1:/dev/disk/by-id/scsi-SATA_Samsung_SSD_840_S1AXNSAF418336R
/etc #

How did that value end in default/grub_installdevice?

What should I do, just remove those two files? (they are not owned by any package).
Comment 3 Josef Möllers 2018-07-26 06:54:29 UTC
Sorry for the somewhat long delay ...

I discussed this with Rich Paredes and Josef Reidinger and both said not to delete the file as it would be used by yast2-bootloader.
As the information in that file appears to be stale, I'm assigning this to the maintainer of yast2-bootloader to discuss how this issue should be resolved properly.
Comment 4 Steffen Winterfeldt 2018-07-27 13:34:23 UTC
Actually, yast issues should go to yast2-maintainers; but let's take a short-cut
as nobody will decide anything without Josef here.
Comment 5 Josef Reidinger 2018-07-27 14:07:50 UTC
OK, let me structure a bit answer:

1) to know why this non-existing device ended up in default/grub_installdevice I need y2logs from installation time ( not sure if it is not already rotated away ).

2) regarding existence of default/grub_installdevice . We using it and it is useful to track where installation puts its stage1. If it use generic_mbr and if we control boot flag or user do not want it for us. This file is really important when there is a multiboot and user expect not so aggressive behavior he configured during installation. Why we need to store it? Because when grub2 is upgraded, it can also upgrade stage1 ( not happen often ) and in such case we need to know where we want to install that new upgraded stage1. And of course to show current settings in yast2-bootloader.

What we can possible discuss is to skip this file for trivial simple cases like single disk and install to MBR. And expect all related parts already know about such decision.

3) this file is used only when grub2 needs stage1 location so non-EFI x86_64 and ppc. For other architectures we do not have it.

So I hope I explain why we need this file. To debug this issue with I need y2logs. Cannot do much more without it.
Comment 6 Michael Chang 2018-07-30 07:50:59 UTC
Interestingly the /dev/disk/by-id/scsi-SATA_Samsung_SSD_840_S1AXNSAF418336R (in grub_installdevice.old) gets renamed to /dev/disk/by-id/scsi-SATA_Samsung_SSD_840S1AXNSAF418336R (in newer grub_installdevice).
Comment 7 Josef Reidinger 2018-08-22 14:28:20 UTC
duncan - ping. Without logs I worry I cannot say what write yast2-bootloader itself and what is written by something else.
Comment 9 Josef Reidinger 2019-02-22 10:08:18 UTC
ok, so lets close.