Description of problem: Laptop IBM Thinkpad R50e with Intel Pentium M processor and Intel graphics 82852/855GM graphics. This graphics uses the Intel 810 driver in Mageia 6. Installing M7 (beta2 round 3) works without problems with MATE selected as DE, but booting the installed system just hangs. Workaround is sto boot into recovery mode and use Xdrakeres to force the vesa driver and force boot to runlevel3. Command startx then works OK to IceWM, but startmate still fails to "unknown screen". How reproducible: Each and eveery time.
(In reply to Herman Viaene from comment #0) > Description of problem: > Laptop IBM Thinkpad R50e with Intel Pentium M processor and Intel graphics > 82852/855GM graphics. This graphics uses the Intel 810 driver in Mageia 6. > > Installing M7 (beta2 round 3) works without problems with MATE selected as > DE, but booting the installed system just hangs. > Workaround is sto boot into recovery mode and use Xdrakeres to force the > vesa driver and force boot to runlevel3. Command startx then works OK to > IceWM, but startmate still fails to "unknown screen". > Thanks for the report, Herman. Can you switch to tty2, when that happens, to fetch /var/log/Xorg.0.log and /etc/X11/xorg.conf and log.txt that is the result of running, as root, journalctl -ab > log.txt Please attach those three files to this report. Btw, did 7beta2 round 1 and round 2 not have this issue?
Keywords: (none) => 7beta2, NEEDINFOCC: (none) => isobuild, kernel, marja11
I cannot switch to tty2, the system does not react. And I think I mentioned problems with previous betas on the riseup pad. If I switch back to the Intel driver, let the boot fail, revert to vesa (which is another boot) and then boot again with vesa, would journalctl -a -b 2 > log.txt not yield the logging of the failed boot, if anything is logged at all??
(In reply to Herman Viaene from comment #2) > I cannot switch to tty2, the system does not react. > And I think I mentioned problems with previous betas on the riseup pad. > If I switch back to the Intel driver, let the boot fail, revert to vesa > (which is another boot) and then boot again with vesa, would > journalctl -a -b 2 > log.txt not yield the logging of the failed boot, if > anything is logged at all?? "journalctl -a -b 2" shows the logs from the 2nd time you booted your system if you installed from a Classical ISO, and from the 1st time after install if you installed from a Live ISO. "journalctl -a -b -1" will show the logs from your previous boot and "journalctl -a -b -2" from the boot before the previous one, indeed provided anything got logged at all. Another option is to use journalctl -a --since="YYYY-MM-DD hh:mm" --until="YYYY-MM-DD hh:mm" and set the dates and times as desired.
Before I wanted to try these suggestions, I let the updates install the latest M7 kernel. Result: the system only boots in recovery mode, vesa or intel driver all alike. The normal boot hangs after 4 seconds. I'll try if I can get anything out of the journal in recovery mode.
Booted into normal boot and it failed, booted in recovery mode and ran journalctl -a -b 1 > logfailedboot.txt and journalctl -a -b > recoveryboot.txt I will attach both files here
Created attachment 10791 [details] hanging boot
Created attachment 10792 [details] recovery boot
May not be relevant but looks strange to me ... kernel: sd 2:0:0:0: [sdb] 122096646 4096-byte logical blocks: (500 GB/466 GiB) fedora-dmraid-activation[713]: ERROR: unsupported sector size 4096 on /dev/sdb. service_harddrake[781]: test_for_bad_drives(/dev/sdb on sector #62) If you boot from a live iso can you fsck the partitions on that drive ok?
CC: (none) => davidwhodginsAssignee: bugsquad => kernel
That sdb is an USB-connected 500Gb HD. I leave it on all the time, because the HD of the laptop being tiny. But anyway, running M6 on the laptop and after unmounting the device, I get: # e2fsck /dev/sdb e2fsck 1.43.4 (31-Jan-2017) /dev/sdb: clean, 11373/30531584 files, 11563811/122096646 blocks
(In reply to Herman Viaene from comment #9) > That sdb is an USB-connected 500Gb HD. I leave it on all the time, because > the HD of the laptop being tiny. > But anyway, running M6 on the laptop and after unmounting the device, I get: > # e2fsck /dev/sdb > e2fsck 1.43.4 (31-Jan-2017) > /dev/sdb: clean, 11373/30531584 files, 11563811/122096646 blocks So sdb has a partition on it, but no partition table. While technically ok, there are a lot of tools that will become very confused by the lack of a dos or gpt style partition table. Please try booting m7 without it, ensuring the fstab entry for sdb has the attribute nofail. Don't forget to update the initrd to ensure it isn't terminating the boot process if sdb is not mounted. From a live iso boot ... # mkdir /sdb # mount /dev/sdb /sdb # systemd-nspawn -D /sdb # dracut -f /boot/initrd-4.14.104-server-1.mga6.img 4.14.104-server-1.mga6 (replacing the kernel flavor/version as appropriate). Hold down ctrl and press ] three times to exit the nspawn (which is similar to old chroot environments). And then try booting into the installed system.
First: there is absolutely no entry for this sdb in fstab. So the simplest test was: unplug the USB cable for it and boot again: That does not change a thing: the recovery boot works OK, but the normal boot hangs after 4 seconds. BTW: this USB connected HD has been on this system on all previous tests, and never caused any problem at all. The issue has been with the Intel video drivers ans up to the latest updated kernel in M7 all worked well with IceWM, but starting to MATE failed. Since the last kernel update neither IceWM nor MATE can be started. Well the boot preocess does come nowhere in the neighbourhood of have a go at X11.
Have you tried booting with the nomodeset option? That worked around the problem in beta1 (bug 23876 comment 52).
CC: (none) => mageia
Closing te bug as the laptop in question has gone south, and I haven't been able to replicate this problem on any other machine I have available (other Intel graphics)
Resolution: (none) => FIXEDStatus: NEW => RESOLVED