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

Groups > linux.debian.user > #220122 > unrolled thread

linux-image-4.9.0-12-amd64 breaks LUKS root

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

Contents

  linux-image-4.9.0-12-amd64 breaks LUKS root David Christensen <dpchrist@holgerdanske.com> - 2020-03-15 07:20 +0100
    Re: linux-image-4.9.0-12-amd64 breaks LUKS root David Christensen <dpchrist@holgerdanske.com> - 2020-03-30 02:00 +0200
      Re: linux-image-4.9.0-12-amd64 breaks LUKS root deloptes <deloptes@gmail.com> - 2020-03-30 09:00 +0200
        Re: linux-image-4.9.0-12-amd64 breaks LUKS root David Christensen <dpchrist@holgerdanske.com> - 2020-03-30 11:00 +0200
          Re: linux-image-4.9.0-12-amd64 breaks LUKS root deloptes <deloptes@gmail.com> - 2020-03-30 12:00 +0200
            Re: linux-image-4.9.0-12-amd64 breaks LUKS root David Christensen <dpchrist@holgerdanske.com> - 2020-07-27 01:50 +0200
              Re: linux-image-4.9.0-12-amd64 breaks LUKS root David <bouncingcats@gmail.com> - 2020-07-27 03:20 +0200
                Re: linux-image-4.9.0-12-amd64 breaks LUKS root David Christensen <dpchrist@holgerdanske.com> - 2020-07-27 06:20 +0200
              Re: linux-image-4.9.0-12-amd64 breaks LUKS root David Wright <deblis@lionunicorn.co.uk> - 2020-07-27 05:50 +0200
                Re: linux-image-4.9.0-12-amd64 breaks LUKS root David Christensen <dpchrist@holgerdanske.com> - 2020-07-27 07:30 +0200
                  Re: linux-image-4.9.0-12-amd64 breaks LUKS root David Wright <deblis@lionunicorn.co.uk> - 2020-07-30 04:10 +0200

#220122 — linux-image-4.9.0-12-amd64 breaks LUKS root

debian-user:

I have Debian machine:

         2020-03-14 22:57:21 root@po ~
         # cat /etc/debian_version ; uname -a
         9.12
         Linux po 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 
(2019-11-11) x86_
64 GNU/Linux


When I install linux-image-4.9.0-12-amd64:

2020-03-14 22:58:13 root@po ~
# time apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
   linux-image-4.9.0-12-amd64
The following packages will be upgraded:
   linux-image-amd64
1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 39.3 MB of archives.
After this operation, 193 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.us.debian.org/debian stretch/main amd64 
linux-image-4.9.0-12-amd64 amd64 4.9.210-1 [39.3 MB]
Get:2 http://ftp.us.debian.org/debian stretch/main amd64 
linux-image-amd64 amd64 4.9+80+deb9u10 [7158 B]
Fetched 39.3 MB in 12s (3074 kB/s) 

Reading changelogs... Done
Selecting previously unselected package linux-image-4.9.0-12-amd64.
(Reading database ... 106060 files and directories currently installed.)
Preparing to unpack .../linux-image-4.9.0-12-amd64_4.9.210-1_amd64.deb ...
Unpacking linux-image-4.9.0-12-amd64 (4.9.210-1) ...
Preparing to unpack .../linux-image-amd64_4.9+80+deb9u10_amd64.deb ...
Unpacking linux-image-amd64 (4.9+80+deb9u10) over (4.9+80+deb9u9) ...
Setting up linux-image-4.9.0-12-amd64 (4.9.210-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.9.0-11-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.9.0-11-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-4.9.0-12-amd64
I: /initrd.img is now a symlink to boot/initrd.img-4.9.0-12-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-12-amd64
cryptsetup: WARNING: target sda2_crypt has a random key, skipped
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: .background_cache.png
Found linux image: /boot/vmlinuz-4.9.0-12-amd64
Found initrd image: /boot/initrd.img-4.9.0-12-amd64
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-9-amd64
Found initrd image: /boot/initrd.img-4.9.0-9-amd64
done
Setting up linux-image-amd64 (4.9+80+deb9u10) ...

real	0m34.738s
user	0m9.616s
sys	0m3.132s


And then reboot, it refuses to accept the (correct) LUKS passphrase:

<snip>
Please unlock disk /dev/disk/by-partuuid/xxxxxxxx-xx (sda3_crypt):
cryptsetup (sda3_crypt) : unknown fstype, bad password or options?
Please unlock disk /dev/disk/by-partuuid/xxxxxxxx-xx (sda3_crypt):
cryptsetup (sda3_crypt) : unknown fstype, bad password or options?
Please unlock disk /dev/disk/by-partuuid/xxxxxxxx-xx (sda3_crypt):
cryptsetup (sda3_crypt) : unknown fstype, bad password or options?
cryptsetup (sda3_crypt) : maximum number of tries exceeded
cryptsetup: going to sleep for 60 seconds...



I tried a rescue using the debian-9.11.0-amd64-xfce-CD-1 USB stick:

Debian GNU/Linux installer boot menu

-> Advanced options

-> Rescue mode

Language -> C

Continent or region -> North America

Country -> United States

Keymap -> American English

Hostname -> po

Domain -> tracy.holgerdanske.com

Time zone -> Pacific

Passphrase for /dev/sdb3 -> ********

Device to use as root filesystem -> /dev/mapper/sdb3_crypt

Mount seperate /boot partition -> Yes

Rescue operations -> Reinstall GRUB boot loader

Device -> /dev/sdb

Rescue operations -> Reboot


Nope:

<snip>
Please unlock disk /dev/disk/by-partuuid/xxxxxxxx-xx (sda3_crypt):
cryptsetup (sda3_crypt) : unknown fstype, bad password or options?
Please unlock disk /dev/disk/by-partuuid/xxxxxxxx-xx (sda3_crypt):
cryptsetup (sda3_crypt) : unknown fstype, bad password or options?
Please unlock disk /dev/disk/by-partuuid/xxxxxxxx-xx (sda3_crypt):
cryptsetup (sda3_crypt) : unknown fstype, bad password or options?
cryptsetup (sda3_crypt) : maximum number of tries exceeded
cryptsetup: going to sleep for 60 seconds...


Thankfully, my other machines still work.


Suggestions?


David

[toc] | [next] | [standalone]

#220688

On 2020-03-14 23:14, David Christensen wrote:
> debian-user:
> 
> I have Debian machine:
> 
>          2020-03-14 22:57:21 root@po ~
>          # cat /etc/debian_version ; uname -a
>          9.12
>          Linux po 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 
> (2019-11-11) x86_
> 64 GNU/Linux
> 
> 
> When I install linux-image-4.9.0-12-amd64:
> 
> 2020-03-14 22:58:13 root@po ~
> # time apt-get dist-upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following NEW packages will be installed:
>    linux-image-4.9.0-12-amd64
> The following packages will be upgraded:
>    linux-image-amd64
> 1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 39.3 MB of archives.
> After this operation, 193 MB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Get:1 http://ftp.us.debian.org/debian stretch/main amd64 
> linux-image-4.9.0-12-amd64 amd64 4.9.210-1 [39.3 MB]
> Get:2 http://ftp.us.debian.org/debian stretch/main amd64 
> linux-image-amd64 amd64 4.9+80+deb9u10 [7158 B]
> Fetched 39.3 MB in 12s (3074 kB/s)
> Reading changelogs... Done
> Selecting previously unselected package linux-image-4.9.0-12-amd64.
> (Reading database ... 106060 files and directories currently installed.)
> Preparing to unpack .../linux-image-4.9.0-12-amd64_4.9.210-1_amd64.deb ...
> Unpacking linux-image-4.9.0-12-amd64 (4.9.210-1) ...
> Preparing to unpack .../linux-image-amd64_4.9+80+deb9u10_amd64.deb ...
> Unpacking linux-image-amd64 (4.9+80+deb9u10) over (4.9+80+deb9u9) ...
> Setting up linux-image-4.9.0-12-amd64 (4.9.210-1) ...
> I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.9.0-11-amd64
> I: /initrd.img.old is now a symlink to boot/initrd.img-4.9.0-11-amd64
> I: /vmlinuz is now a symlink to boot/vmlinuz-4.9.0-12-amd64
> I: /initrd.img is now a symlink to boot/initrd.img-4.9.0-12-amd64
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-4.9.0-12-amd64
> cryptsetup: WARNING: target sda2_crypt has a random key, skipped
> /etc/kernel/postinst.d/zz-update-grub:
> Generating grub configuration file ...
> Found background image: .background_cache.png
> Found linux image: /boot/vmlinuz-4.9.0-12-amd64
> Found initrd image: /boot/initrd.img-4.9.0-12-amd64
> Found linux image: /boot/vmlinuz-4.9.0-11-amd64
> Found initrd image: /boot/initrd.img-4.9.0-11-amd64
> Found linux image: /boot/vmlinuz-4.9.0-9-amd64
> Found initrd image: /boot/initrd.img-4.9.0-9-amd64
> done
> Setting up linux-image-amd64 (4.9+80+deb9u10) ...
> 
> real    0m34.738s
> user    0m9.616s
> sys    0m3.132s
> 
> 
> And then reboot, it refuses to accept the (correct) LUKS passphrase:
> 
> <snip>
> Please unlock disk /dev/disk/by-partuuid/xxxxxxxx-xx (sda3_crypt):
> cryptsetup (sda3_crypt) : unknown fstype, bad password or options?
> Please unlock disk /dev/disk/by-partuuid/xxxxxxxx-xx (sda3_crypt):
> cryptsetup (sda3_crypt) : unknown fstype, bad password or options?
> Please unlock disk /dev/disk/by-partuuid/xxxxxxxx-xx (sda3_crypt):
> cryptsetup (sda3_crypt) : unknown fstype, bad password or options?
> cryptsetup (sda3_crypt) : maximum number of tries exceeded
> cryptsetup: going to sleep for 60 seconds...

I re-imaged that machine and let it run for the past two week.  When I 
upgraded the kernel against today, it failed in the same manner.


Any suggestions?


David

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

#220691

David Christensen wrote:

> I re-imaged that machine and let it run for the past two week.  When I
> upgraded the kernel against today, it failed in the same manner.
> 
> 
> Any suggestions?

/etc/crypttab ?

/etc/initramfs-tools/ ?

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

#220692

On 2020-03-29 23:53, deloptes wrote:
> David Christensen wrote:
> 
>> I re-imaged that machine and let it run for the past two week.  When I
>> upgraded the kernel against today, it failed in the same manner.
>>
>>
>> Any suggestions?
> 
> /etc/crypttab ?
> 
> /etc/initramfs-tools/ ?


CVS says /etc/crypttab was last changed on March 15.


'find /etc/initramfs-tools/ -type f | xargs ls -lt' says the newest file 
in /etc/initramfs-tools was changed on Feb 2.


The error message I am seeing occurs when some stage boot loader or the 
kernel (?) is prompting for the passphrase to decrypt the root 
partition.  So, root is not mounted and /etc is not available.


I can boot the previous kernel, so the LUKS file structures on disk are 
okay.


The error is repeatable if I insert the drive into another machine with 
a different model motherboard.


A different system drive with the  4.0.9-12 kernel and LUKS root works 
in that machine.


I have several other Debian systems.  They all upgraded to kernel 
4.9.0-12 and LUKS root works correctly.


My guess is that:

     /boot/initrd.img-4.9.0-12-amd64

was built wrong by the kernel upgrade post install script (?).


I have filed a bug report:

     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329


David

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

#220693

David Christensen wrote:

> CVS says /etc/crypttab was last changed on March 15.
> 
> 
> 'find /etc/initramfs-tools/ -type f | xargs ls -lt' says the newest file
> in /etc/initramfs-tools was changed on Feb 2.
> 
> 
> The error message I am seeing occurs when some stage boot loader or the
> kernel (?) is prompting for the passphrase to decrypt the root
> partition.  So, root is not mounted and /etc is not available.
> 
> 

go into initram shell and check what is missing

The initramfs holds the necessary files - might be something is missing

> I can boot the previous kernel, so the LUKS file structures on disk are
> okay.
> 
> 
> The error is repeatable if I insert the drive into another machine with
> a different model motherboard.
> 

not necessary - what would you expect - you are on the same disk.

> 
> A different system drive with the  4.0.9-12 kernel and LUKS root works
> in that machine.
> 
> 
> I have several other Debian systems.  They all upgraded to kernel
> 4.9.0-12 and LUKS root works correctly.
> 
> 
> My guess is that:
> 
> /boot/initrd.img-4.9.0-12-amd64
> 
> was built wrong by the kernel upgrade post install script (?).
> 
> 
> I have filed a bug report:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329
> 

Could be. But it is usually a result of some local configuration specific

You can extract the content of working and not working initrd and compare
the content. Or go into the shell init=/bin/sh and check what is wrong.

lsinitramfs will give you the content of the initrd

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

#225303

On 2020-03-30 02:58, deloptes wrote:
> David Christensen wrote:

>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329

I updated/ upgraded the system today and whatever broke LUKS when I 
'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several 
months ago now breaks LUKS when I try to boot the kernel that I have 
been using prior and since -- 4.9.0-11-amd64.  Fortunately, LUKS still 
works with my oldest available kernel, 4.9.0-9-amd64.


> lsinitramfs will give you the content of the initrd

I was unable to understand your other suggestions, but tried to use this 
one:

2020-07-26 16:35:36 root@po ~
# lsinitramfs -l /boot/initrd.img-4.9.0-9-amd64 > 
lsinitramfs-l-initrd.img-4.9.0-9-amd64.out

2020-07-26 16:35:57 root@po ~
# lsinitramfs -l /boot/initrd.img-4.9.0-11-amd64 > 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out


The listings are very large:

2020-07-26 16:40:08 root@po ~
# wc lsinitramfs-l-initrd.img-4.9.0-*
   1243  11247 128364 lsinitramfs-l-initrd.img-4.9.0-11-amd64.out
   1243  11247 127485 lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
   2486  22494 255849 total


And there are a lot of changes:

2020-07-26 16:40:50 root@po ~
# diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | wc
     977    9878  112569

2020-07-26 16:40:52 root@po ~
# diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | head
 > drwxr-xr-x  10 root     root            0 Jul 26 15:46 .
 > drwxr-xr-x   3 root     root            0 Jul 26 15:46 conf
 > drwxr-xr-x   2 root     root            0 Jul 26 15:46 conf/conf.d
 > -rw-r--r--   1 root     root           76 Jul 26 15:46 
conf/conf.d/cryptroot
 > -rw-r--r--   1 root     root           16 Jul 26 15:46 conf/arch.conf
 > drwxr-xr-x   2 root     root            0 Jul 26 15:46 sbin
< lrwxrwxrwx   1 root     root           12 Jan  9  2020 sbin/mount.ntfs 
-> /bin/ntfs-3g
 > lrwxrwxrwx   1 root     root           12 Jul 26 15:46 
sbin/mount.ntfs -> /bin/ntfs-3g
< lrwxrwxrwx   1 root     root           12 Jan  9  2020 
sbin/mount.ntfs-3g -> /bin/ntfs-3g
 > lrwxrwxrwx   1 root     root           12 Jul 26 15:46 
sbin/mount.ntfs-3g -> /bin/ntfs-3g


I doubt I can find the needle(s) in that haystack.


Any other suggestions?


David

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

#225304

On Mon, 27 Jul 2020 at 09:47, David Christensen
<dpchrist@holgerdanske.com> wrote:
> On 2020-03-30 02:58, deloptes wrote:
> > David Christensen wrote:

> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329
>
> I updated/ upgraded the system today and whatever broke LUKS when I
> 'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several
> months ago now breaks LUKS when I try to boot the kernel that I have
> been using prior and since -- 4.9.0-11-amd64.  Fortunately, LUKS still
> works with my oldest available kernel, 4.9.0-9-amd64.
>
> > lsinitramfs will give you the content of the initrd
>
> Any other suggestions?

Hi, just a few thoughts from a dumb onlooker ...

I notice that your bug 955329 is filed against the linux-image
package around 4 months ago, and that there has been no reply from the
maintainers.

Looking around for similar bugs, I found [1] this comment by one of
the maintainers:

> LUKS volumes are recognised and set uo by userland, so are you sure
> this is due to the kernel upgrade?

So maybe it's not helpful to focus on the kernel, and I wonder if you
would get a response or debugging assistance if you were to report
this against the cryptsetup-initramfs package.

Another suggestion, although I am far from an expert in these matters,
I wonder if (per man initramfs-tools) you have tried using a kernel
boot parameter 'break=premount' and then see what happens if you try
to run your cryptsetup command in the initramfs shell.

For example, I would try:
(initramfs) blkid
(initramfs) cryptsetup open /dev/whatever/blkid/says somename
(initramfs) blkid

and expect to see /dev/mapper/somename in the output of the last
command if it succeeds, or some clue if it does not.

You can also run commands like
(initramfs) mount
(initramfs) ls
(initramfs) cat /cryptroot/crypttab
to investigate further.

I confirm all these commands do work for me on a Debian 10 machine.

Also, if that fails, it might be useful to confirm that the drive can be
decrypted when temporarily connected to another working system.

Hope this helps.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827342#10

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

#225306

On 2020-07-26 18:15, David wrote:
> On Mon, 27 Jul 2020 at 09:47, David Christensen
> <dpchrist@holgerdanske.com> wrote:
>> On 2020-03-30 02:58, deloptes wrote:
>>> David Christensen wrote:
> 
>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329
>>
>> I updated/ upgraded the system today and whatever broke LUKS when I
>> 'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several
>> months ago now breaks LUKS when I try to boot the kernel that I have
>> been using prior and since -- 4.9.0-11-amd64.  Fortunately, LUKS still
>> works with my oldest available kernel, 4.9.0-9-amd64.
>>
>>> lsinitramfs will give you the content of the initrd
>>
>> Any other suggestions?
> 
> Hi, just a few thoughts from a dumb onlooker ...
> 
> I notice that your bug 955329 is filed against the linux-image
> package around 4 months ago, and that there has been no reply from the
> maintainers.
> 
> Looking around for similar bugs, I found [1] this comment by one of
> the maintainers:
> 
>> LUKS volumes are recognised and set uo by userland, so are you sure
>> this is due to the kernel upgrade?
> 
> So maybe it's not helpful to focus on the kernel, and I wonder if you
> would get a response or debugging assistance if you were to report
> this against the cryptsetup-initramfs package.
> 
> Another suggestion, although I am far from an expert in these matters,
> I wonder if (per man initramfs-tools) you have tried using a kernel
> boot parameter 'break=premount' and then see what happens if you try
> to run your cryptsetup command in the initramfs shell.
> 
> For example, I would try:
> (initramfs) blkid
> (initramfs) cryptsetup open /dev/whatever/blkid/says somename
> (initramfs) blkid
> 
> and expect to see /dev/mapper/somename in the output of the last
> command if it succeeds, or some clue if it does not.
> 
> You can also run commands like
> (initramfs) mount
> (initramfs) ls
> (initramfs) cat /cryptroot/crypttab
> to investigate further.
> 
> I confirm all these commands do work for me on a Debian 10 machine.
> 
> Also, if that fails, it might be useful to confirm that the drive can be
> decrypted when temporarily connected to another working system.
> 
> Hope this helps.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827342#10

Thanks for the suggestions.


Given the motherboard is circa 2011, Debian 9 has reached end of 
maintenance, and the lack of response on my initial bug report, I doubt 
this bug will be fixed.  Even if I had some success in debugging the 
issue and submitted reports and/or patches, I don't know if or what the 
Debian project would do with them.


It's time to put in a fresh system drive and try something newer that is 
actively supported.


David

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

#225305

On Sun 26 Jul 2020 at 16:46:48 (-0700), David Christensen wrote:
> On 2020-03-30 02:58, deloptes wrote:
> > David Christensen wrote:
> 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329
> 
> I updated/ upgraded the system today and whatever broke LUKS when I
> 'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several
> months ago now breaks LUKS when I try to boot the kernel that I have
> been using prior and since -- 4.9.0-11-amd64.  Fortunately, LUKS still
> works with my oldest available kernel, 4.9.0-9-amd64.
> 
> > lsinitramfs will give you the content of the initrd
> 
> I was unable to understand your other suggestions, but tried to use
> this one:
> 
> 2020-07-26 16:35:36 root@po ~
> # lsinitramfs -l /boot/initrd.img-4.9.0-9-amd64 >
> lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
> 
> 2020-07-26 16:35:57 root@po ~
> # lsinitramfs -l /boot/initrd.img-4.9.0-11-amd64 >
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out
> 
> The listings are very large:
> 
> 2020-07-26 16:40:08 root@po ~
> # wc lsinitramfs-l-initrd.img-4.9.0-*
>   1243  11247 128364 lsinitramfs-l-initrd.img-4.9.0-11-amd64.out
>   1243  11247 127485 lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
>   2486  22494 255849 total
> 
> And there are a lot of changes:
> 
> 2020-07-26 16:40:50 root@po ~
> # diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | wc
>     977    9878  112569
> 
> 2020-07-26 16:40:52 root@po ~
> # diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | head
> > drwxr-xr-x  10 root     root            0 Jul 26 15:46 .
> > drwxr-xr-x   3 root     root            0 Jul 26 15:46 conf
> > drwxr-xr-x   2 root     root            0 Jul 26 15:46 conf/conf.d
> > -rw-r--r--   1 root     root           76 Jul 26 15:46
> conf/conf.d/cryptroot
> > -rw-r--r--   1 root     root           16 Jul 26 15:46 conf/arch.conf
> > drwxr-xr-x   2 root     root            0 Jul 26 15:46 sbin
> < lrwxrwxrwx   1 root     root           12 Jan  9  2020
> sbin/mount.ntfs -> /bin/ntfs-3g
> > lrwxrwxrwx   1 root     root           12 Jul 26 15:46
> sbin/mount.ntfs -> /bin/ntfs-3g
> < lrwxrwxrwx   1 root     root           12 Jan  9  2020
> sbin/mount.ntfs-3g -> /bin/ntfs-3g
> > lrwxrwxrwx   1 root     root           12 Jul 26 15:46
> sbin/mount.ntfs-3g -> /bin/ntfs-3g

If you're going to diff listings like that, you at least need to pipe
the output through something like

  cut --complement -b 43-54 /tmp/initrd.img-4.19.0-9-amd64.out | sed -e 's/4.19.0.9/4.19.0.X/'

to strip the dates and kernel version. This will leave you with the
sizes. If you're looking for missing files, drop the -l, the cut, and
leave the sed.

> I doubt I can find the needle(s) in that haystack.

Cheers,
David.

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

#225307

On 2020-07-26 20:39, David Wright wrote:
> On Sun 26 Jul 2020 at 16:46:48 (-0700), David Christensen wrote:

>> 2020-07-26 16:35:36 root@po ~
>> # lsinitramfs -l /boot/initrd.img-4.9.0-9-amd64 >
>> lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
>>
>> 2020-07-26 16:35:57 root@po ~
>> # lsinitramfs -l /boot/initrd.img-4.9.0-11-amd64 >
>> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out

>> 2020-07-26 16:40:52 root@po ~
>> # diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
>> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | head
>>> drwxr-xr-x  10 root     root            0 Jul 26 15:46 .
>>> drwxr-xr-x   3 root     root            0 Jul 26 15:46 conf
>>> drwxr-xr-x   2 root     root            0 Jul 26 15:46 conf/conf.d
>>> -rw-r--r--   1 root     root           76 Jul 26 15:46
>> conf/conf.d/cryptroot
>>> -rw-r--r--   1 root     root           16 Jul 26 15:46 conf/arch.conf
>>> drwxr-xr-x   2 root     root            0 Jul 26 15:46 sbin
>> < lrwxrwxrwx   1 root     root           12 Jan  9  2020
>> sbin/mount.ntfs -> /bin/ntfs-3g
>>> lrwxrwxrwx   1 root     root           12 Jul 26 15:46
>> sbin/mount.ntfs -> /bin/ntfs-3g
>> < lrwxrwxrwx   1 root     root           12 Jan  9  2020
>> sbin/mount.ntfs-3g -> /bin/ntfs-3g
>>> lrwxrwxrwx   1 root     root           12 Jul 26 15:46
>> sbin/mount.ntfs-3g -> /bin/ntfs-3g
> 
> If you're going to diff listings like that, you at least need to pipe
> the output through something like
> 
>    cut --complement -b 43-54 /tmp/initrd.img-4.19.0-9-amd64.out | sed -e 's/4.19.0.9/4.19.0.X/'
> 
> to strip the dates and kernel version. This will leave you with the
> sizes. If you're looking for missing files, drop the -l, the cut, and
> leave the sed.

Thanks for pointing out potential errors.


Yes, I should have nerfed the kernel version.  But, I believe date and 
time should be retained.  I think we can also remove items with size 0:


2020-07-26 22:06:40 root@po ~
# perl -ane 's/4.9.0-\d+/4.9.0-xxx/; print if $F[4]' 
lsinitramfs-l-initrd.img-4.9.0-9-amd64.out > 
lsinitramfs-l-initrd.img-4.9.0-9-amd64.out2

2020-07-26 22:06:57 root@po ~
# perl -ane 's/4.9.0-\d+/4.9.0-xxx/; print if $F[4]' 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out > 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out2


My previous diff was outputting links in error.  I believe these are the 
files that have been added or changed:

2020-07-26 22:09:01 root@po ~
# diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out2 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out2 | egrep '^>' | wc
     705    7104   84072


Stripping of everything except the file or link name:

2020-07-26 22:11:53 root@po ~
# perl -ae 'print $F[8], "\n" if $F[8]' 
lsinitramfs-l-initrd.img-4.9.0-9-amd64.out2 | sort > 
lsinitramfs-l-initrd.img-4.9.0-9-amd64.out3

2020-07-26 22:12:13 root@po ~
# perl -ae 'print $F[8], "\n" if $F[8]' 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out2 | sort > 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out3


It appears that no files have been added or removed:

2020-07-26 22:14:30 root@po ~
# diff -s lsinitramfs-l-initrd.img-4.9.0-9-amd64.out3 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out3
Files lsinitramfs-l-initrd.img-4.9.0-9-amd64.out3 and 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out3 are identical


At this point, I need to put my efforts into a newer desktop distribution.


David

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

#225513

On Sun 26 Jul 2020 at 22:22:54 (-0700), David Christensen wrote:
> On 2020-07-26 20:39, David Wright wrote:
> > On Sun 26 Jul 2020 at 16:46:48 (-0700), David Christensen wrote:
> 
> > > 2020-07-26 16:35:36 root@po ~
> > > # lsinitramfs -l /boot/initrd.img-4.9.0-9-amd64 >
> > > lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
> > > 
> > > 2020-07-26 16:35:57 root@po ~
> > > # lsinitramfs -l /boot/initrd.img-4.9.0-11-amd64 >
> > > lsinitramfs-l-initrd.img-4.9.0-11-amd64.out
> 
> > > 2020-07-26 16:40:52 root@po ~
> > > # diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
> > > lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | head
> > > > drwxr-xr-x  10 root     root            0 Jul 26 15:46 .
> > > > drwxr-xr-x   3 root     root            0 Jul 26 15:46 conf
> > > > drwxr-xr-x   2 root     root            0 Jul 26 15:46 conf/conf.d
> > > > -rw-r--r--   1 root     root           76 Jul 26 15:46
> > > conf/conf.d/cryptroot
> > > > -rw-r--r--   1 root     root           16 Jul 26 15:46 conf/arch.conf
> > > > drwxr-xr-x   2 root     root            0 Jul 26 15:46 sbin
> > > < lrwxrwxrwx   1 root     root           12 Jan  9  2020
> > > sbin/mount.ntfs -> /bin/ntfs-3g
> > > > lrwxrwxrwx   1 root     root           12 Jul 26 15:46
> > > sbin/mount.ntfs -> /bin/ntfs-3g
> > > < lrwxrwxrwx   1 root     root           12 Jan  9  2020
> > > sbin/mount.ntfs-3g -> /bin/ntfs-3g
> > > > lrwxrwxrwx   1 root     root           12 Jul 26 15:46
> > > sbin/mount.ntfs-3g -> /bin/ntfs-3g
> > 
> > If you're going to diff listings like that, you at least need to pipe
> > the output through something like
> > 
> >    cut --complement -b 43-54 /tmp/initrd.img-4.19.0-9-amd64.out | sed -e 's/4.19.0.9/4.19.0.X/'
> > 
> > to strip the dates and kernel version. This will leave you with the
> > sizes. If you're looking for missing files, drop the -l, the cut, and
> > leave the sed.
> 
> Thanks for pointing out potential errors.
> 
> Yes, I should have nerfed the kernel version.  But, I believe date and
> time should be retained.  I think we can also remove items with size
> 0:
> 
> 2020-07-26 22:06:40 root@po ~
> # perl -ane 's/4.9.0-\d+/4.9.0-xxx/; print if $F[4]'
> lsinitramfs-l-initrd.img-4.9.0-9-amd64.out >
> lsinitramfs-l-initrd.img-4.9.0-9-amd64.out2
> 
> 2020-07-26 22:06:57 root@po ~
> # perl -ane 's/4.9.0-\d+/4.9.0-xxx/; print if $F[4]'
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out >
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out2
> 
> My previous diff was outputting links in error.  I believe these are
> the files that have been added or changed:
> 
> 2020-07-26 22:09:01 root@po ~
> # diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out2
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out2 | egrep '^>' | wc
>     705    7104   84072
> 
> Stripping of everything except the file or link name:
> 
> 2020-07-26 22:11:53 root@po ~
> # perl -ae 'print $F[8], "\n" if $F[8]'
> lsinitramfs-l-initrd.img-4.9.0-9-amd64.out2 | sort >
> lsinitramfs-l-initrd.img-4.9.0-9-amd64.out3
> 
> 2020-07-26 22:12:13 root@po ~
> # perl -ae 'print $F[8], "\n" if $F[8]'
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out2 | sort >
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out3
> 
> It appears that no files have been added or removed:
> 
> 2020-07-26 22:14:30 root@po ~
> # diff -s lsinitramfs-l-initrd.img-4.9.0-9-amd64.out3
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out3
> Files lsinitramfs-l-initrd.img-4.9.0-9-amd64.out3 and
> lsinitramfs-l-initrd.img-4.9.0-11-amd64.out3 are identical

As you have several working machines, another approach to checking the
initramfs is to unmkinitramfs two files, one from the problem machine,
and check the trees are identical with md5sum.

> At this point, I need to put my efforts into a newer desktop distribution.

Fair enough. But it's a very worrying story, and it would be nice
to eliminate some sources of the problem, and possibly determine
where the cause lies.

I recall the relief when I found out why I was having problems
unlocking my own laptop. (Null characters were being injected into the
keyboard input every 20 secs from, I believe, the battery/AC power
controller. This last facility is now defunct.)

Cheers,
David.

[toc] | [prev] | [standalone]

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

csiph-web