Why is my Debian 9 (Stretch) Linux kernel not getting upgraded after 'apt install'?
11
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
aptinstead ofapt-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
debian linux-kernel debian-installer
edited 3 hours ago
G-Man
13k93365
asked 10 hours ago
Egbert SEgbert S
1787
add a comment |
11
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
aptinstead ofapt-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
debian linux-kernel debian-installer
edited 3 hours ago
G-Man
13k93365
asked 10 hours ago
Egbert SEgbert S
1787
add a comment |
11
11
11
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
aptinstead ofapt-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
debian linux-kernel debian-installer
edited 3 hours ago
G-Man
13k93365
asked 10 hours ago
Egbert SEgbert S
1787
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
aptinstead ofapt-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
debian linux-kernel debian-installer
debian linux-kernel debian-installer
edited 3 hours ago
G-Man
13k93365
asked 10 hours ago
Egbert SEgbert S
1787
edited 3 hours ago
G-Man
13k93365
asked 10 hours ago
Egbert SEgbert S
1787
edited 3 hours ago
G-Man
13k93365
edited 3 hours ago
G-Man
13k93365
edited 3 hours ago
G-Man
13k93365
13k93365
asked 10 hours ago
Egbert SEgbert S
1787
asked 10 hours ago
Egbert SEgbert S
1787
asked 10 hours ago
Egbert SEgbert S
1787
1787
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
14
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
answered 10 hours ago
isalgueiroisalgueiro
25625
New contributor
isalgueiro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
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.
– Egbert S
10 hours ago
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.
– Egbert S
9 hours ago
1
Well, I run into this very same issue almost every time I upgrade my gentoo box kernel ¯_(ツ)_/¯
– isalgueiro
9 hours ago
1
@EgbertS ... and I would have gotten away with it too, if it wasn't for those darned kids! :-P
– Time4Tea
9 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f495133%2fwhy-is-my-debian-9-stretch-linux-kernel-not-getting-upgraded-after-apt-instal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
14
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
answered 10 hours ago
isalgueiroisalgueiro
25625
New contributor
isalgueiro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
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.
– Egbert S
10 hours ago
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.
– Egbert S
9 hours ago
1
Well, I run into this very same issue almost every time I upgrade my gentoo box kernel ¯_(ツ)_/¯
– isalgueiro
9 hours ago
1
@EgbertS ... and I would have gotten away with it too, if it wasn't for those darned kids! :-P
– Time4Tea
9 hours ago
add a comment |
14
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
answered 10 hours ago
isalgueiroisalgueiro
25625
New contributor
isalgueiro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
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.
– Egbert S
10 hours ago
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.
– Egbert S
9 hours ago
1
Well, I run into this very same issue almost every time I upgrade my gentoo box kernel ¯_(ツ)_/¯
– isalgueiro
9 hours ago
1
@EgbertS ... and I would have gotten away with it too, if it wasn't for those darned kids! :-P
– Time4Tea
9 hours ago
add a comment |
14
14
14
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
answered 10 hours ago
isalgueiroisalgueiro
25625
New contributor
isalgueiro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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
answered 10 hours ago
isalgueiroisalgueiro
25625
New contributor
isalgueiro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 10 hours ago
isalgueiroisalgueiro
25625
New contributor
isalgueiro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 10 hours ago
isalgueiroisalgueiro
25625
answered 10 hours ago
isalgueiroisalgueiro
25625
25625
New contributor
isalgueiro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
isalgueiro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
isalgueiro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
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.
– Egbert S
10 hours ago
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.
– Egbert S
9 hours ago
1
Well, I run into this very same issue almost every time I upgrade my gentoo box kernel ¯_(ツ)_/¯
– isalgueiro
9 hours ago
1
@EgbertS ... and I would have gotten away with it too, if it wasn't for those darned kids! :-P
– Time4Tea
9 hours ago
add a comment |
4
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.
– Egbert S
10 hours ago
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.
– Egbert S
9 hours ago
1
Well, I run into this very same issue almost every time I upgrade my gentoo box kernel ¯_(ツ)_/¯
– isalgueiro
9 hours ago
1
@EgbertS ... and I would have gotten away with it too, if it wasn't for those darned kids! :-P
– Time4Tea
9 hours ago
4
4
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.
– Egbert S
10 hours ago
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.
– Egbert S
10 hours ago
3
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.
– Egbert S
9 hours ago
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.
– Egbert S
9 hours ago
1
1
Well, I run into this very same issue almost every time I upgrade my gentoo box kernel ¯_(ツ)_/¯
– isalgueiro
9 hours ago
Well, I run into this very same issue almost every time I upgrade my gentoo box kernel ¯_(ツ)_/¯
– isalgueiro
9 hours ago
1
1
@EgbertS ... and I would have gotten away with it too, if it wasn't for those darned kids! :-P
– Time4Tea
9 hours ago
@EgbertS ... and I would have gotten away with it too, if it wasn't for those darned kids! :-P
– Time4Tea
9 hours ago
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f495133%2fwhy-is-my-debian-9-stretch-linux-kernel-not-getting-upgraded-after-apt-instal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
