Description of problem: Mageia 7 Beta1 Live Plasma doesn't boot. Dracut warning: /sysrroot has no propper rootfs layout, ignoring and removing offending mount hook. Dracut warning: Can't mount filesystem Laptop Dell Latitude D630 I tried with two USB keys, same result. These keys works on another computer and one of these keys works well on the laptop DELL with Mageia 6.1 Live.
Created attachment 10523 [details] /run/initramfs/rdsosreport from the laptop
Looks like a corrupted image on the usb: 131.404404] dracut: mgalive overlay is [ 131.475554] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 131.480001] print_req_error: I/O error, dev loop0, sector 0 [ 131.480014] SQUASHFS error: squashfs_read_data failed to read block 0x0 [ 131.480017] squashfs: SQUASHFS error: unable to read squashfs_super_block [ 131.482742] print_req_error: I/O error, dev loop0, sector 0 [ 131.482756] SQUASHFS error: squashfs_read_data failed to read block 0x0 [ 131.482758] squashfs: SQUASHFS error: unable to read squashfs_super_block [ 131.538350] dracut Warning: /sysroot has no proper rootfs layout, ignoring and removing offending mount hook [ 131.650431] dracut Warning: Can't mount root filesystem + '[' -f /run/initramfs/init.log ']'
CC: (none) => tmb
Nope, our problem is [ 131.404124] dracut: mgalive basedev is /dev/sdb2 [ 131.404223] dracut: mgalive livedev is /dev/sdb2 because /dev/disk/by-label: ... lrwxrwxrwx 1 root 0 10 Dec 3 13:18 Mageia-7-b1-Live-Plasma-x86_64 -> ../../sdb2 but + blkid ... /dev/sdb1: UUID="2018-12-02-22-42-48-00" LABEL="Mageia-7-b1-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos" /dev/sdb2: SEC_TYPE="msdos" UUID="D263-2127" TYPE="vfat" looks fine...
CC: (none) => mageia
We've never seen this before, so I'm assuming it's another problem with the latest kernel.
dracut nfs stuff bites us, so it's reverted in drakx-installer-images-2.55-5.mga7
FYI, same problem with the last round (June 05)
CC: (none) => mageiatools, marja11Keywords: (none) => 7beta1Source RPM: (none) => drakx-installer-imagesAssignee: bugsquad => isobuild
Could this be relevant? From the PAD: ISO Name: Mageia-7-beta1-Live-PLASMA5-x86_64.iso DATE.txt: Tue Dec 4 22:30:46 CET 2018 "dvg: usb not booting: Laptop just goes straight to grub2 menu from the HD. DVDRW boots w/o problem". Summarisingcurrent experience from the PAD. ISO Name: Mageia-7-beta1-Live-GNOME-x86_64.iso DATE.txt: Tue Dec 4 22:07:56 CET 2018 Boot to LIVE: ls: Real EFI h/w with AMD/ATI/Radeon HD7310 graphics, screen 1920x1080. - Booting Live [free drivers] stuck forever on the rising bubbles screen. - Booting Live with non-free drivers went further, but stuck eventually on a black screen with cursor top-left in what looks like the 640x480 position. TJ: Refuses to boot on nvidia340 hardware using nonfree drivers. Boots OK with free Boot to INSTALL: TJ: Refuses to boot on nvidia340 hardware using nonfree drivers. Boots OK with free ls: Real EFI h/w with AMD/ATI/Radeon HD7310 graphics, screen 1920x1080. Like TJ: - Booting to install [free drivers] went to start of installation. - Booting to install with non-free drivers stuck on rising bubbles screen. Similar (not identical) for the other Live ISOs.
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #7) > Could this be relevant? From the PAD: These are all very different bugs, and should go in separate bug reports. Note that there is no longer a non-free driver for AMD/ATI graphics. Selecting the non-free boot option adds "nokmsboot" to the boot options, and that stops some of the free drivers from working.
(In reply to Martin Whitaker from comment #3) > Nope, our problem is > > [ 131.404124] dracut: mgalive basedev is /dev/sdb2 > [ 131.404223] dracut: mgalive livedev is /dev/sdb2 > > because > > /dev/disk/by-label: > ... > lrwxrwxrwx 1 root 0 10 Dec 3 13:18 Mageia-7-b1-Live-Plasma-x86_64 -> > ../../sdb2 > > but > > + blkid > ... > /dev/sdb1: UUID="2018-12-02-22-42-48-00" > LABEL="Mageia-7-b1-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos" > /dev/sdb2: SEC_TYPE="msdos" UUID="D263-2127" TYPE="vfat" > > looks fine... That indeed is the problem. Same thing happens with GNOME-LIVE iso While investigating I witnessed 2 successful boots. I'd say 4 out of 5 times the device was wrong. looks like a kernel/udev timing problem? Interestingly, the by-uuid links are correct. /dev/disk/by-uuid: lrwxrwxrwx 1 root 0 10 Dec 3 13:18 2018-12-02-22-42-48-00 -> ../../sdb1 lrwxrwxrwx 1 root 0 10 Dec 3 13:18 D263-2127 -> ../../sdb2 So a possible workaround could be to change the kernel cmd line to: root=mgalive:UUID=2018-12-02-22-42-48-00
CC: (none) => smout.jan
I have now reproduced this problem on one of my machines. I don't know why udev is behaving differently now, but I've found a workaround that fixes the problem for me. So please test again when the beta2 ISOs come out.
CC: (none) => nikos769
Created attachment 10655 [details] Mageia-7-beta2-x86_64 Not better with beta2 but different. Installation seems fine but Plasma is blinking and unusable. After reboot and connexion, the screen is black with no icon. /run/initramfs/rdsosreport doesn't exist any more
The Plasma problem is bug 24060. Several alternative workarounds are described there. The original bug described here would only occur when using the Live ISOs.
Created attachment 10775 [details] journalctl -ab
With Mga7beta2 round 3, the behaviour changed again. Installation and update are fine but boot is very long, about 3,5 minutes (40 sec for Mga7 Cl). See journalctl -ab above
(In reply to André DESMOTTES from comment #14) > With Mga7beta2 round 3, the behaviour changed again. Installation and update > are fine but boot is very long, about 3,5 minutes (40 sec for Mga7 Cl). > See journalctl -ab above So we trip over this: kernel: [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work. kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:34:pipe A] flip_done timed out does booting with "video.allow_duplicates=1" help ?
"video.allow_duplicates=1" didn't help but "video=SVIDEO-1:d" did it, boot in 35 secondes.
CC: lewyssmith => (none)
Isn't this latest problem bug 23875? You've marked that bug as resolved. Is there any difference in the kernel version or kernel boot command line between the installation that was fixed and this one? Might be better to close this bug and reopen that one, to keep this issue in one place.
Yes, it is the same bug than 23875, we can close this one as resolved.
Status: NEW => RESOLVEDResolution: (none) => FIXED