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
Created attachment 4546 [details] report.bug.tar.gz of the upgrade
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
I didn't do updates at the end of the upgrade
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
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.
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.
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
Attachment 4550 is obsolete: 0 => 1
Attachment 4545 is obsolete: 0 => 1
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
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)
Ah, it might be a grub2 issue then. You can try upgrading to current cauldron with current installer
(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 => RESOLVEDResolution: (none) => FIXED
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 => REOPENEDCC: (none) => zen25000Resolution: FIXED => (none)
and also this time, choosing an older kernel (so a former cauldron one in this case) makes it possible to boot the system
"too late to.... " is just a warning. Please attach your /boot/grub2/grub.cfg
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"
Source RPM: (none) => grub2
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.
(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?
s/Not that/Note that/
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
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.
(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.
ah, it is of course "sda" instead of "hda" Good morning :-)
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"
(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
s/grub/grub2/
(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
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.
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
the other failing kernel in that cauldron doesn't have an initrd, either, nor does the failing kernel in my other cauldron have one
Source RPM: grub2 => (none)
Depends on: 11966 => 11979
Blocks: (none) => 11979Depends on: 11979 => (none)
btw, I can't find one instance of mkinitrd in report.bug
(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?
(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.
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.
(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..
Assignee: ennael1 => bugsquad
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)
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
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?
Please attach the /root/drakx/report.bug.xz corresponding to that install
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.
(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
CC: (none) => eeeemail
Did anyone else test a 32bits upgrade to 4 final?
Priority: Normal => release_blocker
MrsB just reported she did a 32bits upgrade once , without hitting this issue, so setting priority back to normal
Priority: release_blocker => Normal
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 => AllWhiteboard: 4RC => pre-4.1
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)
s/that date/last upgrade date/
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 => linuxeroComponent: Release (media or process) => InstallerWhiteboard: pre-4.1 => 5beta2
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?
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..
(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
Created attachment 5825 [details] grub.cfg for Mageia 5 Beta 2
Created attachment 5826 [details] After updating with the released Beta 2 ISOs
Attachment 5825 mime type: application/octet-stream => text/plain
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
Whiteboard: 5beta2 => 5beta3
s/GRUB2 legacy/non-EFI GRUB2/
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
(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?
Blocks: (none) => 15637
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) => NEEDINFOSummary: 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
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...
Assignee: bugsquad => zen25000Source RPM: (none) => grub2
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" ...
Or I could add another action to bootloader-config Though bootloader-config --rebuild-initrds would do something similar to what we want
Created attachment 6208 [details] add support for --reinstall-bootloader untested but should do it. to be called as "bootloader-config --action reinstall-bootloader"
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
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.
Should be fixed now that grub2's %post is saner
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
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
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
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 => REOPENEDResolution: FIXED => (none)Whiteboard: 5beta3 => MGA5TOO
Blocks: 11979 => (none)
Please attach your /root/drakx/report.bug.xz
(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.
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
This is a different issue, please open a new bug report
Keywords: NEEDINFO => (none)Status: REOPENED => RESOLVEDResolution: (none) => FIXED