13

I spent the better part of the month trying to install, reinstall, delete manually, and reinstall the latest linux-image-4.9.0-8 (or thereof) onto my Debian 9 (Stretch), but it will always (re)boot into that wrong version of Linux 3.16.0-5.

I even deleted the entire /boot directory content and reinstalled.

I have a standard Debian 9 installation into /dev/sda drive where /dev/sda1 is the /boot standalone partition.

My checklist:

  • Checked the Debian Administration Handbook.
  • No UEFI bootloader in hardware
  • Turned off imageramfs option in /etc/kernel-img.conf
  • No fancy kernel modules (not even NVIDIA nor ATI)
  • Correctly used apt instead of apt-get

That is one puzzle system here that I've encountered myself.

The latest directory of /boot is:

$ ls -lat /boot
total 106000
drwxr-xr-x 23 root root     4096 Jan 17 12:25 ..
drwxr-xr-x  2 root root     4096 Jan 17 12:17 grub
drwxr-xr-x  3 root root     4096 Jan 17 12:17 .
-rw-r--r--  1 root root 19595458 Jan 17 12:17 initrd.img-4.9.0-8-amd64
-rw-r--r--  1 root root 19446192 Jan 17 12:08 initrd.img-4.9.0-5-amd64
-rw-r--r--  1 root root 19587298 Nov  7 13:58 initrd.img-4.9.0-7-amd64
-rw-r--r--  1 root root   186563 Oct 27 14:46 config-4.9.0-8-amd64
-rw-r--r--  1 root root  3195896 Oct 27 14:46 System.map-4.9.0-8-amd64
-rw-r--r--  1 root root  4232992 Oct 27 14:46 vmlinuz-4.9.0-8-amd64
-rw-r--r--  1 root root   186568 Aug 13 15:31 config-4.9.0-7-amd64
-rw-r--r--  1 root root  3192069 Aug 13 15:31 System.map-4.9.0-7-amd64
-rw-r--r--  1 root root  4232992 Aug 13 15:31 vmlinuz-4.9.0-7-amd64
-rw-r--r--  1 root root 19478453 Feb 19  2018 initrd.img-4.9.0-3-amd64
-rw-r--r--  1 root root   186473 Jan  4  2018 config-4.9.0-5-amd64
-rw-r--r--  1 root root  3185098 Jan  4  2018 System.map-4.9.0-5-amd64
-rw-r--r--  1 root root  4216608 Jan  4  2018 vmlinuz-4.9.0-5-amd64
-rw-r--r--  1 root root   186386 Sep 18  2017 config-4.9.0-3-amd64
-rw-r--r--  1 root root  3180929 Sep 18  2017 System.map-4.9.0-3-amd64
-rw-r--r--  1 root root  4204320 Sep 18  2017 vmlinuz-4.9.0-3-amd64

Noticed that there is no Linux 3.16.0-5 image/initramfs.

Yet executing uname always results in:

Linux arca 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08)

The top-level directory content and their symbolic links are also correct:

# ls -lat /
total 112
drwxrwxrwt  14 root root 11264 Jan 17 13:15 tmp
drwxr-xr-x  33 root root  1080 Jan 17 12:46 run
drwxr-xr-x  19 root root  3480 Jan 17 12:45 dev
drwxr-xr-x 178 root root 12288 Jan 17 12:45 etc
dr-xr-xr-x  13 root root     0 Jan 17 12:44 sys
dr-xr-xr-x 195 root root     0 Jan 17 12:44 proc
drwx------  36 root root  4096 Jan 17 12:44 root
drwxr-xr-x  23 root root  4096 Jan 17 12:25 .
drwxr-xr-x  23 root root  4096 Jan 17 12:25 ..
drwxr-xr-x   3 root root  4096 Jan 17 12:17 boot
drwxr-xr-x   2 root root 12288 Jan 17 11:27 sbin
drwxrwxr-x   2 root root  4096 Jan 17 11:27 bin
lrwxrwxrwx   1 root root    29 Nov  7 13:56 initrd.img -> boot/initrd.img-4.9.0-8-amd64
lrwxrwxrwx   1 root root    29 Nov  7 13:56 initrd.img.crap -> boot/initrd.img-4.9.0-7-amd64
lrwxrwxrwx   1 root root    26 Nov  7 13:56 vmlinuz -> boot/vmlinuz-4.9.0-8-amd64
lrwxrwxrwx   1 root root    26 Nov  7 13:56 vmlinuz.crap.4.9.0.7 -> boot/vmlinuz-4.9.0-7-amd64
drwxr-xr-x   6 root root  4096 Oct 11 17:01 opt
drwxr-xr-x  20 root root  4096 Oct 10 16:52 lib
drwxr-xr-x   3 root root  4096 Oct 10 16:34 srv
drwxr-xr-x   8 root root  4096 Sep  5 13:34 home
drwxr-xr-x  13 root root  4096 Mar 17  2018 var
drwxr-xr-x   2 root root  4096 Mar 17  2018 lib64
drwxr-xr-x   7 root root  4096 Feb 19  2018 media
drwxr-xr-x   2 root root  4096 Feb 19  2018 debootstrap
drwxr-xr-x  10 root root  4096 May 16  2017 usr
drwxr-xr-x   2 root root  4096 Oct  8  2016 mnt
drwx------   2 root root 16384 Oct  8  2016 lost+found

Even boot partition sda1 for /boot is marked correctly.

# fdisk /dev/sda

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xfa4b1728

Device     Boot  Start        End    Sectors   Size Id Type
/dev/sda1  *      2048     499711     497664   243M 83 Linux
/dev/sda2       501758 1953523711 1953021954 931.3G  5 Extended
/dev/sda5       501760 1953523711 1953021952 931.3G 8e Linux LVM

Partition 2 does not start on physical sector boundary.

Command (m for help): quit
Improve this question

1 Answer 1

Reset to default
18

Probably you're using UEFI and the /boot used by the bootloader is not that directory you're listing, but an unmounted vfat partition. Check it in /etc/fstab and, if you have a separate /boot partition, just mount /boot before upgrading the kernel.

If you don't want to mount manually /boot remove the noauto option from it's line in /etc/fstab

Improve this answer
7
  • 6
    You have got to be kidding me. As a long-time slackware user, I had forgotten about the /boot mount point. A quick examination of the /etc/mtab showed that /boot was NOT mounted. Once /boot gets mounted, Fred removed the mask, Velma said "there it is" and the mystery is solved.
    – John Greene
    Jan 17, 2019 at 18:26
  • 3
    Turns out that it was a former system admin practice to not mount (via 'noauto' option) the /boot partition as 'suggested' by CISecurity guideline (probably in effort to cut down the malicious avenues). The usual Debian upgrade route went flawlessly and the box reboot into its new kernel version just fine. Case in point, I've already listed that UEFI was not being used.
    – John Greene
    Jan 17, 2019 at 18:27
  • 2
    Well, I run into this very same issue almost every time I upgrade my gentoo box kernel ¯_(ツ)_/¯
    – isalgueiro
    Jan 17, 2019 at 18:30
  • 2
    @EgbertS ... and I would have gotten away with it too, if it wasn't for those darned kids! :-P
    – Time4Tea
    Jan 17, 2019 at 18:41
  • 1
    It is actually a helpful admin hint to touch a file named /boot/BOOT_PARTITION_NOT_MOUNTED or /boot/0_DO_NOT_INSTALL_KERNEL_HERE depending on whether that partition is mounted or not.
    – John Greene
    Nov 14, 2021 at 11:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .