livefs-editor icon indicating copy to clipboard operation
livefs-editor copied to clipboard

Updated packages not used during curtin installation

Open xypron opened this issue 2 years ago • 4 comments

Hello @mwhudson,

My update.yaml has

- name: install-packages
  packages:
  - efivar
  - libefiboot1
  - libefivar1

to update efivar which has a problem on the target system.

grub-install fails due to using the old efivar.

This is what I find on the file system:

root@ubuntu-server:/# ls /lib/riscv64-linux-gnu/libefivar.so.1* -la
lrwxrwxrwx 1 root root     17 Aug  2 17:52 /lib/riscv64-linux-gnu/libefivar.so.1 -> libefivar.so.1.37
-rw-r--r-- 1 root root 138872 Aug  2 17:52 /lib/riscv64-linux-gnu/libefivar.so.1.37
root@ubuntu-server:/# ls /target/lib/riscv64-linux-gnu/libefivar.so.1* -la
lrwxrwxrwx 1 root root     17 Oct  7  2021 target/lib/riscv64-linux-gnu/libefivar.so.1 -> libefivar.so.1.37
-rw-r--r-- 1 root root 126352 Oct  7  2021 target/lib/riscv64-linux-gnu/libefivar.so.1.37

The root file-system has the new package, but the target system is still using the old version.

My expectation was that the target would receive the updated packages before GRUB is installed.

Best regards

Heinrich

xypron avatar Aug 03 '23 10:08 xypron

Hm this is strange. Is the old efivar installed in any other layer? (which image are you starting with?)

mwhudson avatar Aug 04 '23 04:08 mwhudson

I am using the current mantic-live-server-riscv64.img.gz. This contains:

  • /pool/main/e/efivar/libefiboot1_37-6ubuntu2_riscv64.deb
  • /pool/main/e/efivar/libefivar1_37-6ubuntu2_riscv64.deb

I guess the add-debs-to-pool command could replace these. But this requires manual download. In my case from a private ppa.

I am just wondering whether there should be an easier way to refresh the /pool packages from an archive.

xypron avatar Aug 04 '23 07:08 xypron

add-debs-to-pool does not work correctly see #46

xypron avatar Aug 04 '23 10:08 xypron

Ah so here I think I know what might be going on.

  1. you install libefivar1 in the minimal layer a. so /varlib/dpkg/status in the base layer has libefivar1 marked as installed b. but /varlib/dpkg/status is now out of date in the minimal.full layer
  2. when curtin is installing, it checks the list of installed packages (which is out of date due to 1b) and thinks it needs to install libefivar1
  3. it then runs "apt install libefivar1" and because the only available libefivar1 is from the pool, it installs that version a. usually apt would refuse a downgrade but because of 1b again it doesn't even realise there's any version of libefivar1 installed at all

Is this vaguely plausible? I'm not quite sure it makes sense but it's possible. Do you think you could send me the output of journalctl & /var/log/installer after one of these installs? (privately, I guess)

mwhudson avatar Aug 08 '23 04:08 mwhudson