Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #66820 > unrolled thread

Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost

Back to article view | Back to linux.debian.kernel

Contents

  Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost Christoph Anton Mitterer <calestyo@scientia.net> - 2020-04-18 02:40 +0200
    Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost Ben Hutchings <ben@decadent.org.uk> - 2020-04-19 00:00 +0200
      Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost Christoph Anton Mitterer <calestyo@scientia.net> - 2020-04-19 01:30 +0200
        Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost Ben Hutchings <ben@decadent.org.uk> - 2020-04-24 01:00 +0200
          Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost Christoph Anton Mitterer <calestyo@scientia.net> - 2020-04-24 06:50 +0200

#66820 — Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost

Source: linux
Version: 5.5.17-1
Severity: important


Hi.

I've just switched from the linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64
(which wasn't available as soon as the -unsigned version) in on go via apt.


The consequence was, that many modules were missing.


Looking at the apt/term.log:

Removing linux-image-5.5.0-1-amd64-unsigned
[then debconf asks whether I want to remove the running image]
Removing the running kernel
/etc/kernel/prerm.d/dkms:
dkms: removing: openafs 1.8.6pre1 (5.5.0-1-amd64) (x86_64)
[...]
depmod...

DKMS: uninstall completed.
[...]
Selecting previously unselected package linux-image-5.5.0-1-amd64.
Preparing to unpack .../linux-image-5.5.0-1-amd64_5.5.13-2_amd64.deb ...
Unpacking linux-image-5.5.0-1-amd64 (5.5.13-2) ...
Preparing to unpack .../linux-image-amd64_5.5.13-2_amd64.deb ...
Unpacking linux-image-amd64 (5.5.13-2) over (5.4.19-1) ...
[...]
Removing linux-image-5.4.0-4-amd64 (5.4.19-1) ...
/etc/kernel/prerm.d/dkms:
dkms: removing: openafs 1.8.6pre1 (5.4.0-4-amd64) (x86_64)
[...]
depmod...

DKMS: uninstall completed.
[...]
Setting up linux-image-5.5.0-1-amd64 (5.5.13-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.2.0-3-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.2.0-3-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.5.0-1-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.5.0-1-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.5.0-1-amd64:.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.5.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_09.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_huc_2.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_2.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/glk_huc_4.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/cml_huc_4.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/cml_guc_33.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/icl_huc_9.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/ehl_huc_9.0.0.bin for module i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_33.0.4.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.0.3.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_35.2.0.bin for module i915
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.5.0-1-amd64
Found initrd image: /boot/initrd.img-5.5.0-1-amd64
Found linux image: /boot/vmlinuz-5.2.0-3-amd64
Found initrd image: /boot/initrd.img-5.2.0-3-amd64
Configured General Secure System
Found memtest86+ image: /root/boot/memtest86+.bin
Found memtest86+ multiboot image: /root/boot/memtest86+_multiboot.bin
done
[...]
Setting up xtables-addons-dkms (3.9-1) ...
Loading new xtables-addons-3.9 DKMS files...
Building for 5.5.0-1-amd64
Building initial module for 5.5.0-1-amd64
Done.
[...]
depmod...

DKMS: install completed.
[...]


So far, so good...


Purging configuration files for linux-image-5.5.0-1-amd64-unsigned (5.5.13-2) ...
I: /vmlinuz is now a symlink to boot/vmlinuz-5.2.0-3-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.2.0-3-amd64
rmdir: failed to remove '/lib/modules/5.5.0-1-amd64': Directory not empty
Purging configuration files for linux-image-5.4.0-4-amd64 (5.4.19-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.5.0-1-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.5.0-1-amd64
Processing triggers for tex-common (6.14) ...
[here apt ends after some further triggers]


Looking at the postrm:
if [ "$1" = purge ]; then
    for extra_file in modules.dep modules.isapnpmap modules.pcimap \
                      modules.usbmap modules.parportmap \
                      modules.generic_string modules.ieee1394map \
                      modules.ieee1394map modules.pnpbiosmap \
                      modules.alias modules.ccwmap modules.inputmap \
                      modules.symbols modules.ofmap \
                      modules.seriomap modules.\*.bin \
                      modules.softdep modules.devname; do
        eval rm -f /lib/modules/$version/$extra_file
    done
    rmdir /lib/modules/$version || true
fi


It deletes all modules... which are however already belonging to the
signed version of the package.


Interestingly, and I don't quite understand this, not all modules were deleted.
Cause I spotted the failed rmdir right away and looked briefly at the dir
and modules were still there.

However, after reboot, e.g. iwlwifi was gone.



Cheers,
Chris.

[toc] | [next] | [standalone]

#66827

[Multipart message — attachments visible in raw view] — view raw

Control: forcmerge -1 #851695

On Sat, 2020-04-18 at 02:35 +0200, Christoph Anton Mitterer wrote:
> Source: linux
> Version: 5.5.17-1
> Severity: important
> 
> 
> Hi.
> 
> I've just switched from the linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64
> (which wasn't available as soon as the -unsigned version) in on go via apt.
> 
> 
> The consequence was, that many modules were missing.

I don't think so.

[...]
> Looking at the postrm:
> if [ "$1" = purge ]; then
>     for extra_file in modules.dep modules.isapnpmap modules.pcimap \
>                       modules.usbmap modules.parportmap \
>                       modules.generic_string modules.ieee1394map \
>                       modules.ieee1394map modules.pnpbiosmap \
>                       modules.alias modules.ccwmap modules.inputmap \
>                       modules.symbols modules.ofmap \
>                       modules.seriomap modules.\*.bin \
>                       modules.softdep modules.devname; do
>         eval rm -f /lib/modules/$version/$extra_file
>     done
>     rmdir /lib/modules/$version || true
> fi
> 
> 
> It deletes all modules... which are however already belonging to the
> signed version of the package.
[...]

No, it does not.  It removes kmod's index files, after which modprobe
and udev won't be able to find modules.  (But any modules loaded by the
initramfs will be unaffected.)  Running "depmod" will fix that.

This is a known bug but I don't know how to fix it.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

[toc] | [prev] | [next] | [standalone]

#66832

On Sat, 2020-04-18 at 22:54 +0100, Ben Hutchings wrote:
> No, it does not.  It removes kmod's index files
I probably should have better checked the code I've copy&pased ^^


> This is a known bug but I don't know how to fix it.

Maybe I'm thinking way to simple... but if depmod fixes that...
couldn't one install e.g. a trigger, that runs it in the end?

Or alternatively, simply call depmod unconditonally in the postrm,
after the files were (potentially) removed?
Maybe one could even check in e.g. the postrm of the -unsigned whether
the -signed version of the same name is now installed and only invoke
depmod then (and vice versa for the postrm of the -signed version).


Cheers,
Chris.

[toc] | [prev] | [next] | [standalone]

#66871

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2020-04-19 at 01:21 +0200, Christoph Anton Mitterer wrote:
> On Sat, 2020-04-18 at 22:54 +0100, Ben Hutchings wrote:
> > No, it does not.  It removes kmod's index files
> I probably should have better checked the code I've copy&pased ^^
> 
> 
> > This is a known bug but I don't know how to fix it.
> 
> Maybe I'm thinking way to simple... but if depmod fixes that...
> couldn't one install e.g. a trigger, that runs it in the end?
> 
> Or alternatively, simply call depmod unconditonally in the postrm,
> after the files were (potentially) removed?
>
> Maybe one could even check in e.g. the postrm of the -unsigned whether
> the -signed version of the same name is now installed and only invoke
> depmod then (and vice versa for the postrm of the -signed version).

I came up with a simpler alternative:
https://salsa.debian.org/kernel-team/linux/-/commit/67fa568149b985f73b333acdec4481acf667192f

But I haven't found time to test it yet.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.

[toc] | [prev] | [next] | [standalone]

#66873

On Thu, 2020-04-23 at 23:50 +0100, Ben Hutchings wrote:
> I came up with a simpler alternative:
> https://salsa.debian.org/kernel-team/linux/-/commit/67fa568149b985f73b333acdec4481acf667192f

Looks good... and seems like the best solution.

Thanks,
Chris.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web