Bug 11827 - initrd missing for newest kernel after upgrading with classical iso when using grub2
Summary: initrd missing for newest kernel after upgrading with classical iso when usin...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Barry Jackson
QA Contact:
URL:
Whiteboard: MGA5TOO
Keywords:
Depends on:
Blocks: 15637
  Show dependency treegraph
 
Reported: 2013-11-30 08:13 CET by Marja Van Waes
Modified: 2015-06-16 13:21 CEST (History)
6 users (show)

See Also:
Source RPM: grub2
CVE:
Status comment:


Attachments
screenshot of crash at boot (153.29 KB, image/jpeg)
2013-11-30 08:13 CET, Marja Van Waes
Details
report.bug.tar.gz of the upgrade (360.94 KB, application/gzip)
2013-11-30 08:17 CET, Marja Van Waes
Details
entire screen with call trace (134.76 KB, image/jpeg)
2013-11-30 17:17 CET, Marja Van Waes
Details
very first messages after GRUB2 screen (534.99 KB, image/png)
2013-11-30 17:39 CET, Marja Van Waes
Details
screen with complete trace (123.59 KB, image/jpeg)
2013-12-01 10:54 CET, Marja Van Waes
Details
grub2/grub.cfg of last upgraded cauldron (15.91 KB, text/plain)
2013-12-02 17:59 CET, Marja Van Waes
Details
pre-RC round 10 upgrade report.bug.xz (156.68 KB, application/x-xz)
2014-01-18 18:52 CET, Marja Van Waes
Details
grub.cfg for Mageia 5 Beta 2 (6.24 KB, text/plain)
2015-01-18 22:07 CET, Muhammad Tailounie
Details
After updating with the released Beta 2 ISOs (40.80 KB, application/x-xz)
2015-01-18 22:08 CET, Muhammad Tailounie
Details
Mga5beta3 upgrade install report.bug.xz (62.39 KB, application/x-xz)
2015-02-06 19:37 CET, Marja Van Waes
Details
add support for --reinstall-bootloader (1.50 KB, patch)
2015-04-07 12:44 CEST, Thierry Vignaud
Details | Diff
report.bug.xz (38.36 KB, application/x-xz)
2015-06-16 12:21 CEST, Marja Van Waes
Details

Description Marja Van Waes 2013-11-30 08:13:58 CET
Created attachment 4545 [details]
screenshot of crash at boot

After yesterday's upgrade from Mga3 with the Mageia 4 beta2 - DVD 32 bits of Nov 26, the system crashes right after the GRUB2 screen, see attached screenshot
Comment 1 Marja Van Waes 2013-11-30 08:17:24 CET
Created attachment 4546 [details]
report.bug.tar.gz of the upgrade
Comment 2 Marja Van Waes 2013-11-30 08:21:03 CET
the system can be rebooted with the sysreq keycombination.

booting with the last Mageia 3 kernel works fine

I didn't do updates at th

Whiteboard: (none) => 4beta2

Comment 3 Marja Van Waes 2013-11-30 08:21:27 CET
I didn't do updates at the end of the upgrade
Comment 4 Thierry Vignaud 2013-11-30 10:47:10 CET
The interesting message would be just ahead of the photo you attached.
I guess it fails either to mount / or to run /sbin/init, didn't it?

Please attach a photo of the whole screen.

CC: (none) => thierry.vignaud

Comment 5 Marja Van Waes 2013-11-30 17:17:48 CET
Created attachment 4549 [details]
entire screen with call trace

(In reply to Thierry Vignaud from comment #4)
> The interesting message would be just ahead of the photo you attached.
> I guess it fails either to mount / or to run /sbin/init, didn't it?
> 
> Please attach a photo of the whole screen.

Attaching. In case that part it hard to see: it starts at the top left with:

wn-block(0,0)

which is clearly the end of an invisible line.

This screen comes up so fast, that I don't have the slightest idea which messages come before it.
Comment 6 Marja Van Waes 2013-11-30 17:39:14 CET
Created attachment 4550 [details]
very first messages after GRUB2 screen

all that can be seen before boot up freezes, is 

"Early console in decompress_kernel

Decompressing Linux..."

and after that the same message, followed by:

                      "Parsing ELF... done
Booting the kernel."

(see attached screenshot)

I replayed a video of boot-up at 2% of its original speed, there are no other messages visible on the screen.
Comment 7 Thierry Vignaud 2013-11-30 22:51:00 CET
Please try again with "vga=6" (or "vga=ask" then select the highest text mode resolution)
Thus we would have 60 lines instead of 25

Keywords: (none) => NEEDINFO

Thierry Vignaud 2013-11-30 22:51:12 CET

Attachment 4550 is obsolete: 0 => 1

Thierry Vignaud 2013-11-30 22:51:17 CET

Attachment 4545 is obsolete: 0 => 1

Comment 8 Marja Van Waes 2013-12-01 10:54:53 CET
Created attachment 4552 [details]
screen with complete trace

(In reply to Thierry Vignaud from comment #7)
> Please try again with "vga=6" (or "vga=ask" then select the highest text
> mode resolution)
> Thus we would have 60 lines instead of 25


And s/linux/linux16/ ;-)

https://wiki.debian.org/GrubTransition#fnref-231bbb76472490d8f289f110d30d2d982e08a663

(I didn't change anything in /boot/grub2/custom.cfg or anywhere else, btw, so didn't do the s/initrd/initrd16/ )

The first line (of which only the end was visible before) becomes completely visible now:

..... Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Attachment 4549 is obsolete: 0 => 1

Comment 9 Marja Van Waes 2013-12-01 11:00:28 CET
btw, Thierry, I plan to do another upgrade install over this one with the new traditonal installer pre-beta2 i586 iso as soon as it is available.

Or wouldn't that help and should I start from Mga 3 again?

Keywords: NEEDINFO => (none)

Comment 10 Thierry Vignaud 2013-12-01 13:45:35 CET
Ah, it might be a grub2 issue then.
You can try upgrading to current cauldron with current installer
Comment 11 Marja Van Waes 2013-12-01 14:52:40 CET
(In reply to Thierry Vignaud from comment #10)
> Ah, it might be a grub2 issue then.
> You can try upgrading to current cauldron with current installer

Used boot-nonfree.iso to upgrade, so the last drakx-installer-stage2 was used

Problem is solved :-D

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 12 Marja Van Waes 2013-12-02 15:30:36 CET
I don't understand what is going on. I just used the new pre-beta2 to "upgrade" a different cauldron, only because I needed a screenshot.

The same problem occurs, when trying to boot into that "upgraded" cauldron, there is a kernel panic. 

This time, using boot.iso to upgrade again doesn't help :-(

The first line is again:
* Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

This is again with GRUB2 as bootloader

cc'ing barjac and reopening

btw, during both "upgrades" I saw a message about "too late to.... "

Status: RESOLVED => REOPENED
CC: (none) => zen25000
Resolution: FIXED => (none)

Comment 13 Marja Van Waes 2013-12-02 15:33:52 CET
and also this time, choosing an older kernel (so a former cauldron one in this case) makes it possible to boot the system
Comment 14 Thierry Vignaud 2013-12-02 17:15:42 CET
"too late to.... " is just a warning.
Please attach your /boot/grub2/grub.cfg

Keywords: (none) => NEEDINFO

Comment 15 Marja Van Waes 2013-12-02 17:59:38 CET
Created attachment 4566 [details]
grub2/grub.cfg of last upgraded cauldron

(In reply to Thierry Vignaud from comment #14)
> "too late to.... " is just a warning.
> Please attach your /boot/grub2/grub.cfg

Attaching, it comes from the sda10 cauldron that was "upgraded" today.

Mageia on sda1 is the one for which I opened this bug report, and which boots up fine since the boot-nonfree.iso "upgrade"
Thierry Vignaud 2013-12-03 12:56:57 CET

Source RPM: (none) => grub2

Comment 16 Barry Jackson 2013-12-11 11:34:56 CET
I think this *may* be due to missing drakboot.conf in the Mageia3 system that is being upgraded. 

Grub2 package now looks for this file on update to determine whether or not to re-install grub to MBR, which is needed when the package has been re-built from new sources.

It is possible that a user has installed grub2 manually outside of drakboot and the only way I could think to decide whether (and where) to re-install grub2 was to use the existence and content of /boot/grub2/drakboot.conf.

I am open to ideas here - basically grub2 needs to know where to re-install the bootloader during system upgrade.
Comment 17 Marja Van Waes 2013-12-11 13:58:19 CET
(In reply to Barry Jackson from comment #16)
> I think this *may* be due to missing drakboot.conf in the Mageia3 system
> that is being upgraded. 

Not that the last time this happened was with a cauldron that has never been a Mga3 that was being upgraded

> 
> Grub2 package now looks for this file on update to determine whether or not
> to re-install grub to MBR, which is needed when the package has been
> re-built from new sources.
> 
> It is possible that a user has installed grub2 manually outside of drakboot
> and the only way I could think to decide whether (and where) to re-install
> grub2 was to use the existence and content of /boot/grub2/drakboot.conf.

all my Grub2s come from GRUB2-as-bootloader selection during install

> 
> I am open to ideas here - basically grub2 needs to know where to re-install
> the bootloader during system upgrade.

I'm sure that when I upgraded Mga3, the bootloader was installed into the MBR, because the upgraded partition was now at the top of the list, and that was the only partition with Mageia 3 kernels (+ the new panicking Mga4 one)

I'm also sure that after last upgrade (a cauldron that has never been Mga3) the bootloader was re-installed in the MBR, because then that partition was at the top, and there I had only Mga4 kernels to boot into (with only the newest Mga4 kernel, the one from upgrade, panicking)

The only exception is when I upgraded the "upgraded-to-4prebeta2 Mga 3 install", after I had (while using a Mga3 kernel) gotten a 2nd Mga4 kernel with updates. After reboot after those updates, I couldn't boot into that Mga4 kernel, either, but after another upgrade-install I could.

I can't be sure that that time the bootloader was re-written to the MBR too, though, because no newer kernel was added during that upgrade, and that partition was already at the top of the bootloader list.

Is there nothing wrong with the attached configuration for the default partition with last kernel?
Comment 18 Marja Van Waes 2013-12-11 13:59:00 CET
s/Not that/Note that/
Comment 19 Marja Van Waes 2013-12-11 14:47:24 CET
Could it be that the problem is 

"root=/dev/sda10" instead of "root=UUID=1578414b-6d76-4042-8301-7074338c25da"

in

linux	/boot/vmlinuz-desktop root=/dev/sda10 ro   splash quiet
and in
linux	/boot/vmlinuz-3.12.2-desktop-1.mga4 root=/dev/sda10 ro   splash quiet

The older kernel that doesn't panick has:

linux	/boot/vmlinuz-3.12.0-desktop-2.mga4 root=UUID=1578414b-6d76-4042-8301-7074338c25da ro   splash quiet
Comment 20 Barry Jackson 2013-12-12 00:19:32 CET
Yes that's strange.
It would be interesting to see if a re-install of grub2 and a re-build of the menu changes that.
If you still have the system then you could...  ;)

First back up the MBR and PT of sda using dd:

dd if=/dev/hda of=/path/to/image count=1 bs=512

and also backup your current /boot/grub2 dir so the buggy situation can be returned to if needed.

Then from that system on sda10:
su
grub2-install /dev/sda

That will re-install all the grub2 files into /boot/grub2 from the installed grub2 version, and then re-build grub.cfg.

If this fixes it then the issue is probably that drakboot.conf was/is ?? missing when you updated and hence the grub2-install was skipped.
Comment 21 Marja Van Waes 2013-12-12 09:31:37 CET
(In reply to Barry Jackson from comment #20)
> Yes that's strange.
> It would be interesting to see if a re-install of grub2 and a re-build of
> the menu changes that.
> If you still have the system then you could...  ;)
> 
> First back up the MBR and PT of sda using dd:
> 
> dd if=/dev/hda of=/path/to/image count=1 bs=512
>

# dd if=/dev/hda of=/home/user/corruptMBRbackup count=1 bs=512
dd:failed to open '/dev/hda': No such file or directory

I'll try this part over the other cauldron, later.

And I'll check there whether the entry for the kernel that was added during upgrade, is of "root=UUID=*" type too, now, or that that only applies to the kernel that was added with normal updates.
Comment 22 Marja Van Waes 2013-12-12 09:47:21 CET
ah, it is of course "sda" instead of "hda"

Good morning :-)
Comment 23 Marja Van Waes 2013-12-12 09:57:17 CET
In the other cauldron, where booting works fine now, the entries in /boot/grub2/grub.cfg for the Mga3 kernels and for the last Mga4 kernel, that was retrieved from a normal update, are all of the "root=UUID=" type.


However, the kernel that was added while upgrading still has "root=/dev/sda1"
Comment 24 Marja Van Waes 2013-12-12 10:00:42 CET
(In reply to Marja van Waes from comment #23)
> In the other cauldron, where booting works fine now, the entries in
> /boot/grub2/grub.cfg for the Mga3 kernels and for the last Mga4 kernel, that
> was retrieved from a normal update, are all of the "root=UUID=" type.
> 
> 
> However, the kernel that was added while upgrading still has "root=/dev/sda1"

And choosing that kernel in the Grub menu, still leads to a kernel panic
Comment 25 Marja Van Waes 2013-12-12 10:01:07 CET
s/grub/grub2/
Comment 26 Marja Van Waes 2013-12-12 10:09:53 CET
(In reply to Barry Jackson from comment #20)

> 
> Then from that system on sda10:
> su
> grub2-install /dev/sda
> 
> That will re-install all the grub2 files into /boot/grub2 from the installed
> grub2 version, and then re-build grub.cfg.
> 
> If this fixes it then the issue is probably that drakboot.conf was/is ??
> missing when you updated and hence the grub2-install was skipped.

It does /not/ fix it
Comment 27 Barry Jackson 2013-12-12 16:09:06 CET
Well FWIW I can reproduce the kernel panic by using the menuentry format from your grub.cfg on my current cauldron system.
Why it fails eludes me as yet. I have asked a question upstream.
Comment 28 Marja Van Waes 2013-12-12 21:00:28 CET
Barry just asked me whether I had an initrd for the failing kernel, but I don't.

I'm not sure it is correct to set this bug to depend on 11966, please revert if it is wrong

Keywords: NEEDINFO => (none)
Depends on: (none) => 11966

Comment 29 Marja Van Waes 2013-12-12 21:06:07 CET
the other failing kernel in that cauldron doesn't have an initrd, either, nor does the failing kernel in my other cauldron have one
Barry Jackson 2013-12-12 21:10:28 CET

Source RPM: grub2 => (none)

claire robinson 2013-12-13 13:27:14 CET

Depends on: 11966 => 11979

claire robinson 2013-12-13 13:28:26 CET

Blocks: (none) => 11979
Depends on: 11979 => (none)

Comment 30 Marja Van Waes 2013-12-13 23:03:19 CET
btw, I can't find one instance of mkinitrd in report.bug
Comment 31 Barry Jackson 2013-12-14 00:21:55 CET
(In reply to Marja van Waes from comment #30)
> btw, I can't find one instance of mkinitrd in report.bug

Probably because it's dracut now?
Comment 32 Marja Van Waes 2013-12-14 09:12:03 CET
(In reply to Barry Jackson from comment #31)
> (In reply to Marja van Waes from comment #30)
> > btw, I can't find one instance of mkinitrd in report.bug
> 
> Probably because it's dracut now?

Well, I understood or misunderstood that dracut needs to do mkinitrd, because of what tv mentioned here:

https://bugs.mageia.org/show_bug.cgi?id=11966#c4

> That's a dracut issue. We can't do anything if mkinitrd fails.
Comment 33 Marja Van Waes 2013-12-14 09:21:40 CET
And on my "production" cauldron (a freshly installed 4 alpha), there are many lines in report.bug.xz that contain "mkinitrd"... dracut is chosen for mkinitrd

So the upgrade installs should show similare lines.
Comment 34 Thomas Backlund 2013-12-14 10:18:34 CET
(In reply to Marja van Waes from comment #32)
> (In reply to Barry Jackson from comment #31)
> > (In reply to Marja van Waes from comment #30)
> > > btw, I can't find one instance of mkinitrd in report.bug
> > 
> > Probably because it's dracut now?
> 
> Well, I understood or misunderstood that dracut needs to do mkinitrd,
> because of what tv mentioned here:
> 
> https://bugs.mageia.org/show_bug.cgi?id=11966#c4
> 
> > That's a dracut issue. We can't do anything if mkinitrd fails.

This is because "old habits" wont die,,, :)

and people are used to say "mkinitrd" as a short of "create an initial ramdisk"

and as for: "dracut is chosen for mkinitrd" it comes from the fact that we used to have both, and set dracut as default.

and we have mkinitrd linked to dracut so old commands & howtos still works too..
Anne Nicolas 2013-12-29 23:00:53 CET

Assignee: ennael1 => bugsquad

Comment 35 Marja Van Waes 2014-01-09 19:50:27 CET
I just upgraded another Mageia 3 (64 bits) with the beta 2 DVD and using additional media. It didn't have this problem (but, of course, this one was filed against i586, so not closing yet)
Comment 36 Marja Van Waes 2014-01-15 18:59:09 CET
I don't know why I don't see this bug on 64bits systems, but on a 32 bits I see it again:

I upgraded a previous Mageia pre-RC that had not had last updates and didn't have the most recent kernel, with last night's traditional 32bits DVD (round 8).

After install, rebooting gives a kernel panic again. initrd for the kernel that came with the upgrade is again missing

Summary: kernel panic when booting into 4beta-pre2 upgraded system => initrd missing for newest kernel after upgrading with 32-bits iso (was: kernel panic when booting into 4beta-pre2 upgraded system)
Whiteboard: 4beta2 => 4RC

Comment 37 Marja Van Waes 2014-01-17 20:04:42 CET
still valid with the 10th round 32bits traditional DVD of today

upgraded a fully updated Mageia 3

again kernel panic when booting Mageia, again the initrd for the mga4 kernel is missing

Am I the only one who tests 32bits upgrades (on real hw), or is the initrd only generated when there is *no* grub2 detected, or what?
Comment 38 Thierry Vignaud 2014-01-18 17:23:01 CET
Please attach the /root/drakx/report.bug.xz corresponding to that install

Keywords: (none) => NEEDINFO

Comment 39 Marja Van Waes 2014-01-18 18:52:13 CET
Created attachment 4815 [details]
pre-RC round 10 upgrade report.bug.xz

(In reply to Thierry Vignaud from comment #38)
> Please attach the /root/drakx/report.bug.xz corresponding to that install

btw, nowadays, whith upgrades to 4 beta2 and 4RC, there is a new report.bug, but the report.bug.xz is *not* the most recent one, so users might attach the wrong file when asked to do this.
Comment 40 Marja Van Waes 2014-01-20 01:44:23 CET
(In reply to Marja van Waes from comment #39)
> Created attachment 4815 [details]
> pre-RC round 10 upgrade report.bug.xz
> 
> (In reply to Thierry Vignaud from comment #38)
> > Please attach the /root/drakx/report.bug.xz corresponding to that install
> 
> btw, nowadays, whith upgrades to 4 beta2 and 4RC, there is a new report.bug,
> but the report.bug.xz is *not* the most recent one, so users might attach
> the wrong file when asked to do this.

but the attached one is the good one, because it results from compressing the new report.bug

Keywords: NEEDINFO => (none)

claire robinson 2014-01-22 17:37:26 CET

CC: (none) => eeeemail

Comment 41 Marja Van Waes 2014-01-23 22:22:18 CET
Did anyone else test a 32bits upgrade to 4 final?

Priority: Normal => release_blocker

Comment 42 Marja Van Waes 2014-01-23 22:28:30 CET
MrsB just reported she did a 32bits upgrade once , without hitting this issue, so setting priority back to normal

Priority: release_blocker => Normal

Comment 43 Marja Van Waes 2014-06-12 22:10:24 CEST
Now the same problem on a 64bits system, with the classical 64bits pre4.1DVD of June 10th

Again GRUB2 was used

report.bug of that date gives:
                                 
[root@localhost drakx]# grep mkinitrd report.bug
[root@localhost drakx]# grep dracut report.bug
<30>[    2.853597] dracut: dracut-034
<30>[   19.568099] dracut: Mounted root filesystem none
<30>[   19.767631] dracut: Switching root
* running: /usr/lib/dracut/modules.d/30convertfs/convertfs.sh /mnt
[root@localhost drakx]# 

So again nothing about dracut being chosen for mkinitrd :-/

initrd-3.12.21-desktop-2.mga4.img is indeed missing

Hardware: i586 => All
Whiteboard: 4RC => pre-4.1

Marja Van Waes 2014-06-12 22:11:15 CEST

Summary: initrd missing for newest kernel after upgrading with 32-bits iso (was: kernel panic when booting into 4beta-pre2 upgraded system) => initrd missing for newest kernel after upgrading with classical iso (was: kernel panic when booting into 4beta-pre2 upgraded system)

Comment 44 Marja Van Waes 2014-06-12 22:53:00 CEST
s/that date/last upgrade date/
Comment 45 Marja Van Waes 2015-01-18 11:34:00 CET
Forgot to mention that I have not (yet) seen this bug when replacing the Mageia version everywhere in /etc/urpmi/urpmi.cfg with the next version.

On QA ml, linuxero mentioned he had a kernel panic and a missing initrd when upgrading an older QA pre-5beta2 with the final one.

I haven't run any DVD upgrades since June, will try to free up some time to do so.

CC: sysadmin-bugs => linuxero
Component: Release (media or process) => Installer
Whiteboard: pre-4.1 => 5beta2

Comment 46 Marja Van Waes 2015-01-18 11:57:44 CET
Btw, linuxero hit it on a 64bit upgrade.

Rereading my comments in this bug, I see that, both for 32bit and for 64bit 3->4.* upgrades, sometimes the bug did not occur, while other times it did.

I don't have the slightest idea what the difference between those upgrades was. 

I suppose things like the amount of partitions or having a partition with a bootloader at the beginning of the partition, cannot stop dracut from being chosen to create an initrd?
Comment 47 Muhammad Tailounie 2015-01-18 16:58:27 CET
As I mentioned in an email on the QAML, I tried to update Mageia 5 Beta 2 64-bit date 9th. or 10th., January using Mageia 5 Beta 2 available to the public. The result was as follows;

On reboot a kernel panic hit me. I rebooted and checked GRUB2 entry and there was no initrd for Mageia..! I entered the GRUB shell and tried to use the initrd called; initrd-desktop.img but it didn't work..maybe points to the removed kernel!! so I tried to use initrd-3.18.1-desktop-3.mga5.img I found under /boot, but then a problem of partition UUID popped up.

I didn't try further testing as the problem for me sums up in:

1. initrd might be generated but not properly linked
2. GRUB configuration loses trace of initrd
3. Something is changing the UUID of the partitions.

Hope this helps..
Comment 48 Marja Van Waes 2015-01-18 17:10:14 CET
(In reply to Muhammad Tailounie from comment #47)
> As I mentioned in an email on the QAML, I tried to update Mageia 5 Beta 2
> 64-bit date 9th. or 10th., January using Mageia 5 Beta 2 available to the
> public. The result was as follows;
> 
> On reboot a kernel panic hit me. I rebooted and checked GRUB2 entry and
> there was no initrd for Mageia..! I entered the GRUB shell and tried to use
> the initrd called; initrd-desktop.img but it didn't work..maybe points to
> the removed kernel!! so I tried to use initrd-3.18.1-desktop-3.mga5.img I
> found under /boot, but then a problem of partition UUID popped up.
> 
> I didn't try further testing as the problem for me sums up in:
> 
> 1. initrd might be generated but not properly linked
> 2. GRUB configuration loses trace of initrd
> 3. Something is changing the UUID of the partitions.
> 

Maybe I was too fast to think it is the same bug, I don't remember having seen that a partition UUID changed to a different value, but do remember the UUID wasn't there for the newest kernel in /boot/grub2/grub.cfg.

However, here booting into an older kernel (from before the upgrade) worked fine.

If you still have the original /boot/grub2/grub.cfg from just after the upgrade, then please attach it

Can you also please attach the /root/drakx/report.bug* from the date + time of the upgrade 
If the file isn't already compressed, then please compress it with xz
Comment 49 Muhammad Tailounie 2015-01-18 22:07:59 CET
Created attachment 5825 [details]
grub.cfg for Mageia 5 Beta 2
Comment 50 Muhammad Tailounie 2015-01-18 22:08:41 CET
Created attachment 5826 [details]
After updating with the released Beta 2 ISOs
Marja Van Waes 2015-01-18 22:20:25 CET

Attachment 5825 mime type: application/octet-stream => text/plain

Comment 51 Marja Van Waes 2015-02-06 19:37:45 CET
Created attachment 5868 [details]
Mga5beta3 upgrade install report.bug.xz

Hit this bug again on a 64 bits system where I hit it before, with GRUB2 legacy.

initrd-3.19.0-desktop-0.rc7.3.mga5.img is missing, and in report.bug the string there is no line about dracut being chosen for mkinitrd

Attachment 4546 is obsolete: 0 => 1
Attachment 4552 is obsolete: 0 => 1
Attachment 4566 is obsolete: 0 => 1
Attachment 4815 is obsolete: 0 => 1

Marja Van Waes 2015-02-06 19:38:33 CET

Whiteboard: 5beta2 => 5beta3

Comment 52 Marja Van Waes 2015-02-06 19:49:05 CET
s/GRUB2 legacy/non-EFI GRUB2/
Comment 53 Marja Van Waes 2015-02-09 19:09:01 CET
still valid for 32bits boot-nonfree iso upgrade, too: trying to reboot with new kernel 3.19.0-1 ends in a kernel panic. Again there is nothing about mkinitrd in report.bug
as before, this is a GRUB2 system
Comment 54 Barry Jackson 2015-03-20 13:26:48 CET
(In reply to Marja van Waes from comment #53)
> still valid for 32bits boot-nonfree iso upgrade, too: trying to reboot with
> new kernel 3.19.0-1 ends in a kernel panic. Again there is nothing about
> mkinitrd in report.bug
> as before, this is a GRUB2 system

I'm wondering if https://bugs.mageia.org/show_bug.cgi?id=15532 may turn out to be a duplicate of this?
Marja Van Waes 2015-04-06 22:37:12 CEST

Blocks: (none) => 15637

Comment 55 Thierry Vignaud 2015-04-07 12:18:15 CEST
Comparing the attached report.bug with a successful one, there's no "adding 3...." lines

which suggests that add_kernel() is not called, see:
http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.pm?id=16.77#n1102

as called from install::steps::setupBootloaderBefore() -> any::setupBootloaderBefore() -> bootloader::suggests()

AFAIC, this could only happen b/c kernel list is empty after:

    my %old_kernels = map { vmlinuz2version($_->{kernel_or_dev}) => 1 } @{$bootloader->{entries}};
    @kernels = grep { !$old_kernels{$_->{version}} } @kernels;

Whiwh was introduced by http://gitweb.mageia.org/software/drakx/commit/?id=a579d4de
("do not add again kernels that are already in bootloader config file") which I guess has side effect with grub2

Could anyone create & export a minimal grub2 VM whose expose this issue?
Don't forget to take a snapshot in order to be able to rollback once you've confirmed the VM exhibit the behavior.

Keywords: (none) => NEEDINFO
Summary: initrd missing for newest kernel after upgrading with classical iso (was: kernel panic when booting into 4beta-pre2 upgraded system) => initrd missing for newest kernel after upgrading with classical iso when using grub2

Comment 56 Thierry Vignaud 2015-04-07 12:20:10 CEST
Actually I think this is because grub2 has still %post script that try to be too inteliggent and generate a config before we can do, and thus we read back from the config those kernels were already added...

http://svnweb.mageia.org/packages/cauldron/grub2/current/SPECS/grub2.spec?revision=819208&view=markup#l254

We already asked for those to be ripped...
Thierry Vignaud 2015-04-07 12:22:24 CEST

Assignee: bugsquad => zen25000
Source RPM: (none) => grub2

Comment 57 Thierry Vignaud 2015-04-07 12:34:47 CEST
1) At minimal, all grub2-mkconfig calls should be killed.
The goal w

2) Though as already told, this is wrong if installing both eg grub & grub2:
# Generate core.img, and install it to filesystem for multiboot
    %{name}-install --directory=%{_libdir}/grub/%{pc_arch} --grub-setup=/bin/true $BOOT_PARTITION

This should NOT be systemitcally done.
It should at minimal only be done if grub2 is the actual bootloader.

3) And it should CHECK with "detectloader" if grub2 is the current bootloader instead of assuming it'is just because this file or that file exist...

4) this %post script is bug prone.
eg it doesn't check if $BOOT_PARTITION is actually set and just run commands with it as arguements

I should make drakboot generates a /boot/grub2/install.sh like we create /boot/grub/install.sh for grub in order to prevent other errors and replace the whole "On update re-install grub2 to where it was installed by drakboot otherwise next boot may fail due to mismatched boot code" ...
Comment 58 Thierry Vignaud 2015-04-07 12:39:14 CEST
Or I could add another action to bootloader-config
Though bootloader-config --rebuild-initrds would do something similar to what we want
Comment 59 Thierry Vignaud 2015-04-07 12:44:51 CEST
Created attachment 6208 [details]
add support for --reinstall-bootloader

untested but should do it.
to be called as "bootloader-config --action reinstall-bootloader"
Comment 60 Thierry Vignaud 2015-04-07 12:47:55 CEST
and then grub2 should have sg similar to grub's  update_copy_in_boot() to call from when_config_changed_grub2() that would update core.img

See http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.pm?id=16.77#n1712
Comment 61 Barry Jackson 2015-04-07 21:17:46 CEST
So are you now suggesting that the whole of both grub2 %post(s) (grub2 and grub2-efi) can now be removed, along with the kernel update part of the grub2 filetrigger, and that the above patch will now handle all this correctly?

I am happy to do some VM testing in both pc-bios and efi systems once I fully understand exactly what to do in preparation.
Comment 62 Thierry Vignaud 2015-04-13 16:20:28 CEST
Should be fixed now that grub2's %post is saner

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Comment 63 Marja Van Waes 2015-04-18 20:35:56 CEST
with grub2-2.02-0.git9752.18.mga5 on the iso, it happened again

I'll try to reproduce before re-opening this bug report
Comment 64 Marja Van Waes 2015-04-19 01:16:57 CEST
That was with the dual iso, I could not reproduce it with the 32bit iso.

I may have forgotten to update (the maybe old) Mageia 4 before upgrading with the dual
Comment 65 Marja Van Waes 2015-06-16 11:58:22 CEST
initrd-3.19.8-desktop-3.mga5.img is missing after upgrading with last night's (round 9) 32bits Classical iso

I hadn't tried an upgrade install again since comment 64 :-( 

*not* adding it to the errata, the few who use non-default grub2 on non-efi systems will probably know to boot with an older kernel.

Keywords: NEEDINFO => (none)
Status: RESOLVED => REOPENED
Resolution: FIXED => (none)
Whiteboard: 5beta3 => MGA5TOO

Marja Van Waes 2015-06-16 12:04:18 CEST

Blocks: 11979 => (none)

Comment 66 Thierry Vignaud 2015-06-16 12:07:18 CEST
Please attach your /root/drakx/report.bug.xz

Keywords: (none) => NEEDINFO

Comment 67 Samuel Verschelde 2015-06-16 12:08:38 CEST
(In reply to Marja van Waes from comment #65)
> *not* adding it to the errata, the few who use non-default grub2 on non-efi
> systems will probably know to boot with an older kernel.

Your call. It could save trouble to some people and avoid a bad surprise. A non bootable system, even if in rare situations, is worth an errata entry to me.
Comment 68 Marja Van Waes 2015-06-16 12:21:54 CEST
Created attachment 6744 [details]
report.bug.xz


(In reply to Thierry Vignaud from comment #66)
> Please attach your /root/drakx/report.bug.xz

attaching

(In reply to Samuel VERSCHELDE from comment #67)
> (In reply to Marja van Waes from comment #65)
> > *not* adding it to the errata, the few who use non-default grub2 on non-efi
> > systems will probably know to boot with an older kernel.
> 
> Your call. It could save trouble to some people and avoid a bad surprise. A
> non bootable system, even if in rare situations, is worth an errata entry to
> me.

Well, it was in the errata before, but the last times I've seen the errata I found them so confusing, that I'd rather not add anything unless 
1. it is likely to hit many users 
2. it is likely to cause panic for at least part of the users

grub2 isn't installed by default on legacy systems, so neither 1. nor 2. will be likely

Apart from that, this bug appears in the list of bugs to which a link exists in the Errata

Attachment 5868 is obsolete: 0 => 1

Comment 69 Thierry Vignaud 2015-06-16 13:21:58 CEST
This is a different issue, please open a new bug report

Keywords: NEEDINFO => (none)
Status: REOPENED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.