Bug 23876 - Mageia 7Beta i586 does not boot on Thinkpad R50e (real 32bit hardware)
Summary: Mageia 7Beta i586 does not boot on Thinkpad R50e (real 32bit hardware)
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Release (media or process) (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: release_blocker critical
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-21 16:44 CET by Herman Viaene
Modified: 2018-12-09 10:28 CET (History)
6 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
report from installation (163.45 KB, application/x-xz)
2018-11-23 09:24 CET, Herman Viaene
Details
last messages on failed reboot of Beta2i586 (923.58 KB, image/jpeg)
2018-11-26 10:48 CET, Herman Viaene
Details
Screenshot - boot after clean Netinstall - Kernel 4.19.5-2 (205.87 KB, image/jpeg)
2018-11-28 23:41 CET, psyca
Details
journal of failed boot M7 i586 round 4 (111.06 KB, text/plain)
2018-12-07 17:16 CET, Herman Viaene
Details
Xorg log after startx (78.62 KB, text/plain)
2018-12-08 13:04 CET, Herman Viaene
Details
Xorg log after startmate (80.05 KB, text/plain)
2018-12-08 13:08 CET, Herman Viaene
Details

Description Herman Viaene 2018-11-21 16:44:45 CET
Description of problem:
Mageia 7Beta does not boot

Version-Release number of selected component (if applicable):


How reproducible:
Every time


Steps to Reproduce:
Installation of Mageia 7 Beta on IBM Thinkpad R50e 5 Intel pentium M processor) seems to work OK, grub is updated OK.
Booting, choosing the new install in grub menu results in a black screen, no disk activity. Left it there for 20 min.
Checked via M6 on same machine, no log in M7's partition is /root/drakx. All files untouched and pointing to the installation.
Comment 1 Marja Van Waes 2018-11-22 09:42:20 CET
This might be a duplicate of bug 23431 (Similar issue with some 64bit-capable HP machines).

I fail to see the workaround Martin refers to in that report, or is that using a 64bit iso? Herman can't do that, because the ThinkPad R50e is incapable of running 64bit.

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=23431
Component: RPM Packages => Release (media or process)
Assignee: bugsquad => isobuild
Summary: Mageia 7Beta does not boot => Mageia 7Beta i586 does not boot on Thinkpad R50e (real 32bit hardware)
CC: (none) => marja11, sysadmin-bugs

Marja Van Waes 2018-11-22 09:42:31 CET

CC: sysadmin-bugs => (none)

Comment 2 Martin Whitaker 2018-11-22 19:47:14 CET
I think it's different to bug 23431 - there Dick could not boot from the USB stick, here Herman has booted and run the installer, and it only fails when booting the newly installed system.

The odd thing is the lack of install logs in /root/drakx. Herman, could you rerun the install, and when it reaches the final screen, use Ctrl-Alt-F2 to switch to the command prompt, insert a FAT-formatted USB stick, and type

  bug

on the command line. That should copy report.bux.xz onto the USB stick.

CC: (none) => mageia

Comment 3 Herman Viaene 2018-11-22 21:09:49 CET
@Martin
I was not clear enough: I have the logs of the installation in /root/drakx, but there's no info whatsoever on the failed boots after installation.
Now do you want the reprt from the installation??
Comment 4 Martin Whitaker 2018-11-22 21:16:56 CET
Yes, let's have report.bug.xz, in case it tells us anything. Also the output from

  ls -l /path-to-mga7/boot

to make sure the kernel and initrd are there and look sensible.
Comment 5 Herman Viaene 2018-11-23 09:24:15 CET
Created attachment 10496 [details]
report from installation
Comment 6 Herman Viaene 2018-11-23 09:29:51 CET
ls -l boot
totaal 19312
-rw-r--r-- 1 root root   219874 nov 16 12:54 config-4.19.2-desktop-3.mga7
drwxr-xr-x 2 root root     4096 nov 11 00:07 dracut/
drwxr-xr-x 6 root root     4096 nov 20 09:36 grub2/
-rw------- 1 root root 11127274 nov 20 09:25 initrd-4.19.2-desktop-3.mga7.img
lrwxrwxrwx 1 root root       32 nov 20 09:25 initrd.img -> initrd-4.19.2-desktop-3.mga7.img
-rw-r--r-- 1 root root   181496 nov 16 12:54 symvers-4.19.2-desktop-3.mga7.xz
-rw-r--r-- 1 root root  2966891 nov 16 12:54 System.map-4.19.2-desktop-3.mga7
lrwxrwxrwx 1 root root       29 nov 20 09:25 vmlinuz -> vmlinuz-4.19.2-desktop-3.mga7
-rw-r--r-- 1 root root  5261312 nov 16 12:54 vmlinuz-4.19.2-desktop-3.mga7

Yesterday I ran the boot without spash quiet during the QA meeting, and posted the last message there. tmb told me this is a kernel crash and advized to leave it alone til the next kernel comes around.
Comment 7 Martin Whitaker 2018-11-23 09:43:39 CET
I see the installer has chosen to install the desktop kernel, whereas the ISO will be using the desktop586 kernel, which might be the important difference.

CC: (none) => tmb

Comment 8 Herman Viaene 2018-11-26 10:43:48 CET
Beta2 has same problem. Took a picture of last screen of messages.
Although a discussion on the qa list seemed to blame nvidia for this problem and recommended to use the vesa driver, I gave this lat suggestion a try.
But this laptop has an Intel (810 and later) graphics chipset.
Reinstalled, choose the vesa driver, rebooted and the reboot is successfull.
The only defaults that I changed during installation are the language and the video driver.
Comment 9 Herman Viaene 2018-11-26 10:48:53 CET
Created attachment 10502 [details]
last messages on failed reboot of Beta2i586
Comment 10 psyca 2018-11-26 16:44:23 CET
Hm. Had a similar error (clean cauldron netinstall) - but with a little different text.
https://bugs.mageia.org/show_bug.cgi?id=23900

CC: (none) => linux

Comment 11 Thomas Andrews 2018-11-26 18:27:38 CET
Seeing what I believe is the same thing on a Dell Inspiron 5100 (P4 Northwood core, 2GB RAM, radeon MV200 graphics) after an install of Xfce from the second-round i586 Classical iso.

The visual symptoms are different, but as with Herman, there is no evidence of any logs on that first boot. Nothing in /var/log/journal, no dmseg file, and all the logs that ARE there contain 0 bytes. The install.log file indicates that kernel-desktop was installed.

The round-2 i586 Xfce Live iso on a usb stick boots to a working desktop, and installing from that desktop is successful. That iso installs kernel-desktop586.

I am currently re-installing from the Live iso. Once that is finished, I will attempt to install kernel-desktop-latest, and reboot to see what happens.

CC: (none) => andrewsfarm

Comment 12 Martin Whitaker 2018-11-26 21:01:48 CET
Herman's CPU at least is a 686, so should work with the standard desktop kernel. Maybe there is some Spectre/Meltdown mitigation included in that version of the kernel that doesn't work on all 686 processors. Anyway, reassigning as this appears to be a kernel problem.

Assignee: isobuild => kernel

Comment 13 Thomas Andrews 2018-11-26 21:57:41 CET
Maybe not.

Just finished doing the re-install from the Live iso mentioned in Comment 11, set MCC up to use the math.princeton mirror, and after getting the 100 or so pending updates, I installed kernel-desktop-latest. I then used "update-grub," just to be sure grub2 was correct, and shut down. I booted again, making sure I was booting into kernel-desktop.

The boot was successful, perfectly normal, in fact. Everything acts normally. Firefox browses, vlc plays videos, etc. 

So it would appear that, at least for the P4, the problem is not so much in the kernel as it is in the installation of it by the Classical iso.

(FWIW, I noticed that one of the updates I got before installing kernel-desktop-latest was dnf. No idea if that makes any difference.)
Comment 14 Thomas Andrews 2018-11-27 13:47:48 CET
Changing this to a release blocker.

Priority: Normal => release_blocker

Comment 15 Martin Whitaker 2018-11-27 20:40:06 CET
The Live ISO is created by the classical installer, so the installations should largely be the same. What would be different is the composition of the initrd. The initrd should be regenerated when you run the live installer, but with the current release it's not. However, TJ's test of installing the desktop kernel should have generated a new initrd for that kernel, so I doubt this is the problem.

Note to tmb: we still have early microcode loading disabled in the Live initrd. I guess we should revert that now VirtualBox is fixed.
Comment 16 Thomas Backlund 2018-11-27 21:21:42 CET
(In reply to Martin Whitaker from comment #15)


> Note to tmb: we still have early microcode loading disabled in the Live
> initrd. I guess we should revert that now VirtualBox is fixed.

Yep. done in git
Comment 17 psyca 2018-11-28 23:41:35 CET
Created attachment 10517 [details]
Screenshot - boot after clean Netinstall - Kernel 4.19.5-2

Screenshot after successful clean net-install (today) and reboot with Kernel 4.19.5-desktop-2

Laptop system:
LG F-222EG with Intel Core Duo T2250 and Intel 945GM.
Comment 18 Martin Whitaker 2018-12-01 15:55:19 CET
I have reproduced this using qemu:

  qemu-img create qemu.img 8G
  qemu-system-i386 -cdrom Mageia-7-beta1-i586.iso -m 3G --enable-kvm -vga std -cpu qemu32 -drive file=qemu.img -boot order=d

I've tested with RAM size of 3GB, which causes the desktop kernel to be selected, and with a RAM size of 4GB, which causes the server kernel to be selected. Both show the bug. I've also reduced the CPU capabilities (by -cpu qemu32,-cmov), which causes the desktop586 kernel to be selected. That boots to the desktop without any problem.

I've also discovered that, on the buggy systems, if I remove both "nokmsboot" and "splash quiet" and add "3" on the boot command line, I can boot to a text login prompt (using ctrl-alt-F2 to get to a working tty). Then, if I delete /etc/X11/xorg.conf, reboot, and just remove "nokmsboot" from the boot command line, the system will then reliably boot to a working desktop.

There seems to be a weird bit of memory in this. After a failed boot, trying to boot to run level 3 as above will fail on the first attempt, but succeed on subsequent attempts. Suspecting service_harddrake, I disabled the mandriva-everytime service, but that made no difference.
Comment 19 Martin Whitaker 2018-12-01 18:35:24 CET
Using qemu, replacing "nokmsboot" with "nomodeset" works around this bug.
Comment 20 Herman Viaene 2018-12-06 18:03:53 CET
Still the same in round 4 as my original report. Diiference is that when I change the configuration from Intel graphics to xorg/vesa and runlevel 3, the boot process goes further till "Started Command Scheduler" and at that point completly dies.
Comment 21 Thomas Andrews 2018-12-06 18:29:08 CET
Problem is gone on my Inspiron 5100, as of the latest Classical i586 iso, dated (I think) 1 Dec.

I was able to install and boot into a working Xfce system that uses the free radeon driver. Later, I was able to install and boot into a working Plasma system, using the VESA driver as past experience tells me Plasma will not work on this hardware with the radeon driver.
Comment 22 Marja Van Waes 2018-12-06 22:55:04 CET
(In reply to Herman Viaene from comment #20)
> Still the same in round 4 as my original report. Difference is that when I
> change the configuration from Intel graphics to xorg/vesa and runlevel 3,
> the boot process goes further till "Started Command Scheduler" and at that
> point completly dies.

Did you see the same kernel trace and all the coloured artefacts that psyca and you saw before? If you didn't see them, then please  mount the root partition of the round 4 install that fails to boot.

There's a directory with a very long hexadecimal name in
 /that/partition's/var/log/journal/

please run, as root,

  journalctl -D /path/into/that/hexadecimal/directory/ > journal.txt

and then attach journal.txt to this bug report.
(Compress the journal with "xz journal.txt" if it's too large to attach.)

Please do also attach your new /root/drakx/report.bug.xz from the root partition of that install, to replace your old report.bug.xz

CC: (none) => isobuild
Severity: normal => critical

Comment 23 Marja Van Waes 2018-12-06 22:56:39 CET
(In reply to Marja Van Waes from comment #22)

> 
> Did you see the same kernel trace and all the coloured artefacts that psyca
> and you saw before? If you didn't see them, then please  mount the root
> partition of the round 4 install that fails to boot.
> 

ah, run level 3, so probably no coloured artefacts... it would be nice to have the journal logs :-)
Comment 24 Herman Viaene 2018-12-07 09:56:25 CET
Hm,
# journalctl -D /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313 > journal.txt
Journal file /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313/system.journal uses an unsupported feature, ignoring file.
Comment 25 Marja Van Waes 2018-12-07 14:28:37 CET
(In reply to Herman Viaene from comment #24)
> Hm,
> # journalctl -D /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313 >
> journal.txt
> Journal file
> /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313/system.journal uses
> an unsupported feature, ignoring file.

On the system from where you issued that command, what is the output of (as normal user):

   systemctl --version


What was that system, btw, a Mageia 6 install or a Mageia 7beta1 Live iso?
Comment 26 Herman Viaene 2018-12-07 14:45:50 CET
The system from where I issued that command is a Mageia 6 installation, and the requested output:
$ systemctl --version
systemd 230
+PAM +AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
Comment 27 Marja Van Waes 2018-12-07 15:06:34 CET
(In reply to Herman Viaene from comment #26)
> The system from where I issued that command is a Mageia 6 installation, and
> the requested output:
> $ systemctl --version
> systemd 230
> +PAM +AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN

The problem is probably "-LZ4". In my Mageia 7 here that is +LZ4, which means that in your Mageia7beta1 install most likely lz4 compression is used (instead of xz), but, going by the above output, your Mageia 6 install cannot uncompress that.

Do you have a working Mageia 7 install, or Mageia 7 Live iso, with which to try again?

(You could also copy /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313/ and its contents to a USB stick and then plug it into a Mga 7 machine)
Comment 28 Herman Viaene 2018-12-07 17:16:18 CET
Created attachment 10532 [details]
journal of failed boot M7 i586 round 4
Comment 29 Martin Whitaker 2018-12-08 01:37:02 CET
From the journal, it looks like the system has booted successfully. Does Ctrl-Alt-F2 get you to a text login prompt?
Comment 30 Herman Viaene 2018-12-08 10:38:18 CET
Ctrl-Alt-F2 gets me to a login prompt. I can login. 
There "startmate" throws an error "Unable to init server: connection refused.
"startx" gives me an ICEWM session which works partly: I cann't start any application from the Mageia button - menus. I can start Firefox from the context menu, but not MCC. I have to start that one from terminal CLI.
Ctrl-Alt-F1 reamins all the time at "Started Command Scheduler" and I find no way to get it moving.
Comment 31 Martin Whitaker 2018-12-08 11:51:18 CET
It may not seem like it, but we are making progress - the kernel bug has gone.

From a root login, what do

  systemctl get-default

and

  systemctl status display-manager

report?

What driver is currently selected in the "Device" section of /etc/X11/xorg.conf?

Can you attach a copy of /var/log/Xorg.0.log after running startmate and also after running startx.

Does the 32-bit Live ISO still work on this machine? If so, which X driver is it using?

Sorry for all the questions, but I don't know a better way to debug X problems :-(
Comment 32 Herman Viaene 2018-12-08 13:03:28 CET
# systemctl get-default
multi-user.target

# systemctl status display-manager
● lightdm.service - Light Display Manager
   Loaded: loaded (/usr/lib/systemd/system/lightdm.service; enabled; vendor pre>
   Active: inactive (dead)
     Docs: man:lightdm(1)

Section "Device"
    Identifier "device1"
    Driver "vesa"
    Option "DPMS"
EndSection
Comment 33 Herman Viaene 2018-12-08 13:04:46 CET
Created attachment 10534 [details]
Xorg log after startx
Comment 34 Herman Viaene 2018-12-08 13:08:33 CET
Created attachment 10535 [details]
Xorg log after startmate
Comment 35 Herman Viaene 2018-12-08 13:12:13 CET
As far as the Live iso is concerned, I have no idea as I never try to run Live on this laptop, will be painfully slow.
If you really want it, it'll have to wait till monday to have time to download the Live etc....
Comment 36 Martin Whitaker 2018-12-08 14:15:49 CET
Sorry, I was misremembering. It was TJ who reported the Live ISO worked but the classical install did not.

OK, so you are booting to the multi-user target (equivalent to run level 3). The lack of a login prompt on vt1 is bug 22620.

There aren't any errors reported in your Xorg log files. Have you already tried booting to the graphical target after selecting the vesa driver?

You could try replacing "nokmsboot" with "nomodeset" to see if that makes a difference. Alternatively, try setting the X driver to "modesetting" (and removing "nokmsboot" / "nomodeset" - they will stop the "modesetting" driver from working).

The "intel" driver should work of course, but that's beyond me to fix.
Comment 37 Herman Viaene 2018-12-09 09:38:45 CET
Booting to the graphical target after selecting the vesa driver: OK , gives working MATE desktop.
Other questions to investigate after reboot.
Comment 38 Herman Viaene 2018-12-09 09:45:07 CET
Remark: since my comment 20, a number of updates have been issued and installed on this laptop. Are we sure none of those impacted/improved on the issue at hand??
Comment 39 Marja Van Waes 2018-12-09 09:58:40 CET
(In reply to Herman Viaene from comment #38)

Thanks for all your tests, Herman!

> Remark: since my comment 20, a number of updates have been issued and
> installed on this laptop. Are we sure none of those impacted/improved on the
> issue at hand??

No we're not, and more importantly: the _original_ issue of this bug report got fixed!

It would be better to open (a) new report(s) and close this bug report as fixed, while giving (a) link(s) to the new bug report(s). 
For the intel Gfx driver a separate report will be needed, if it still doesn't work on this hardware.
Comment 40 Martin Whitaker 2018-12-09 10:28:46 CET
Those updates (or more likely updates to those updates...) will of course be on the next set of ISOs we build.

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