Kernel installed in wrong location

[CLOSE Dave]

Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
the right place (/boot) and is not detected by GRUB. Why not?

For example, after installing the most recent new kernel, I see this.

[root@machine ~]# ls /boot
7725dfc225d14958a625ddaaaea5962b
config-4.14.11-300.fc27.x86_64
efi
extlinux
grub2
initramfs-0-rescue-7725dfc225d14958a625ddaaaea5962b.img
initramfs-4.14.11-300.fc27.x86_64.img
initrd-plymouth.img
loader
lost+found
System.map-4.14.11-300.fc27.x86_64
vmlinuz-0-rescue-7725dfc225d14958a625ddaaaea5962b
vmlinuz-4.14.11-300.fc27.x86_64

[root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
0-rescue                 4.13.10-200.fc26.x86_64  4.13.9-200.fc26.x86_64
4.11.11-300.fc26.x86_64  4.13.11-200.fc26.x86_64  4.14.11-300.fc27.x86_64
4.12.11-300.fc26.x86_64  4.13.12-200.fc26.x86_64  4.14.4-200.fc26.x86_64
4.12.12-300.fc26.x86_64  4.13.13-200.fc26.x86_64  4.14.5-200.fc26.x86_64
4.12.13-300.fc26.x86_64  4.13.15-100.fc25.x86_64  4.14.6-200.fc26.x86_64
4.12.14-300.fc26.x86_64  4.13.15-200.fc26.x86_64  4.15.8-300.fc27.x86_64
4.12.5-300.fc26.x86_64   4.13.16-200.fc26.x86_64  4.15.9-300.fc27.x86_64
4.12.8-300.fc26.x86_64   4.13.16-202.fc26.x86_64
4.12.9-300.fc26.x86_64   4.13.4-200.fc26.x86_64

But RPM thinks the new kernel was installed correctly!

[root@machine ~]# rpm -V kernel-core-4.15.9-300.fc27
 (no output)

[Rick Stevens]

On 03/19/2018 11:54 AM, CLOSE Dave wrote:
> Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
> the right place (/boot) and is not detected by GRUB. Why not?
>
> For example, after installing the most recent new kernel, I see this.
>
> [root@machine ~]# ls /boot
> 7725dfc225d14958a625ddaaaea5962b
> config-4.14.11-300.fc27.x86_64
> efi
> extlinux
> grub2
> initramfs-0-rescue-7725dfc225d14958a625ddaaaea5962b.img
> initramfs-4.14.11-300.fc27.x86_64.img
> initrd-plymouth.img
> loader
> lost+found
> System.map-4.14.11-300.fc27.x86_64
> vmlinuz-0-rescue-7725dfc225d14958a625ddaaaea5962b
> vmlinuz-4.14.11-300.fc27.x86_64
>
> [root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
> 0-rescue                 4.13.10-200.fc26.x86_64  4.13.9-200.fc26.x86_64
> 4.11.11-300.fc26.x86_64  4.13.11-200.fc26.x86_64  4.14.11-300.fc27.x86_64
> 4.12.11-300.fc26.x86_64  4.13.12-200.fc26.x86_64  4.14.4-200.fc26.x86_64
> 4.12.12-300.fc26.x86_64  4.13.13-200.fc26.x86_64  4.14.5-200.fc26.x86_64
> 4.12.13-300.fc26.x86_64  4.13.15-100.fc25.x86_64  4.14.6-200.fc26.x86_64
> 4.12.14-300.fc26.x86_64  4.13.15-200.fc26.x86_64  4.15.8-300.fc27.x86_64
> 4.12.5-300.fc26.x86_64   4.13.16-200.fc26.x86_64  4.15.9-300.fc27.x86_64
> 4.12.8-300.fc26.x86_64   4.13.16-202.fc26.x86_64
> 4.12.9-300.fc26.x86_64   4.13.4-200.fc26.x86_64
>
> But RPM thinks the new kernel was installed correctly!
>
> [root@machine ~]# rpm -V kernel-core-4.15.9-300.fc27

Sure looks like the scriptlet didn't run. I think you should get a
report about the initramfs image and the system map having different
modes and that they're ghost files (not part of the package payload as
they are created by the post-install scriptlet). I get:

[root@golem4 boot]# rpm -V kernel-core-4.15.9-300.fc27.x86_64
.M.......  g /boot/System.map-4.15.9-300.fc27.x86_64
.M.......  g /boot/initramfs-4.15.9-300.fc27.x86_64.img

(the "M" means different modes and the "g" means "ghost file"). Check
your dnf logs to verify that something didn't go wrong during the
install process.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-    "Hello. My PID is Inigo Montoya.  You `kill -9'-ed my parent    -
-                     process.  Prepare to vi."                      -
----------------------------------------------------------------------

[CLOSE Dave]

Rick Stevens wrote:
> > Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
> > the right place (/boot) and is not detected by GRUB. Why not?
> Sure looks like the scriptlet didn't run. I think you should get a
> report about the initramfs image and the system map having different
> modes and that they're ghost files (not part of the package payload as
> they are created by the post-install scriptlet). I get:
>
> [root@golem4 boot]# rpm -V kernel-core-4.15.9-300.fc27.x86_64
> .M.......  g /boot/System.map-4.15.9-300.fc27.x86_64
> .M.......  g /boot/initramfs-4.15.9-300.fc27.x86_64.img
>
> (the "M" means different modes and the "g" means "ghost file"). Check
> your dnf logs to verify that something didn't go wrong during the
> install process.

My /etc/dnf/dnf.conf contains only the default:
> [main]
> gpgcheck=1
> installonly_limit=3
> clean_requirements_on_remove=true

The portion of /var/log/dnf.log for an attempted reinstall shows:
> 2018-03-19T18:33:55Z INFO Dependencies resolved.
> 2018-03-19T18:33:55Z INFO ================================================================================
>  Package            Arch          Version                  Repository      Size
> ================================================================================
> Reinstalling:
>  kernel-core        x86_64        4.15.9-300.fc27          updates         23 M
> Transaction Summary
>
> 2018-03-19T18:33:55Z INFO Total download size: 23 M
> 2018-03-19T18:33:55Z INFO Downloading Packages:
> 2018-03-19T18:33:56Z SUBDEBUG Call: RPMPayload._end_cb: (<dnf.repo.RPMPayload object at 0x7f5df909e6d8>, 0, None), {}
> 2018-03-19T18:33:56Z INFO --------------------------------------------------------------------------------
> 2018-03-19T18:33:56Z INFO Total                                            66 MB/s |  23 MB     00:00
> 2018-03-19T18:33:56Z INFO Running transaction check
> 2018-03-19T18:33:59Z INFO Transaction check succeeded.
> 2018-03-19T18:33:59Z INFO Running transaction test
> 2018-03-19T18:34:13Z INFO Transaction test succeeded.
> 2018-03-19T18:34:13Z DDEBUG timer: transaction test: 14222 ms
> 2018-03-19T18:34:13Z INFO Running transaction
> 2018-03-19T18:34:19Z DDEBUG RPM transaction start.
> 2018-03-19T18:35:17Z DDEBUG RPM transaction over.
> 2018-03-19T18:35:33Z DDEBUG timer: verify transaction: 16178 ms
> 2018-03-19T18:35:33Z DDEBUG timer: transaction: 79880 ms
> 2018-03-19T18:35:33Z DEBUG Completion plugin: Generating completion cache...
> 2018-03-19T18:35:33Z INFO
> Reinstalled:
>   kernel-core.x86_64 4.15.9-300.fc27
>
> 2018-03-19T18:35:33Z INFO Complete!
> 2018-03-19T18:35:33Z DDEBUG Cleaning up.
> 2018-03-19T18:35:33Z DDEBUG /var/cache/dnf/updates-7dab57dbb768f030/packages/kernel-core-4.15.9-300.fc27.x86_64.rpm removed

I don't see anything strange about /boot/grub2/grub.cfg or
/etc/default/grub (which is identical to other local machines that are
working as expected). What should I be looking for to see why the kernel
is only being installed in the rescue directory?

[CLOSE Dave]

Further, here is an extract of /var/log/messages for the attempted
reinstall, surpressing the timestamp and dracut indicator.
> dracut-046-8.git20180105.fc27
> Executing: /usr/bin/dracut /boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64/initrd 4.15.9-300.fc27.x86_64
> dracut module 'busybox' will not be installed, because command 'busybox' could not be found!
> dracut module 'busybox' will not be installed, because command 'busybox' could not be found!
> *** Including module: bash ***
> *** Including module: systemd ***
> *** Including module: systemd-initrd ***
> *** Including module: nss-softokn ***
> *** Including module: i18n ***
> *** Including module: network ***
> *** Including module: ifcfg ***
> *** Including module: drm ***
> *** Including module: plymouth ***
> *** Including module: dm ***
> Skipping udev rule: 64-device-mapper.rules
> Skipping udev rule: 60-persistent-storage-dm.rules
> Skipping udev rule: 55-dm.rules
> *** Including module: kernel-modules ***
> *** Including module: kernel-network-modules ***
> *** Including module: lvm ***
> Skipping udev rule: 64-device-mapper.rules
> Skipping udev rule: 56-lvm.rules
> Skipping udev rule: 60-persistent-storage-lvm.rules
> *** Including module: resume ***
> *** Including module: rootfs-block ***
> *** Including module: terminfo ***
> *** Including module: udev-rules ***
> Skipping udev rule: 40-redhat.rules
> Skipping udev rule: 50-firmware.rules
> Skipping udev rule: 50-udev.rules
> Skipping udev rule: 91-permissions.rules
> Skipping udev rule: 80-drivers-modprobe.rules
> *** Including module: biosdevname ***
> *** Including module: dracut-systemd ***
> *** Including module: usrmount ***
> *** Including module: base ***
> *** Including module: fs-lib ***
> *** Including module: shutdown ***
> *** Including modules done ***
> *** Installing kernel module dependencies ***
> *** Installing kernel module dependencies done ***
> *** Resolving executable dependencies ***
> *** Resolving executable dependencies done***
> *** Hardlinking files ***
> *** Hardlinking files done ***
> *** Stripping files ***
> *** Stripping files done ***
> *** Generating early-microcode cpio image ***
> *** Constructing GenuineIntel.bin ****
> *** Store current command line parameters ***
> *** Creating image file '/boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64/initrd' ***
> *** Creating initramfs image file '/boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64/initrd' done ***

[CLOSE Dave]

Further information from another attempt a few minutes ago. Could the
broken pipe be the problem? What could cause that? /boot is at 52%.
> # /usr/bin/dnf -y reinstall kernel*-4.15.9-300.fc27.x86_64
> Last metadata expiration check: 23:59:22 ago on Sun Mar 18 14:00:12 2018.
> Dependencies resolved.
> ================================================================================
>  Package                   Arch        Version               Repository    Size
> ================================================================================
> Reinstalling:
>  kernel                    x86_64      4.15.9-300.fc27       updates       81 k
>  kernel-core               x86_64      4.15.9-300.fc27       updates       23 M
>  kernel-devel              x86_64      4.15.9-300.fc27       updates       12 M
>  kernel-headers            x86_64      4.15.9-300.fc27       updates      1.2 M
>  kernel-modules            x86_64      4.15.9-300.fc27       updates       27 M
>  kernel-modules-extra      x86_64      4.15.9-300.fc27       updates      2.2 M
> Transaction Summary
> Total download size: 65 M
> Downloading Packages:
> (1/6): kernel-4.15.9-300.fc27.x86_64.rpm         13 MB/s |  81 kB     00:00
> (2/6): kernel-headers-4.15.9-300.fc27.x86_64.rp  48 MB/s | 1.2 MB     00:00
> (3/6): kernel-devel-4.15.8-300.fc27_4.15.9-300.  36 MB/s | 3.1 MB     00:00
> (4/6): kernel-modules-extra-4.15.9-300.fc27.x86  50 MB/s | 2.2 MB     00:00
> (5/6): kernel-core-4.15.9-300.fc27.x86_64.rpm    55 MB/s |  23 MB     00:00
> (6/6): kernel-modules-4.15.9-300.fc27.x86_64.rp  50 MB/s |  27 MB     00:00
> [DRPM] kernel-devel-4.15.8-300.fc27_4.15.9-300.fc27.x86_64.drpm: done
>
> Total                                           2.4 MB/s |  56 MB     00:23
> Delta RPMs reduced 65.4 MB of updates to 56.4 MB (13.1% saved)
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> Transaction test succeeded.
> Running transaction
>   Preparing        :                                                        1/1
>   Reinstalling     : kernel-core-4.15.9-300.fc27.x86_64                    1/12
>   Running scriptlet: kernel-core-4.15.9-300.fc27.x86_64                    1/12
>   Reinstalling     : kernel-modules-4.15.9-300.fc27.x86_64                 2/12
>   Running scriptlet: kernel-modules-4.15.9-300.fc27.x86_64                 2/12
>   Reinstalling     : kernel-4.15.9-300.fc27.x86_64                         3/12
>   Reinstalling     : kernel-modules-extra-4.15.9-300.fc27.x86_64           4/12
>   Running scriptlet: kernel-modules-extra-4.15.9-300.fc27.x86_64           4/12
>   Reinstalling     : kernel-headers-4.15.9-300.fc27.x86_64                 5/12
>   Reinstalling     : kernel-devel-4.15.9-300.fc27.x86_64                   6/12
>   Running scriptlet: kernel-devel-4.15.9-300.fc27.x86_64                   6/12
>   Erasing          : kernel-4.15.9-300.fc27.x86_64                         7/12
>   Running scriptlet: kernel-4.15.9-300.fc27.x86_64                         7/12
>   Erasing          : kernel-headers-4.15.9-300.fc27.x86_64                 8/12
>   Erasing          : kernel-devel-4.15.9-300.fc27.x86_64                   9/12
>   Erasing          : kernel-modules-extra-4.15.9-300.fc27.x86_64          10/12
>   Running scriptlet: kernel-modules-extra-4.15.9-300.fc27.x86_64          10/12
>   Erasing          : kernel-modules-4.15.9-300.fc27.x86_64                11/12
>   Running scriptlet: kernel-modules-4.15.9-300.fc27.x86_64                11/12
>   Running scriptlet: kernel-core-4.15.9-300.fc27.x86_64                   12/12
>   Erasing          : kernel-core-4.15.9-300.fc27.x86_64                   12/12
>   Running scriptlet: kernel-core-4.15.9-300.fc27.x86_64                   12/12
> cat: write error: Broken pipe
>   Verifying        : kernel-4.15.9-300.fc27.x86_64                         1/12
>   Verifying        : kernel-core-4.15.9-300.fc27.x86_64                    2/12
>   Verifying        : kernel-devel-4.15.9-300.fc27.x86_64                   3/12
>   Verifying        : kernel-headers-4.15.9-300.fc27.x86_64                 4/12
>   Verifying        : kernel-modules-4.15.9-300.fc27.x86_64                 5/12
>   Verifying        : kernel-modules-extra-4.15.9-300.fc27.x86_64           6/12
>   Verifying        : kernel-core-4.15.9-300.fc27.x86_64                    7/12
>   Verifying        : kernel-devel-4.15.9-300.fc27.x86_64                   8/12
>   Verifying        : kernel-headers-4.15.9-300.fc27.x86_64                 9/12
>   Verifying        : kernel-modules-4.15.9-300.fc27.x86_64                10/12
>   Verifying        : kernel-modules-extra-4.15.9-300.fc27.x86_64          11/12
>   Verifying        : kernel-4.15.9-300.fc27.x86_64                        12/12
> Reinstalled:
>   kernel.x86_64 4.15.9-300.fc27
>   kernel-core.x86_64 4.15.9-300.fc27
>   kernel-devel.x86_64 4.15.9-300.fc27
>   kernel-headers.x86_64 4.15.9-300.fc27
>   kernel-modules.x86_64 4.15.9-300.fc27
>   kernel-modules-extra.x86_64 4.15.9-300.fc27
> Complete!

[Stephen Morris]

On 20/3/18 8:05 am, CLOSE Dave wrote:
> Further information from another attempt a few minutes ago. Could the
> broken pipe be the problem? What could cause that? /boot is at 52%.

I don't think the broken pipe is causing the issue, I'll need to check 
next time there's a new kernel, as when I run the same transaction as 
you have I get the broken pipe error as well, but all my kernels are 
still in /boot and /boot/"rescue directory".

regards,

Steve
> > # /usr/bin/dnf -y reinstall kernel*-4.15.9-300.fc27.x86_64
> > Last metadata expiration check: 23:59:22 ago on Sun Mar 18 14:00:12 2018.
> > Dependencies resolved.
> > ================================================================================
> >   Package                   Arch        Version               Repository    Size
> > ================================================================================
> > Reinstalling:
> >   kernel                    x86_64      4.15.9-300.fc27       updates       81 k
> >   kernel-core               x86_64      4.15.9-300.fc27       updates       23 M
> >   kernel-devel              x86_64      4.15.9-300.fc27       updates       12 M
> >   kernel-headers            x86_64      4.15.9-300.fc27       updates      1.2 M
> >   kernel-modules            x86_64      4.15.9-300.fc27       updates       27 M
> >   kernel-modules-extra      x86_64      4.15.9-300.fc27       updates      2.2 M
> > Transaction Summary
> > ================================================================================
> > Total download size: 65 M
> > Downloading Packages:
> > (1/6): kernel-4.15.9-300.fc27.x86_64.rpm         13 MB/s |  81 kB     00:00
> > (2/6): kernel-headers-4.15.9-300.fc27.x86_64.rp  48 MB/s | 1.2 MB     00:00
> > (3/6): kernel-devel-4.15.8-300.fc27_4.15.9-300.  36 MB/s | 3.1 MB     00:00
> > (4/6): kernel-modules-extra-4.15.9-300.fc27.x86  50 MB/s | 2.2 MB     00:00
> > (5/6): kernel-core-4.15.9-300.fc27.x86_64.rpm    55 MB/s |  23 MB     00:00
> > (6/6): kernel-modules-4.15.9-300.fc27.x86_64.rp  50 MB/s |  27 MB     00:00
> > [DRPM] kernel-devel-4.15.8-300.fc27_4.15.9-300.fc27.x86_64.drpm: done
> >
> > Total                                           2.4 MB/s |  56 MB     00:23
> > Delta RPMs reduced 65.4 MB of updates to 56.4 MB (13.1% saved)
> > Running transaction check
> > Transaction check succeeded.
> > Running transaction test
> > Transaction test succeeded.
> > Running transaction
> >    Preparing        :                                                        1/1
> >    Reinstalling     : kernel-core-4.15.9-300.fc27.x86_64                    1/12
> >    Running scriptlet: kernel-core-4.15.9-300.fc27.x86_64                    1/12
> >    Reinstalling     : kernel-modules-4.15.9-300.fc27.x86_64                 2/12
> >    Running scriptlet: kernel-modules-4.15.9-300.fc27.x86_64                 2/12
> >    Reinstalling     : kernel-4.15.9-300.fc27.x86_64                         3/12
> >    Reinstalling     : kernel-modules-extra-4.15.9-300.fc27.x86_64           4/12
> >    Running scriptlet: kernel-modules-extra-4.15.9-300.fc27.x86_64           4/12
> >    Reinstalling     : kernel-headers-4.15.9-300.fc27.x86_64                 5/12
> >    Reinstalling     : kernel-devel-4.15.9-300.fc27.x86_64                   6/12
> >    Running scriptlet: kernel-devel-4.15.9-300.fc27.x86_64                   6/12
> >    Erasing          : kernel-4.15.9-300.fc27.x86_64                         7/12
> >    Running scriptlet: kernel-4.15.9-300.fc27.x86_64                         7/12
> >    Erasing          : kernel-headers-4.15.9-300.fc27.x86_64                 8/12
> >    Erasing          : kernel-devel-4.15.9-300.fc27.x86_64                   9/12
> >    Erasing          : kernel-modules-extra-4.15.9-300.fc27.x86_64          10/12
> >    Running scriptlet: kernel-modules-extra-4.15.9-300.fc27.x86_64          10/12
> >    Erasing          : kernel-modules-4.15.9-300.fc27.x86_64                11/12
> >    Running scriptlet: kernel-modules-4.15.9-300.fc27.x86_64                11/12
> >    Running scriptlet: kernel-core-4.15.9-300.fc27.x86_64                   12/12
> >    Erasing          : kernel-core-4.15.9-300.fc27.x86_64                   12/12
> >    Running scriptlet: kernel-core-4.15.9-300.fc27.x86_64                   12/12
> > cat: write error: Broken pipe
> >    Verifying        : kernel-4.15.9-300.fc27.x86_64                         1/12
> >    Verifying        : kernel-core-4.15.9-300.fc27.x86_64                    2/12
> >    Verifying        : kernel-devel-4.15.9-300.fc27.x86_64                   3/12
> >    Verifying        : kernel-headers-4.15.9-300.fc27.x86_64                 4/12
> >    Verifying        : kernel-modules-4.15.9-300.fc27.x86_64                 5/12
> >    Verifying        : kernel-modules-extra-4.15.9-300.fc27.x86_64           6/12
> >    Verifying        : kernel-core-4.15.9-300.fc27.x86_64                    7/12
> >    Verifying        : kernel-devel-4.15.9-300.fc27.x86_64                   8/12
> >    Verifying        : kernel-headers-4.15.9-300.fc27.x86_64                 9/12
> >    Verifying        : kernel-modules-4.15.9-300.fc27.x86_64                10/12
> >    Verifying        : kernel-modules-extra-4.15.9-300.fc27.x86_64          11/12
> >    Verifying        : kernel-4.15.9-300.fc27.x86_64                        12/12
> > Reinstalled:
> >    kernel.x86_64 4.15.9-300.fc27
> >    kernel-core.x86_64 4.15.9-300.fc27
> >    kernel-devel.x86_64 4.15.9-300.fc27
> >    kernel-headers.x86_64 4.15.9-300.fc27
> >    kernel-modules.x86_64 4.15.9-300.fc27
> >    kernel-modules-extra.x86_64 4.15.9-300.fc27
> > Complete!

[Stephen Morris]

On 20/3/18 5:54 am, CLOSE Dave wrote:
> Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
> the right place (/boot) and is not detected by GRUB. Why not?
>
> For example, after installing the most recent new kernel, I see this.
>
> [root@machine ~]# ls /boot
> 7725dfc225d14958a625ddaaaea5962b
> config-4.14.11-300.fc27.x86_64
> efi
> extlinux
> grub2
> initramfs-0-rescue-7725dfc225d14958a625ddaaaea5962b.img
> initramfs-4.14.11-300.fc27.x86_64.img
> initrd-plymouth.img
> loader
> lost+found
> System.map-4.14.11-300.fc27.x86_64
> vmlinuz-0-rescue-7725dfc225d14958a625ddaaaea5962b
> vmlinuz-4.14.11-300.fc27.x86_64
>
> [root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
> 0-rescue                 4.13.10-200.fc26.x86_64  4.13.9-200.fc26.x86_64
> 4.11.11-300.fc26.x86_64  4.13.11-200.fc26.x86_64  4.14.11-300.fc27.x86_64
> 4.12.11-300.fc26.x86_64  4.13.12-200.fc26.x86_64  4.14.4-200.fc26.x86_64
> 4.12.12-300.fc26.x86_64  4.13.13-200.fc26.x86_64  4.14.5-200.fc26.x86_64
> 4.12.13-300.fc26.x86_64  4.13.15-100.fc25.x86_64  4.14.6-200.fc26.x86_64
> 4.12.14-300.fc26.x86_64  4.13.15-200.fc26.x86_64  4.15.8-300.fc27.x86_64
> 4.12.5-300.fc26.x86_64   4.13.16-200.fc26.x86_64  4.15.9-300.fc27.x86_64
> 4.12.8-300.fc26.x86_64   4.13.16-202.fc26.x86_64
> 4.12.9-300.fc26.x86_64   4.13.4-200.fc26.x86_64
>
> But RPM thinks the new kernel was installed correctly!
>
> [root@machine ~]# rpm -V kernel-core-4.15.9-300.fc27
>   (no output)

I have installed kernels 4.15.9-300, 4.15.6-300 and 4.15.4-300, all of 
which were installed correctly into /boot by dnf and like you have 
indicated all 3 are also replicated in the long named directory that 
matches the rescue kernel name because of the grub setting to create 
rescue entries. From your listing you seem to have changed dnf's default 
of only keeping 3 kernels, do you have a setting in /etc/dnf/dnf.conf 
that might be causing dnf to only write kernels to the rescue location?

regards,

Steve

[Greg Woods]

On Mon, Mar 19, 2018 at 12:54 PM, CLOSE Dave 
wrote:
> Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
> the right place (/boot)

Just a wild-ass guess here, but how much free space do you have in the
partition that contains /boot?

--greg

[Ed Greshko]

On 03/20/18 02:54, CLOSE Dave wrote:
> [root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
> 0-rescue                 4.13.10-200.fc26.x86_64  4.13.9-200.fc26.x86_64
> 4.11.11-300.fc26.x86_64  4.13.11-200.fc26.x86_64  4.14.11-300.fc27.x86_64
> 4.12.11-300.fc26.x86_64  4.13.12-200.fc26.x86_64  4.14.4-200.fc26.x86_64
> 4.12.12-300.fc26.x86_64  4.13.13-200.fc26.x86_64  4.14.5-200.fc26.x86_64
> 4.12.13-300.fc26.x86_64  4.13.15-100.fc25.x86_64  4.14.6-200.fc26.x86_64
> 4.12.14-300.fc26.x86_64  4.13.15-200.fc26.x86_64  4.15.8-300.fc27.x86_64
> 4.12.5-300.fc26.x86_64   4.13.16-200.fc26.x86_64  4.15.9-300.fc27.x86_64
> 4.12.8-300.fc26.x86_64   4.13.16-202.fc26.x86_64
> 4.12.9-300.fc26.x86_64   4.13.4-200.fc26.x86_64

All of those directories are empty, yes?

[CLOSE Dave]

Ed Greshko wrote:
> > [root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
> > 0-rescue                 4.13.10-200.fc26.x86_64  4.13.9-200.fc26.x86_64
> > 4.11.11-300.fc26.x86_64  4.13.11-200.fc26.x86_64  4.14.11-300.fc27.x86_64
> > 4.12.11-300.fc26.x86_64  4.13.12-200.fc26.x86_64  4.14.4-200.fc26.x86_64
> > 4.12.12-300.fc26.x86_64  4.13.13-200.fc26.x86_64  4.14.5-200.fc26.x86_64
> > 4.12.13-300.fc26.x86_64  4.13.15-100.fc25.x86_64  4.14.6-200.fc26.x86_64
> > 4.12.14-300.fc26.x86_64  4.13.15-200.fc26.x86_64  4.15.8-300.fc27.x86_64
> > 4.12.5-300.fc26.x86_64   4.13.16-200.fc26.x86_64  4.15.9-300.fc27.x86_64
> > 4.12.8-300.fc26.x86_64   4.13.16-202.fc26.x86_64
> > 4.12.9-300.fc26.x86_64   4.13.4-200.fc26.x86_64
>
> All of those directories are empty, yes?

Most, but not all:
> # ls /boot/77*/*
> /boot/7725dfc225d14958a625ddaaaea5962b/0-rescue:
> initrd  linux
> /boot/7725dfc225d14958a625ddaaaea5962b/4.11.11-300.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.12.11-300.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.12.12-300.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.12.13-300.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.12.14-300.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.12.5-300.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.12.8-300.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.12.9-300.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.10-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.11-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.12-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.13-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.15-100.fc25.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.15-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.16-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.16-202.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.4-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.13.9-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.14.11-300.fc27.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.14.4-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.14.5-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.14.6-200.fc26.x86_64:
> /boot/7725dfc225d14958a625ddaaaea5962b/4.15.8-300.fc27.x86_64:
> initrd  linux
> /boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64:
> initrd  linux

[Ed Greshko]

On 03/20/18 07:23, CLOSE Dave wrote:
> Ed Greshko wrote:
> > > [root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
> > > 0-rescue                 4.13.10-200.fc26.x86_64  4.13.9-200.fc26.x86_64
> > > 4.11.11-300.fc26.x86_64  4.13.11-200.fc26.x86_64  4.14.11-300.fc27.x86_64
> > > 4.12.11-300.fc26.x86_64  4.13.12-200.fc26.x86_64  4.14.4-200.fc26.x86_64
> > > 4.12.12-300.fc26.x86_64  4.13.13-200.fc26.x86_64  4.14.5-200.fc26.x86_64
> > > 4.12.13-300.fc26.x86_64  4.13.15-100.fc25.x86_64  4.14.6-200.fc26.x86_64
> > > 4.12.14-300.fc26.x86_64  4.13.15-200.fc26.x86_64  4.15.8-300.fc27.x86_64
> > > 4.12.5-300.fc26.x86_64   4.13.16-200.fc26.x86_64  4.15.9-300.fc27.x86_64
> > > 4.12.8-300.fc26.x86_64   4.13.16-202.fc26.x86_64
> > > 4.12.9-300.fc26.x86_64   4.13.4-200.fc26.x86_64
> >
> > All of those directories are empty, yes?
>
> Most, but not all:
> > /boot/7725dfc225d14958a625ddaaaea5962b/4.15.8-300.fc27.x86_64:
> > initrd  linux
> > /boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64:
> > initrd  linux

I get the feeling, based on the name of the directory and most of them being empty,
that these are just "temporary" directories that are just not getting deleted for
some reason.  I doubt there would be any problem to delete them.

[CLOSE Dave]

Ed Greshko wrote:
> > > All of those directories are empty, yes?
> >
> > Most, but not all:
> > > /boot/7725dfc225d14958a625ddaaaea5962b/4.15.8-300.fc27.x86_64:
> > > initrd  linux
> > > /boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64:
> > > initrd  linux
>
> I get the feeling, based on the name of the directory and most of 
> them being empty, that these are just "temporary" directories that
> are just not getting deleted for some reason.  I doubt there would be
> any problem to delete them.

Thanks. But that isn't the issue. The issue is that the
4.15.9-300.fc27.x86_64 files are NOT in /boot directly so they aren't
found by mkconfig. Of course, I could copy them there but that doesn't
seem like it should be necessary.

[CLOSE Dave]

The following procedure did NOT fix my problem. Using RPM instead of DNF
still did not install the new kernel in /boot.

Note, the new kernel is not in /boot when I start.
> # ls /boot
> 7725dfc225d14958a625ddaaaea5962b
> config-4.14.11-300.fc27.x86_64
> efi
> extlinux
> grub2
> initramfs-0-rescue-7725dfc225d14958a625ddaaaea5962b.img
> initramfs-4.14.11-300.fc27.x86_64.img
> initrd-plymouth.img
> loader
> lost+found
> System.map-4.14.11-300.fc27.x86_64
> vmlinuz-0-rescue-7725dfc225d14958a625ddaaaea5962b
> vmlinuz-4.14.11-300.fc27.x86_64

RPM won't install the new kernel since it is already installed.
> # mkdir temp
> # cd temp
> # dnf download kernel-core-4.15.9-300.fc27.x86_64
> # rpm -ivh kernel-core-4.15.9-300.fc27.x86_64
> Preparing...                          ################################# [100%]
>        package kernel-core-4.15.9-300.fc27.x86_64 is already installed

Get the rescue directory out of the way. Remove the new kernel completely.
> # mv /boot/7725dfc225d14958a625ddaaaea5962b /tmp
> # dnf -y remove kernel*-4.15.9-300.fc27.x86_64
> Removing:
>  kernel               x86_64 4.15.9-300.fc27                     @updates   0
>  kernel-core          x86_64 4.15.9-300.fc27                     @updates  58 M
>  kernel-devel         x86_64 4.15.9-300.fc27                     @updates  48 M
>  kernel-headers       x86_64 4.15.9-300.fc27                     @updates 4.3 M
>  kernel-modules       x86_64 4.15.9-300.fc27                     @updates  26 M
>  kernel-modules-extra x86_64 4.15.9-300.fc27                     @updates 2.1 M
> Removing dependent packages:
>  gcc                  x86_64 7.3.1-5.fc27                        @updates  52 M
>  gcc-c++              x86_64 7.3.1-5.fc27                        @updates  27 M
>  gcc-gdb-plugin       x86_64 7.3.1-5.fc27                        @updates 316 k
>  glibc-devel          x86_64 2.26-27.fc27                        @updates 1.1 M
>  glibc-headers        x86_64 2.26-27.fc27                        @updates 2.2 M
>  libtool              x86_64 2.4.6-20.fc27                       @fedora  2.6 M
>  pocl                 x86_64 0.15-0.1.20171023git53ef5e8.fc27    @updates 222 M
> Removing unused dependencies:
>  hwloc-libs           x86_64 1.11.5-6.fc27                       @fedora  2.1 M
>  isl                  x86_64 0.16.1-3.fc27                       @fedora  2.9 M
>  libstdc++-devel      x86_64 7.3.1-5.fc27                        @updates  10 M

Try to install the new kernel using RPM.
> # dnf download gcc-7.3.1-5.fc27.x86_64 \
>       gcc-c++-7.3.1-5.fc27.x86_64 \
>       gcc-gdb-plugin-7.3.1-5.fc27.x86_64 \
>       glibc-devel-2.26-27.fc27.x86_64 \
>       glibc-headers-2.26-27.fc27.x86_64 \
>       hwloc-libs-1.11.5-6.fc27.x86_64 \
>       isl-0.16.1-3.fc27.x86_64 \
>       kernel-4.15.9-300.fc27.x86_64 \
>       kernel-devel-4.15.9-300.fc27.x86_64 \
>       kernel-headers-4.15.9-300.fc27.x86_64 \
>       kernel-modules-4.15.9-300.fc27.x86_64 \
>       kernel-modules-extra-4.15.9-300.fc27.x86_64 \
>       libstdc++-devel-7.3.1-5.fc27.x86_64 \
>       libtool-2.4.6-20.fc27.x86_64 \
>       pocl-0.15-0.1.20171023git53ef5e8.fc27.x86_64
> # rpm -ivh *
> Preparing...                          ################################# [100%]
> Updating / installing...
>    1:kernel-core-4.15.9-300.fc27      ################################# [  6%]
>    2:kernel-modules-4.15.9-300.fc27   ################################# [ 13%]
>    3:libstdc++-devel-7.3.1-5.fc27     ################################# [ 19%]
>    4:kernel-headers-4.15.9-300.fc27   ################################# [ 25%]
>    5:glibc-headers-2.26-27.fc27       ################################# [ 31%]
>    6:glibc-devel-2.26-27.fc27         ################################# [ 38%]
>    7:isl-0.16.1-3.fc27                ################################# [ 44%]
>    8:gcc-7.3.1-5.fc27                 ################################# [ 50%]
>    9:hwloc-libs-1.11.5-6.fc27         ################################# [ 56%]
>   10:pocl-0.15-0.1.20171023git53ef5e8.################################# [ 63%]
>   11:gcc-c++-7.3.1-5.fc27             ################################# [ 69%]
>   12:gcc-gdb-plugin-7.3.1-5.fc27      ################################# [ 75%]
>   13:libtool-2.4.6-20.fc27            ################################# [ 81%]
>   14:kernel-4.15.9-300.fc27           ################################# [ 88%]
>   15:kernel-modules-extra-4.15.9-300.f################################# [ 94%]
>   16:kernel-devel-4.15.9-300.fc27     ################################# [100%]
> cat: write error: Broken pipe
> Running as unit: run-rff037a106b224379a6a6288281705dcb.service

The new kernel is still not in /boot. The rescue directory has returned.
> # ls /boot
> 7725dfc225d14958a625ddaaaea5962b
> config-4.14.11-300.fc27.x86_64
> efi
> extlinux
> grub2
> initramfs-0-rescue-7725dfc225d14958a625ddaaaea5962b.img
> initramfs-4.14.11-300.fc27.x86_64.img
> initrd-plymouth.img
> loader
> lost+found
> System.map-4.14.11-300.fc27.x86_64
> vmlinuz-0-rescue-7725dfc225d14958a625ddaaaea5962b
> vmlinuz-4.14.11-300.fc27.x86_64

It seems clear that some script or scriptlet in the package is not doing
its job. But they seem pretty simple and I don't see any dependencies
which would make them fail on this machine and not others.
> # rpm -qp --scripts kernel-core-4.15.9-300.fc27.x86_64.rpm
> postinstall scriptlet (using /bin/sh):
>
> if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
>    [ -f /etc/sysconfig/kernel ]; then
>   /bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
> fi
> preuninstall scriptlet (using /bin/sh):
> /bin/kernel-install remove 4.15.9-300.fc27.x86_64 /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz || exit $?
> posttrans scriptlet (using /bin/sh):
> /bin/kernel-install add 4.15.9-300.fc27.x86_64 /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz || exit $?

[Roger Heflin]

I would run this and see where rpm thinks they should be since they
are not in /boot
 rpm -qa --filesbypkg | grep -i vmlinuz

On Tue, Mar 20, 2018 at 2:05 PM, CLOSE Dave
 wrote:
> The following procedure did NOT fix my problem. Using RPM instead of DNF
> still did not install the new kernel in /boot.
>
> Note, the new kernel is not in /boot when I start.
> > # ls /boot
> > 7725dfc225d14958a625ddaaaea5962b
> > config-4.14.11-300.fc27.x86_64
> > efi
> > extlinux
> > grub2
> > initramfs-0-rescue-7725dfc225d14958a625ddaaaea5962b.img
> > initramfs-4.14.11-300.fc27.x86_64.img
> > initrd-plymouth.img
> > loader
> > lost+found
> > System.map-4.14.11-300.fc27.x86_64
> > vmlinuz-0-rescue-7725dfc225d14958a625ddaaaea5962b
> > vmlinuz-4.14.11-300.fc27.x86_64
>
> RPM won't install the new kernel since it is already installed.
> > # mkdir temp
> > # cd temp
> > # dnf download kernel-core-4.15.9-300.fc27.x86_64
> > # rpm -ivh kernel-core-4.15.9-300.fc27.x86_64
> > Preparing...                          ################################# [100%]
> >        package kernel-core-4.15.9-300.fc27.x86_64 is already installed
>
> Get the rescue directory out of the way. Remove the new kernel completely.
> > # mv /boot/7725dfc225d14958a625ddaaaea5962b /tmp
> > # dnf -y remove kernel*-4.15.9-300.fc27.x86_64
> > Removing:
> >  kernel               x86_64 4.15.9-300.fc27                     @updates   0
> >  kernel-core          x86_64 4.15.9-300.fc27                     @updates  58 M
> >  kernel-devel         x86_64 4.15.9-300.fc27                     @updates  48 M
> >  kernel-headers       x86_64 4.15.9-300.fc27                     @updates 4.3 M
> >  kernel-modules       x86_64 4.15.9-300.fc27                     @updates  26 M
> >  kernel-modules-extra x86_64 4.15.9-300.fc27                     @updates 2.1 M
> > Removing dependent packages:
> >  gcc                  x86_64 7.3.1-5.fc27                        @updates  52 M
> >  gcc-c++              x86_64 7.3.1-5.fc27                        @updates  27 M
> >  gcc-gdb-plugin       x86_64 7.3.1-5.fc27                        @updates 316 k
> >  glibc-devel          x86_64 2.26-27.fc27                        @updates 1.1 M
> >  glibc-headers        x86_64 2.26-27.fc27                        @updates 2.2 M
> >  libtool              x86_64 2.4.6-20.fc27                       @fedora  2.6 M
> >  pocl                 x86_64 0.15-0.1.20171023git53ef5e8.fc27    @updates 222 M
> > Removing unused dependencies:
> >  hwloc-libs           x86_64 1.11.5-6.fc27                       @fedora  2.1 M
> >  isl                  x86_64 0.16.1-3.fc27                       @fedora  2.9 M
> >  libstdc++-devel      x86_64 7.3.1-5.fc27                        @updates  10 M
>
> Try to install the new kernel using RPM.
> > # dnf download gcc-7.3.1-5.fc27.x86_64 \
> >       gcc-c++-7.3.1-5.fc27.x86_64 \
> >       gcc-gdb-plugin-7.3.1-5.fc27.x86_64 \
> >       glibc-devel-2.26-27.fc27.x86_64 \
> >       glibc-headers-2.26-27.fc27.x86_64 \
> >       hwloc-libs-1.11.5-6.fc27.x86_64 \
> >       isl-0.16.1-3.fc27.x86_64 \
> >       kernel-4.15.9-300.fc27.x86_64 \
> >       kernel-devel-4.15.9-300.fc27.x86_64 \
> >       kernel-headers-4.15.9-300.fc27.x86_64 \
> >       kernel-modules-4.15.9-300.fc27.x86_64 \
> >       kernel-modules-extra-4.15.9-300.fc27.x86_64 \
> >       libstdc++-devel-7.3.1-5.fc27.x86_64 \
> >       libtool-2.4.6-20.fc27.x86_64 \
> >       pocl-0.15-0.1.20171023git53ef5e8.fc27.x86_64
> > # rpm -ivh *
> > Preparing...                          ################################# [100%]
> > Updating / installing...
> >    1:kernel-core-4.15.9-300.fc27      ################################# [  6%]
> >    2:kernel-modules-4.15.9-300.fc27   ################################# [ 13%]
> >    3:libstdc++-devel-7.3.1-5.fc27     ################################# [ 19%]
> >    4:kernel-headers-4.15.9-300.fc27   ################################# [ 25%]
> >    5:glibc-headers-2.26-27.fc27       ################################# [ 31%]
> >    6:glibc-devel-2.26-27.fc27         ################################# [ 38%]
> >    7:isl-0.16.1-3.fc27                ################################# [ 44%]
> >    8:gcc-7.3.1-5.fc27                 ################################# [ 50%]
> >    9:hwloc-libs-1.11.5-6.fc27         ################################# [ 56%]
> >   10:pocl-0.15-0.1.20171023git53ef5e8.################################# [ 63%]
> >   11:gcc-c++-7.3.1-5.fc27             ################################# [ 69%]
> >   12:gcc-gdb-plugin-7.3.1-5.fc27      ################################# [ 75%]
> >   13:libtool-2.4.6-20.fc27            ################################# [ 81%]
> >   14:kernel-4.15.9-300.fc27           ################################# [ 88%]
> >   15:kernel-modules-extra-4.15.9-300.f################################# [ 94%]
> >   16:kernel-devel-4.15.9-300.fc27     ################################# [100%]
> > cat: write error: Broken pipe
> > Running as unit: run-rff037a106b224379a6a6288281705dcb.service
>
> The new kernel is still not in /boot. The rescue directory has returned.
> > # ls /boot
> > 7725dfc225d14958a625ddaaaea5962b
> > config-4.14.11-300.fc27.x86_64
> > efi
> > extlinux
> > grub2
> > initramfs-0-rescue-7725dfc225d14958a625ddaaaea5962b.img
> > initramfs-4.14.11-300.fc27.x86_64.img
> > initrd-plymouth.img
> > loader
> > lost+found
> > System.map-4.14.11-300.fc27.x86_64
> > vmlinuz-0-rescue-7725dfc225d14958a625ddaaaea5962b
> > vmlinuz-4.14.11-300.fc27.x86_64
>
> It seems clear that some script or scriptlet in the package is not doing
> its job. But they seem pretty simple and I don't see any dependencies
> which would make them fail on this machine and not others.
> > # rpm -qp --scripts kernel-core-4.15.9-300.fc27.x86_64.rpm
> > postinstall scriptlet (using /bin/sh):
> >
> > if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
> >    [ -f /etc/sysconfig/kernel ]; then
> >   /bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
> > fi
> > preuninstall scriptlet (using /bin/sh):
> > /bin/kernel-install remove 4.15.9-300.fc27.x86_64 /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz || exit $?
> > posttrans scriptlet (using /bin/sh):
> > /bin/kernel-install add 4.15.9-300.fc27.x86_64 /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz || exit $?
>
> --
>         Dave Close
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[CLOSE Dave]

Roger Heflin wrote:
> I would run this and see where rpm thinks they should be since they
> are not in /boot
>  rpm -qa --filesbypkg | grep -i vmlinuz

Evidently, RPM thinks they should be in /boot (as I would expect):
> $ rpm -qa --filesbypkg | grep -i vmlinuz
> kernel-core      /boot/.vmlinuz-4.15.9-300.fc27.x86_64.hmac
> kernel-core      /boot/vmlinuz-4.15.9-300.fc27.x86_64
> kernel-core      /lib/modules/4.15.9-300.fc27.x86_64/.vmlinuz.hmac
> kernel-core      /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz
> kernel-core      /boot/.vmlinuz-4.14.11-300.fc27.x86_64.hmac
> kernel-core      /boot/vmlinuz-4.14.11-300.fc27.x86_64
> kernel-core      /lib/modules/4.14.11-300.fc27.x86_64/.vmlinuz.hmac
> kernel-core      /lib/modules/4.14.11-300.fc27.x86_64/vmlinuz
> kernel-core      /boot/.vmlinuz-4.15.8-300.fc27.x86_64.hmac
> kernel-core      /boot/vmlinuz-4.15.8-300.fc27.x86_64
> kernel-core      /lib/modules/4.15.8-300.fc27.x86_64/.vmlinuz.hmac
> kernel-core      /lib/modules/4.15.8-300.fc27.x86_64/vmlinuz

[Stephen Morris]

On 21/3/18 7:24 am, CLOSE Dave wrote:
> Roger Heflin wrote:
> > I would run this and see where rpm thinks they should be since they
> > are not in /boot
> >   rpm -qa --filesbypkg | grep -i vmlinuz
>
> Evidently, RPM thinks they should be in /boot (as I would expect):
> > $ rpm -qa --filesbypkg | grep -i vmlinuz
> > kernel-core      /boot/.vmlinuz-4.15.9-300.fc27.x86_64.hmac
> > kernel-core      /boot/vmlinuz-4.15.9-300.fc27.x86_64
> > kernel-core      /lib/modules/4.15.9-300.fc27.x86_64/.vmlinuz.hmac
> > kernel-core      /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz
> > kernel-core      /boot/.vmlinuz-4.14.11-300.fc27.x86_64.hmac
> > kernel-core      /boot/vmlinuz-4.14.11-300.fc27.x86_64
> > kernel-core      /lib/modules/4.14.11-300.fc27.x86_64/.vmlinuz.hmac
> > kernel-core      /lib/modules/4.14.11-300.fc27.x86_64/vmlinuz
> > kernel-core      /boot/.vmlinuz-4.15.8-300.fc27.x86_64.hmac
> > kernel-core      /boot/vmlinuz-4.15.8-300.fc27.x86_64
> > kernel-core      /lib/modules/4.15.8-300.fc27.x86_64/.vmlinuz.hmac
> > kernel-core      /lib/modules/4.15.8-300.fc27.x86_64/vmlinuz

Just as a matter of interest, the directories on my system in 
/boot/"rescue directory", of which there are only 3 matching the 
installed kernels are all empty.

Also, where are the config, initramfs and system.map files stored for 
the kernels you have installed?

I also have a couple of questions (which may be off topic here) around 
the contents of /boot.

With the dkms compiling of my wifi, nvidia and mouse drivers, a recent 
innovation in dkms is to run dracut. The first thing that dracut does is 
create a backup copy of the relevant initramfs before it rebuilds it. 
Are we required to manually remove those dracut created backups when dnf 
removes the associated kernel?

Secondly, does anyone else have .vmlinuz.hmac-$(kernelver) files lying 
around in /boot? I have a mountain of these in there, of which only 1 
actually matches an installed kernel. The name of one of these files, 
because its name is non-standard compared to the rest, is potentially 
giving an indication of where they originated from, but I just wanted to 
check whether they were normal, and whether or not like the dracut 
backup, we are expected to remove them manually?

regards,

Steve

[Ed Greshko]

On 03/21/18 04:54, Stephen Morris wrote:
> I also have a couple of questions (which may be off topic here)

Yes, for sure off-topic.

You need to start your own thread if you encounter questions not related to resolving
the issue of an OP.

[Roger Heflin]

The only way I know to produce these results would be to override the
build_root location someplace.

echo ${RPM_BUILD_ROOT}

There are probably other ways to override it.

On Tue, Mar 20, 2018 at 3:24 PM, CLOSE Dave
 wrote:
> Roger Heflin wrote:
> > I would run this and see where rpm thinks they should be since they
> > are not in /boot
> >  rpm -qa --filesbypkg | grep -i vmlinuz
>
> Evidently, RPM thinks they should be in /boot (as I would expect):
> > $ rpm -qa --filesbypkg | grep -i vmlinuz
> > kernel-core      /boot/.vmlinuz-4.15.9-300.fc27.x86_64.hmac
> > kernel-core      /boot/vmlinuz-4.15.9-300.fc27.x86_64
> > kernel-core      /lib/modules/4.15.9-300.fc27.x86_64/.vmlinuz.hmac
> > kernel-core      /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz
> > kernel-core      /boot/.vmlinuz-4.14.11-300.fc27.x86_64.hmac
> > kernel-core      /boot/vmlinuz-4.14.11-300.fc27.x86_64
> > kernel-core      /lib/modules/4.14.11-300.fc27.x86_64/.vmlinuz.hmac
> > kernel-core      /lib/modules/4.14.11-300.fc27.x86_64/vmlinuz
> > kernel-core      /boot/.vmlinuz-4.15.8-300.fc27.x86_64.hmac
> > kernel-core      /boot/vmlinuz-4.15.8-300.fc27.x86_64
> > kernel-core      /lib/modules/4.15.8-300.fc27.x86_64/.vmlinuz.hmac
> > kernel-core      /lib/modules/4.15.8-300.fc27.x86_64/vmlinuz
>
> --
> Dave Close, Thales InFlyt Experience, Irvine California USA.
> cell [phone], [e-mail]
>
> "1800: Joseph Marie Jacquard teaches a loom to read punch cards,
>   creating the first heavily multi-threaded processing unit."
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Ed Greshko]

On 03/21/18 03:05, CLOSE Dave wrote:
> It seems clear that some script or scriptlet in the package is not doing
> its job. But they seem pretty simple and I don't see any dependencies
> which would make them fail on this machine and not others.
> > # rpm -qp --scripts kernel-core-4.15.9-300.fc27.x86_64.rpm
> > postinstall scriptlet (using /bin/sh):
> >
> > if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
> >    [ -f /etc/sysconfig/kernel ]; then
> >   /bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
> > fi
> > preuninstall scriptlet (using /bin/sh):
> > /bin/kernel-install remove 4.15.9-300.fc27.x86_64 /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz || exit $?
> > posttrans scriptlet (using /bin/sh):
> > /bin/kernel-install add 4.15.9-300.fc27.x86_64 /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz || exit $?

That would seem to be a fair conclusion.

I think I would look at the kernel-install script a bit more.  It seems it may be
calling the scripts in /usr/lib/kernel/install.d

[CLOSE Dave]

Ed Greshko wrote:
> > It seems clear that some script or scriptlet in the package is not doing
> > its job. But they seem pretty simple and I don't see any dependencies
> > which would make them fail on this machine and not others.
> That would seem to be a fair conclusion.
>
> I think I would look at the kernel-install script a bit more.  It seems it may be
> calling the scripts in /usr/lib/kernel/install.d

All of these scripts, /bin/kernel-install and
/usr/lib/kernel/install.d/*, are identical on this problem machine with
those on several other local machines which are not having this problem.

[CLOSE Dave]

I think I found the problem. Comparing packages installed on this
problem machine with others, I noticed that grubby was not installed.
After installing it and then re-installing the kernel, I find the kernel
in /boot where it belongs.

Evidently, something isn't checking dependencies sufficiently. I saw no
error messages indicating anything was missing.

[Ed Greshko]

On 03/21/18 07:02, CLOSE Dave wrote:
> I think I found the problem. Comparing packages installed on this
> problem machine with others, I noticed that grubby was not installed.
> After installing it and then re-installing the kernel, I find the kernel
> in /boot where it belongs.
>
> Evidently, something isn't checking dependencies sufficiently. I saw no
> error messages indicating anything was missing.

If that turns out to be the case, and if things on that machine used to work, it
would be interesting to know if/when grubby was removed.

Also, if it fails with grubby out it sounds like a very good bugzilla.

[CLOSE Dave]

Greshko wrote:
> > I think I found the problem. Comparing packages installed on this 
> > problem machine with others, I noticed that grubby was not 
> > installed. After installing it and then re-installing the kernel,
> > I find the kernel in /boot where it belongs.
> >
> > Evidently, something isn't checking dependencies sufficiently. I 
> > saw no error messages indicating anything was missing.
> If that turns out to be the case, and if things on that machine used 
> to work, it would be interesting to know if/when grubby was removed.

Too long ago to still be in my /var/log/dnf* logs. Evidently, some time
after kernel 4.14.11-300.fc27.x86_64 as that was the last one properly
placed in /boot.
> Also, if it fails with grubby out it sounds like a very good 
> bugzilla.

True.

[Ed Greshko]

On 03/21/18 07:46, CLOSE Dave wrote:
> Greshko wrote:
> > > I think I found the problem. Comparing packages installed on this 
> > > problem machine with others, I noticed that grubby was not 
> > > installed. After installing it and then re-installing the kernel,
> > > I find the kernel in /boot where it belongs.
> > >
> > > Evidently, something isn't checking dependencies sufficiently. I 
> > > saw no error messages indicating anything was missing.
> >
> > If that turns out to be the case, and if things on that machine used 
> > to work, it would be interesting to know if/when grubby was removed.
>
> Too long ago to still be in my /var/log/dnf* logs. Evidently, some time
> after kernel 4.14.11-300.fc27.x86_64 as that was the last one properly
> placed in /boot.

OK...
> > Also, if it fails with grubby out it sounds like a very good 
> > bugzilla.
>
> True.

I have tested this in a VM and verified the failure.  There is one exception.  If the
/boot directory does not contain a directory with the name of the "machine-id" then
the upgrade will be successful.

Will you be writing up the BZ?

[CLOSE Dave]

Ed Greshko wrote:
> I have tested this in a VM and verified the failure.  There is one
> exception.  If the /boot directory does not contain a directory with
> the name of the "machine-id" then the upgrade will be successful.
>
> Will you be writing up the BZ?

Bug 1559118.

[Ed Greshko]

On 03/21/18 01:09, CLOSE Dave wrote:
> Ed Greshko wrote:
> > > > All of those directories are empty, yes?
> > >
> > > Most, but not all:
> > > > /boot/7725dfc225d14958a625ddaaaea5962b/4.15.8-300.fc27.x86_64:
> > > > initrd  linux
> > > > /boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64:
> > > > initrd  linux
> >
> > I get the feeling, based on the name of the directory and most of 
> > them being empty, that these are just "temporary" directories that
> > are just not getting deleted for some reason.  I doubt there would be
> > any problem to delete them.
>
> Thanks. But that isn't the issue. The issue is that the
> 4.15.9-300.fc27.x86_64 files are NOT in /boot directly so they aren't
> found by mkconfig. Of course, I could copy them there but that doesn't
> seem like it should be necessary.

I see.  I misunderstood an earlier post.

Anyway, I've since determined that the directory name
7725dfc225d14958a625ddaaaea5962b is derived from the contents of /etc/machine-id

[Tim]

Allegedly, on or about 21 March 2018, Ed Greshko sent:
> Anyway, I've since determined that the directory name
> 7725dfc225d14958a625ddaaaea5962b is derived from the contents of
> /etc/machine-id

For what it's worth, I have a collection of those empty directories on
my older installation (FC26), and two sets because I changed a
motherboard.  The bizarre conglomeration of directories made no sense,
to me, until your comment, above.

https://paste.fedoraproject.org/paste/SZkbx0H8W09msV5jVjpliw

But it strikes me, though, are these empty directories something that
ought to get erased once the kernel has been installed?  Is there any
point to them being there.

[Ed Greshko]

On 03/21/18 14:48, Tim wrote:
> Allegedly, on or about 21 March 2018, Ed Greshko sent:
> > Anyway, I've since determined that the directory name
> > 7725dfc225d14958a625ddaaaea5962b is derived from the contents of
> > /etc/machine-id
>
> For what it's worth, I have a collection of those empty directories on
> my older installation (FC26), and two sets because I changed a
> motherboard.  The bizarre conglomeration of directories made no sense,
> to me, until your comment, above.
>
> https://paste.fedoraproject.org/paste/SZkbx0H8W09msV5jVjpliw
>
> But it strikes me, though, are these empty directories something that
> ought to get erased once the kernel has been installed?  Is there any
> point to them being there.

Yes, I think those empty directories should have been deleted by some process.  I
can't see a point in leaving those around.

Now, I'm trying to decided what component to file the BZ about the install failure
when grubby is erased.  I'm thinking it should be filed against "kernel" and that an
added require of /sbin/new-kernel-pkg be added to ensure grubby is installed.