Kernel 4.11.2-300.fc26 INSTALLED, but DOES NOT appear as entry in GRUB2???

[nobody]

Kernel 4.11.2-300.fc26 INSTALLED, but DOES NOT appear as entry in GRUB2???
https://bugzilla.redhat.com/show_bug.cgi?id=1460147

_nobody_

[nobody]

From: http://www.forums.fedoraforum.org/sh...6&postcount=12

Logically, 1+1=2, and the following was the product of 1+1!

https://bugzilla.redhat.com/show_bug.cgi?id=1460147#c1

niemand 2017-06-09 16:24:35 EDT
I managed to find where rpm stores the update database:
http://www.forums.fedoraforum.org/sh...6&postcount=12

So even kernel 4.11.2-300.fc26.x86_64 does NOT have representatives in /boot:

[root@localhost boot]# ls -al
total 124880
dr-xr-xr-x. 8 root root 4096 Jun 7 06:26 .
dr-xr-xr-x. 18 root root 4096 Mar 29 21:20 ..
drwxr-xr-x. 6 root root 4096 Jun 7 06:26 5a76d41d758649feb94e3abdbfa7157f
-rw-r--r--. 1 root root 185326 May 25 21:00 config-4.11.3-300.fc26.x86_64
-rw-r--r--. 1 root root 185315 Jun 5 20:59 config-4.11.3-302.fc26.x86_64
drwxr-xr-x. 3 root root 4096 Mar 29 21:23 dbed1a205afe4fd3b60050c0e205222f
drwx------. 4 root root 4096 Mar 29 21:23 efi
-rw-r--r--. 1 root root 184380 Feb 11 06:58 elf-memtest86+-5.01
drwxr-xr-x. 2 root root 4096 Mar 29 21:21 extlinux
drwxr-xr-x. 6 root root 4096 Jun 7 06:26 grub2
-rw-------. 1 root root 56980221 May 14 19:54 initramfs-0-rescue-5a76d41d758649feb94e3abdbfa7157f.img
-rw-------. 1 root root 20570156 May 27 09:42 initramfs-4.11.3-300.fc26.x86_64.img
-rw-------. 1 root root 20571538 Jun 7 06:26 initramfs-4.11.3-302.fc26.x86_64.img
drwx------. 2 root root 16384 May 14 19:50 lost+found
-rw-r--r--. 1 root root 182704 Feb 11 06:58 memtest86+-5.01
-rw-------. 1 root root 3549687 May 25 21:00 System.map-4.11.3-300.fc26.x86_64
-rw-------. 1 root root 3549687 Jun 5 20:59 System.map-4.11.3-302.fc26.x86_64
-rwxr-xr-x. 1 root root 7262808 May 14 19:54 vmlinuz-0-rescue-5a76d41d758649feb94e3abdbfa7157f
-rwxr-xr-x. 1 root root 7282776 May 25 21:01 vmlinuz-4.11.3-300.fc26.x86_64
-rw-r--r--. 1 root root 167 May 25 20:56 .vmlinuz-4.11.3-300.fc26.x86_64.hmac
-rwxr-xr-x. 1 root root 7282776 Jun 5 21:00 vmlinuz-4.11.3-302.fc26.x86_64
-rw-r--r--. 1 root root 167 Jun 5 20:53 .vmlinuz-4.11.3-302.fc26.x86_64.hmac
[root@localhost boot]#

It does exist in rpm local database:

[root@localhost log]# dnf list installed | grep kernel
abrt-addon-kerneloops.x86_64 2.10.2-2.fc26 @updates-testing
kernel.x86_64 4.11.2-300.fc26 @updates-testing
kernel.x86_64 4.11.3-300.fc26 @updates-testing
kernel.x86_64 4.11.3-302.fc26 @updates-testing
kernel-core.x86_64 4.11.2-300.fc26 @System
kernel-core.x86_64 4.11.3-300.fc26 @updates-testing
kernel-core.x86_64 4.11.3-302.fc26 @updates-testing
kernel-devel.x86_64 4.11.2-300.fc26 @System
kernel-devel.x86_64 4.11.3-300.fc26 @updates-testing
kernel-devel.x86_64 4.11.3-302.fc26 @updates-testing
kernel-headers.x86_64 4.11.3-302.fc26 @updates-testing
kernel-modules.x86_64 4.11.2-300.fc26 @System
kernel-modules.x86_64 4.11.3-300.fc26 @updates-testing
kernel-modules.x86_64 4.11.3-302.fc26 @updates-testing
kernel-modules-extra.x86_64 4.11.2-300.fc26 @System
kernel-modules-extra.x86_64 4.11.3-300.fc26 @updates-testing
kernel-modules-extra.x86_64 4.11.3-302.fc26 @updates-testing
libreport-plugin-kerneloops.x86_64 2.9.1-2.fc26 @updates-testing
[root@localhost log]#
_______

The question is: why installation of kernel 4.11.2-300.fc26.x86_64 abruptly/violently exited, not finishing obvious installation to the /boot directory???

Few possible reasons for that:
[1] Kernel 4.11.2-300.fc26.x86_64 scrip-let had fatal error?
[2] mkinitrd script had fatal error?
[3] You, Fedora 26 kernel maintainers, name other reason(s)???

Thank you,

_nobody_

[erm67]

dnf crashed a couple of times for me as well in the previous days of alpha 26 ....
Try this it worked for me:
rebuild the rpm database
https://docs.fedoraproject.org/en-US...h04s05s02.html
and verify the installed packages
https://docs.fedoraproject.org/en-US...e/ch04s04.html

I did a couple of times already after dnf crashes.

[antikythera]

dnf works fine for me, dnfdragora exits early occasionally but the transactions are completed by dnf once initiated anyhow. therefore i rely more on dnf for updates from the command line.

also, this morning there's kernel 4.11.4-300 being installed so it will be interesting to see if that works properly and tidies up the leftovers for you nobody

[srakitnican]

The question is: why installation of kernel 4.11.2-300.fc26.x86_64 abruptly/violently exited, not finishing obvious installation to the /boot directory???

dnf history info <id>

[nobody]

Dear Virtual Fedora Friends,

Thank you for insights. I rebuilt RPM (Red Hat Linux Package Manager) using the pointer, shown to me: Rebuilding the RPM database.

As discussed, I backed/cloned (apriori rebuilding RPM's local database) the whole rpm/ directory to rpm_backup/ (just in case). After, rebuilt with: rpm --rebuilddb .

I upgraded Fedora 26, and got 3 kernels, thus everything works perfectly.

[user@localhost ~]$ cd /boot
[user@localhost boot]$ uname -r
4.11.4-300.fc26.x86_64
[user@localhost boot]$ ls -al
total 155748
dr-xr-xr-x. 8 root root 4096 Jun 10 11:19 .
dr-xr-xr-x. 18 root root 4096 Mar 29 21:20 ..
drwxr-xr-x. 7 root root 4096 Jun 10 11:19 5a76d41d758649feb94e3abdbfa7157f
-rw-r--r--. 1 root root 185326 May 25 21:00 config-4.11.3-300.fc26.x86_64
-rw-r--r--. 1 root root 185315 Jun 5 20:59 config-4.11.3-302.fc26.x86_64
-rw-r--r--. 1 root root 185315 Jun 7 20:23 config-4.11.4-300.fc26.x86_64
drwxr-xr-x. 3 root root 4096 Mar 29 21:23 dbed1a205afe4fd3b60050c0e205222f
drwx------. 4 root root 4096 Mar 29 21:23 efi
-rw-r--r--. 1 root root 184380 Feb 11 06:58 elf-memtest86+-5.01
drwxr-xr-x. 2 root root 4096 Mar 29 21:21 extlinux
drwxr-xr-x. 6 root root 4096 Jun 10 11:19 grub2
-rw-------. 1 root root 56980221 May 14 19:54 initramfs-0-rescue-5a76d41d758649feb94e3abdbfa7157f.img
-rw-------. 1 root root 20570156 May 27 09:42 initramfs-4.11.3-300.fc26.x86_64.img
-rw-------. 1 root root 20571538 Jun 7 06:26 initramfs-4.11.3-302.fc26.x86_64.img
-rw-------. 1 root root 20573270 Jun 10 11:19 initramfs-4.11.4-300.fc26.x86_64.img
drwx------. 2 root root 16384 May 14 19:50 lost+found
-rw-r--r--. 1 root root 182704 Feb 11 06:58 memtest86+-5.01
-rw-------. 1 root root 3549687 May 25 21:00 System.map-4.11.3-300.fc26.x86_64
-rw-------. 1 root root 3549687 Jun 5 20:59 System.map-4.11.3-302.fc26.x86_64
-rw-------. 1 root root 3550042 Jun 7 20:23 System.map-4.11.4-300.fc26.x86_64
-rwxr-xr-x. 1 root root 7262808 May 14 19:54 vmlinuz-0-rescue-5a76d41d758649feb94e3abdbfa7157f
-rwxr-xr-x. 1 root root 7282776 May 25 21:01 vmlinuz-4.11.3-300.fc26.x86_64
-rw-r--r--. 1 root root 167 May 25 20:56 .vmlinuz-4.11.3-300.fc26.x86_64.hmac
-rwxr-xr-x. 1 root root 7282776 Jun 5 21:00 vmlinuz-4.11.3-302.fc26.x86_64
-rw-r--r--. 1 root root 167 Jun 5 20:53 .vmlinuz-4.11.3-302.fc26.x86_64.hmac
-rwxr-xr-x. 1 root root 7286872 Jun 7 20:24 vmlinuz-4.11.4-300.fc26.x86_64
-rw-r--r--. 1 root root 167 Jun 7 20:19 .vmlinuz-4.11.4-300.fc26.x86_64.hmac
[user@localhost boot]$

There is still "but"... The questions I have asked Fedora 26 kernel maintainers remain in effect. Me and erm67 (and, my best guess, srak and AK) need to know answers to my questions (in Fedora bugzilla 1460147: https://bugzilla.redhat.com/show_bug.cgi?id=1460147)!

Since 1460147 has NOTHING to do with RPM, everything with kernel 4.11.2-300.fc26.x86_64 and its packaging?!

_nobody_

[erm67]

Well, what happened ... probably when dnf/rpm crashed during to an update a few days ago it failed to update some entries relative to that kernel on your system but you were so lucky that the database was still functional, you did not notice the failure during the update (otherwise you had rebuilt the rpm database :-) ). I was less lucky since after the dnf/rpm crash the database was not functional and dnf did not work so Iwas forced to fix imediately the database. I was ready for some radical rebuild like this:
https://people.redhat.com/berrange/n...mrecovery.html

but luckily rebuilddb worked at the first attempt.

It's an alpha it is expetd that something like that happens, keep an eye on the updates and rebuild the database after every hard failure (segfaults).

---------- Post added at 03:38 PM ---------- Previous post was at 03:38 PM ----------

Well, what happened ... probably when dnf/rpm crashed during to an update a few days ago it failed to update some entries relative to that kernel on your system but you were so lucky that the database was still functional, you did not notice the failure during the update (otherwise you had rebuilt the rpm database :-) ). I was less lucky since after the dnf/rpm crash the database was not functional and dnf did not work so Iwas forced to fix imediately the database. I was ready for some radical rebuild like this:
https://people.redhat.com/berrange/n...mrecovery.html

but luckily rebuilddb worked at the first attempt.

It's an alpha it is expetd that something like that happens, keep an eye on the updates and rebuild the database after every hard failure (segfaults).

[nobody]

Well, what happened ... probably when dnf/rpm crashed during to an update a few days ago it failed to update some entries relative to that kernel on your system but you were so lucky that the database was still functional, you did not notice the failure during the update (otherwise you had rebuilt the rpm database :-) ). I was less lucky since after the dnf/rpm crash the database was not functional and dnf did not work so Iwas forced to fix immediately the database. I was ready for some radical rebuild like this:
https://people.redhat.com/berrange/n...mrecovery.html

but luckily rebuilddb worked at the first attempt.

It's an alpha it is expected that something like that happens, keep an eye on the updates and rebuild the database after every hard failure (segfaults).

I've noticed after the whole thing crashed, that actually the kernel is the reason. Then I checked /boot, /lib/modules and /usr/src/kernels directories, to find that last two are correctly installed, but /boot has no any trace of it (4.11.2-300.fc26).

Next day I did another update, and, magically, the new 4.11.3-300.fc26 appeared, correctly installed. Fedora kernel maintainers do NOT change/upgrade kernels every day. So, I had smoking gun right there.

We have to know what really happened there, and WHY it happened?! I was lucky, I admit, but next time I might be NOT so lucky... Correct?

I'll also report/import this post into the Bugzilla 1460147. Let us see what Peter Jones and Laura Abbott have to say about all this mess???

_nobody_

[erm67]

Well did you follow this guide to check if everything is ok after the segfault?
https://docs.fedoraproject.org/en-US...e/ch04s04.html

rpm -Va

showed several MD5 mismatches in my system so I verified my (updated) system

sudo dnf repoquery --unsatisfied

showed a couple of packages with broken dependencies So I used

sudo dnf distro-sync --allowerasing

and it reinstalled several packages but there wer still some MD5 failures so I issued

sudo dnf repoquery --duplicated

and it found a package that was installed twice (and removing it fixed most MD5 failures)

for the final touches I used

sudo dnf list extras

to find packages not provided by any configure repository and this found 2 f25 packages that were not updated for some reason (and I removed them)

for the final touches I issued

sudo dnf autoremove

but it found noothing to do

and a

sudo touch /.autorelabel

since selinux policies were recently updated

now my F26 install should be perfctly in-sync with the repositories.

Is your install in-sync?

Is it possible that dnf/rpm crashed on my system because it wasn't correctly installed/updated?

[nobody]

Well did you follow this guide to check if everything is ok after the segfault?
https://docs.fedoraproject.org/en-US...e/ch04s04.html
...
[snap]
...

The question is much simpler, erm?!

Could you (or anybody else) run kernel 4.11.2-300.fc26.x86_64? I can NOT!

_nobody_

[antikythera]

I did use it before it was removed by subsequent updates. I now have:

4.11.4-300
4.11.3-302
4.11.3-300

all of which are bootable in my Virtualbox install

[erm67]

The question is much simpler, erm?!

Could you (or anybody else) run kernel 4.11.2-300.fc26.x86_64? I can NOT!

_nobody_

It's an old kernel why hould you want to use it?

[nobody]

I did use it before it was removed by subsequent updates. I now have:

4.11.4-300
4.11.3-302
4.11.3-300

all of which are bootable in my Virtualbox install

I have all of them bootable as well... But the 4th one (4.11.2-300) was not. Or, maybe, still, erm is correct: maybe some other glitch made this failure.

The main suspicion, though, is that the new kernel at the time (4.11.3-300) came less that 24 hours after (4.11.2-300).

_nobody_

[srakitnican]

The question is much simpler, erm?!

Could you (or anybody else) run kernel 4.11.2-300.fc26.x86_64? I can NOT!

_nobody_

Sure you can, you can install it from koji.

https://koji.fedoraproject.org/koji/...buildID=896107

I have no desire to test old kernel builds, sorry. My suspicion is that something went wrong with upgrade on your machine and that package itself is fine.

[nobody]

What about this, my dear Srak/Wattson?

Bug 1443415 - [TRACKING] Upgrade f25 to f26 get stuck in Cleanup
https://bugzilla.redhat.com/show_bug.cgi?id=1443415

Comment 29 Branko Grubić (bitlord) 2017-05-26 00:39 EDT
Created attachment 1282477 [details]
upgrade_fail

This could be relate to this bug. During upgrade my dnf crashed with:

...
Running scriptlet: qpdf-libs-6.0.0-4.fc26.x86_64 107/112
Cleanup : microcode_ctl-2:2.1-14.1.fc26.x86_64 108/112
Cleanup : libv4l-1.12.5-1.fc26.x86_64 109/112
Running scriptlet: libv4l-1.12.5-1.fc26.x86_64 109/112
Running scriptlet: gssproxy-0.7.0-7.fc26.x86_64 110/112
Floating point exception (core dumped)

Now even 'rpm' doesn't work it crashes.

Comment 30 Andre Robatino 2017-05-26 01:12:31 EDT
> Now even 'rpm' doesn't work it crashes.

That happened to me yesterday during a yum update of a F26 guest. It looks like the rpm database format changed. You have to rebuild the rpm database. I followed the instructions at https://ma.ttias.be/yum-update-db_ru...base-recovery/ (you'd use the corresponding instructions for dnf) and then ran yum-complete-transaction (don't know the dnf command) and then everything was fine again.

Comment 31 Andre Robatino 2017-05-26 01:33:29 EDT
I take it back - AFAIK the rpm database format didn't change, but as I said, rebuilding the rpm database did fix my problem.

Comment 32 Adam Williamson 2017-05-26 02:05:47 EDT
It certainly seems plausible that you ran into basically the same problem the composes are hitting, whatever it is, and a database rebuild would shift it. I've now unpushed the update for F26 as well, so hopefully no-one else will run into it.

Where this Fedora test prime guy Adam Williamson hides (I would like to know), so I can find him and pull his ears (very hard way) up, people???

_nobody_