http://bugzilla.opensuse.org/show_bug.cgi?id=1188110 http://bugzilla.opensuse.org/show_bug.cgi?id=1188110#c2 --- Comment #2 from Neal Gompa --- Thanks for the information, I'm looking into it. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188110 http://bugzilla.opensuse.org/show_bug.cgi?id=1188110#c4 --- Comment #4 from Dario Faggioli --- Yes, I have also experienced this. I'll add that doing: sudo tukit --continue execute update-bootloader after `pkcon update` / `pkcon upgrade-system` and before rebooting acts as a workaround for this problem, at least for me and for a couple of other users with which I was discussing this issue. Of course, that's not acceptable as a solution and pkcon/PackageKit should handle kernel updates automatically. But maybe it's something useful to know, while we look for a proper fix -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188110 http://bugzilla.opensuse.org/show_bug.cgi?id=1188110#c7 --- Comment #7 from Neal Gompa --- (In reply to Dario Faggioli from comment #6)

(In reply to Neal Gompa from comment #5)

...

Currently, I expect something like this to be run as some kind of post-transaction trigger by the packages that would require this to be run...

... is what should happen. And, in fact, it happens automatically when we upgrade with zypper inside `tukit` (or with the old `transactional-update`).

The point is why it does not happen when installing/updating the package with `pkcon`

Do we know what package actually does run update-bootloader itself so I can narrow down to a test case? -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188110 http://bugzilla.opensuse.org/show_bug.cgi?id=1188110#c9 --- Comment #9 from Neal Gompa --- (In reply to Richard Brown from comment #8)

(In reply to Neal Gompa from comment #7)

...

Do we know what package actually does run update-bootloader itself so I can narrow down to a test case?

Isn't that done by the kernel post script which is codified in suse-module-tools?

https://build.opensuse.org/package/show/openSUSE:Factory/suse-module-tools

https://github.com/openSUSE/suse-module-tools/tree/master/kernel-scriptlets

It doesn't appear to be the case. It looks like only dracut is called from the scripts in there, not update-bootloader. And I didn't find a direct reference to a script that calls update-bootloader in the kernel spec templates in kernel-source either. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188110
http://bugzilla.opensuse.org/show_bug.cgi?id=1188110#c12

Neal Gompa  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iforster@suse.com
              Flags|                            |needinfo?(iforster@suse.com
                   |                            |)

--- Comment #12 from Neal Gompa  ---
Created attachment 853724
  --> http://bugzilla.opensuse.org/attachment.cgi?id=853724&action=edit
System upgrade from MicroOS 20211008 to 20211111 using Micro DNF

I installed Micro DNF to attempt to get a better idea of what's happening, and
now I know a bit about what's wrong.

I attempted an upgrade using Micro DNF from the October 8 snapshot to the
November 11 snapshot, which includes a kernel upgrade, and I got some
interesting output:

```
grub2-probe: error: cannot find a device for /boot (is /dev mounted?).
update-bootloader: 2021-11-13 14:28:57 <3> update-bootloader-0815
run_command.294: '/usr/lib/bootloader/grub2/install' failed with exit code 1,
output:
<<<<<<<<<<<<<<<<
target = i386-pc
+ /usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe
/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0
Installing for i386-pc platform.
/usr/sbin/grub2-install: error: cannot find a device for / (is /dev mounted?).
>>>>>>>>>>>>>>>>
update-bootloader: 2021-11-13 14:28:57 <3> update-bootloader-0815
run_command.294: '/usr/lib/bootloader/grub2/config' failed with exit code 1,
output:
<<<<<<<<<<<<<<<<
+ /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
/usr/sbin/grub2-probe: error: cannot find a device for / (is /dev mounted?).
>>>>>>>>>>>>>>>>
```

This seems like something is wrong with how libtukit sets up the new root
snapshot for the transaction.

I've attached the full output log as well, so you can see for yourself.

My reproducer:

1. Download and install the 20211008 snapshot
2. Install microdnf with pkcon: "pkcon install microdnf"
3. Reboot
4. Update with microdnf: "sudo microdnf update"

-- 
You are receiving this mail because:
You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188110 http://bugzilla.opensuse.org/show_bug.cgi?id=1188110#c14 --- Comment #14 from Neal Gompa --- (In reply to Ignaz Forster from comment #13)

I see the problem now: Transaction->getRoot() returns the path to the directory of the root file system. This path is then set as the root path for DNF directly.

The problem is that /usr/sbin/grub2-install requires to have a dedicated mount point and not just a directory, so tukit is also creating a temporary bind mount and executes commands it receives on that bind mount instead of the root directory. However libdnf-plugin-txnupd is using the root path directly.

I guess the best solution would be to return the bind path for Transaction->getRoot() instead. If one needs the real root path one can use Snapshot->getRoot() then (the Snapshot class will become public with transactional-update 4.0 anyway).

That would make sense, as I'm expecting Transaction->getRoot() to be the prepared transaction area for package management to work in. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188110 http://bugzilla.opensuse.org/show_bug.cgi?id=1188110#c16 Ignaz Forster changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Ignaz Forster --- Thinking about this again, the temporary mount directory in /tmp is not necessary at all. With transactional-update 3.6.2 the snapshot directory will just be bind mounted over itself now, so the return value of Transaction->getRoot() will be identical to the return value of Snapshot->getRoot() for now. -- You are receiving this mail because: You are the assignee for the bug.