Description of problem: After the resolution of bug 19592, I noticed the proceeds to a screen where just three character boxes on a dark screen would be lit in progress to signal the progress of the boot process. This appears to happen in stead of the graphical Mageia cauldron with bubbles appearing to mark the boot progress (still to be confirmed). After all available updates were applied, such characters appear as white blocks with question marks inside. It looks like the replacement character: https://en.wikipedia.org/wiki/Specials_%28Unicode_block%29#Replacement_character ... but inside a rectangle. Version-Release number of selected component (if applicable): How reproducible: This was tried in another PC without success. Possibly because the graphical boot screen was activated (Plymouth?) -- and possibly not in the PC where the current bug has been observed. I will try to investigate further. Steps to Reproduce: 1.Install Mga6sta1. 2.Install package "grub2-mageia-theme-dejavu". 3. Install updates. 4. Set up boot to grub2 with text mode. PS: Formerly, in order to save time, I was testing things on the original DVD image (Mga sta1). The rationale was that I was not testing the distro but one particularl release to see whether it was ready to release. After pondering over the issue, I reversed my thinking and decided to apply all updates, so as to try to make Mageia 6 work more closer to what a new sta2 release.
Confirmed that on the affected machine the Splash screen with the Mageia logo where bubbles are added won't appear being replaced by the dark screen with three question marks used as progress indicator. Priority and severity adjusted to reflect the minor importance of this bug (aesthetic only).
Severity: normal => minorPriority: Normal => Low
I think barjac mentioned at some time what causes those question marks, CC'ing him.
CC: (none) => marja11, zen25000
Nope wasn't me. I see them on a real h/w i586 (old pIII intel machine) that was booting fine until the more recent kernels appeared. It was OK with 4.6.2 IIRC, after which boot fails without noacpi but I now see the 3 X "?" in place of plymouth.
This mostly affects the perception of the Mageia brand, otherwise it's a microscopic bug. I only reported because the ? undefined chars give the impression of something internally wrong -- but I don't think that is the case -- and most old guys (the ones who have old computers!) will see it means nothing.
Assigning to all packagers collectively, since there is no registered maintainer for plymouth.
CC: (none) => anssi.hannula, fundawang, luigiwalser, mageiaSource RPM: (none) => plymouthSummary: Weird characters during boot. => 3 diamond shapes with question mark instead of plymouthAssignee: bugsquad => pkg-bugs
Summary: 3 diamond shapes with question mark instead of plymouth => 3 rectangle shapes with question mark instead of plymouth
Marja, the link I provided was just to show the content of the shape, which is a rectangle/square instead of a diamond.
(In reply to Renato Dali from comment #6) > Marja, the link I provided was just to show the content of the shape, which > is a rectangle/square instead of a diamond. It is a square or rectangle, standing on one of its corners, too, when all angles are 90 degrees. However, read the link you gave: "often a black diamond with a white question mark" Compare with the comment at the bottom of https://en.wikipedia.org/wiki/Suit_%28cards%29#/media/File:French_suits.svg " The four French playing cards suits used primarily in the English-speaking world: spades (â ), hearts (â¥), diamonds (â¦) and clubs (â£) But I can understand your confusion, the expensive diamonds in rings and such have a very different shape ;-)
Summary: 3 rectangle shapes with question mark instead of plymouth => 3 rectangle shapes with question mark � � � instead of plymouth
Nice link, I wish more themes were available when I play Yukon/Kpatience... Well, it seems I'm unable to convey what I saw, but here's a link which comes closer: https://www.utf8icons.com/character/65533/replacement-character Please take a look at the square titled GNU Unifont... that's what I saw (though the depicted one has a lot more jaggies). BUT! A few instants ago I applied today's update (new kernel etc.) and Plymouth works again. The three chars are no longer to be seen. So I changed the current bug to RESOLVED, WORKSFORME (in part, because I won't be able to reproduce the bug again).
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME
@ Renato I agree those are squares, not diamonds. @ Barjac Assuming it got fixed for you, too, so closing. Please reopen if needed.
Summary: 3 rectangle shapes with question mark � � � instead of plymouth => 3 rectangle shapes with question mark instead of plymouthResolution: WORKSFORME => FIXED
s/squares/rectangles/
Sorry, Marja and Barry. I did a big confusion, because I'm testing two machines at once. I misremembered the error as occuring in my older (circa 2004) PC, The other, probably from 2009/2010 is the one which uses the sisimedia driver (SiS 671/771 integrated video card) -- this is the one showing the three question chars. And they're still there... so we're back to where we were and I'll reopen the bug. This is not very significant from a technical point-of-view, but could be from a Marketing angle, because people tend to associate such question marks with something gone wrong. Sorry for any inconvenience caused and thank you for your attention and support -- I now and then open lesser bugs with the sole intent that Mageia looks good in the release version.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
CC: (none) => mageia
@marja This was not fixed for me either and seems to be similar to 19539 18155 An upgrade of my Acer laptop (with NVIDIA graphics) from Mageia 5 to Cauldron today has produced the same problem. I ended up searching here hoping to find a solution. :\ Maybe these bugs should be consolidated and given higher priority as this, while cosmetic, gives a terrible impression of the distro.
IMHO, Barry is right about the bad impression -- I just hope it happens only in a few old computers. Giuseppe did a much better description of the bug, I'm sorry I wasn't able to find his bug, entered 20 days before the present one. Since there is a conversation here I'm not quite sure about what to do. Regarding the present situation, without knowing anything, I hypothesize the following: 1. The interrogation chars IMHO are actually some special ASCII char which is not defined in the font Mageia uses. I booted another (can't remember now which) showing three centered white squares (I believe Ubuntu did that in previous incarnations) -- so the solution for this might be find which chars are being used (probably by perusing Plymouth's source and looking for the hide-splash code (as Giuseppe has shown). 2. Regarding Plymouth not working, I venture (again just a conjecture) it didn't like the hardware and somehow concluded it was best not to mess with things it cannot understand... falling back to text mode boxes display. In my case the hardware is weird and uses a not very compatible driver (sisimedia) -- that's what led me to such a(n) hypothesis.
Well, this has been happening on my machine ever since STA1 was released last summer. My machine is a few years old, but not a dinosaur: MSI Z97 Gaming3 motherboard Pentium G3258 dual-core processor 16GB DDR3 1600MHz EVGS Geforce GTX 780 2x WDC 1TB 3.5" drives (blue & black), + 1TB Seagate 3.5" I have only seen the proper boot splash, randomly, about 5 times in total since last July.
CC: (none) => jdchoate
(In reply to Renato Dali from comment #13) > IMHO, Barry is right about the bad impression -- I just hope it happens only > in a few old computers. Martin Whitaker has done things to workaround and/or fix this, he probably knows best who are affected, CC'ing him. > > Giuseppe did a much better description of the bug, I'm sorry I wasn't able > to find his bug, entered 20 days before the present one. Since there is a > conversation here I'm not quite sure about what to do. > That's bug #19539, and it's assigned to the Mageia tools maintainers. It's got normal priority and severity. I agree that severity and priority should be increased for this report, doing so now.
Severity: minor => normalPriority: Low => NormalCC: (none) => mageia
I got the same issue in VirtualBox after an upgrade from Mageia 5 to Mageia 6 RC using urpmi.
Priority: Normal => High
(In reply to Rémi Verschelde from comment #16) > I got the same issue in VirtualBox after an upgrade from Mageia 5 to Mageia > 6 RC using urpmi. Does it persist after a reboot? Please add 'plymouth.debug=stream:/dev/kmsg' to the boot command line in grub2, and attach the resulting /var/log/plymouth_debug.log
Created attachment 9268 [details] plymouth-debug.log of 5->6 upgraded VM in vbox (In reply to Martin Whitaker from comment #17) > Does it persist after a reboot? Yes. > Please add 'plymouth.debug=stream:/dev/kmsg' to the boot command line in > grub2, and attach the resulting /var/log/plymouth_debug.log Here it is. In case it matters, the bootloader is grub (legacy), as it's what was configured by default for Mageia 5 and this VM is an upgrade.
(In reply to Rémi Verschelde from comment #18) > Created attachment 9268 [details] > plymouth-debug.log of 5->6 upgraded VM in vbox OK, you've hit the inherent race in the new plymouth device timeout scheme - see my initial comment in bug 19890. It should be fixable in a couple of ways: 1) Add the vboxvideo driver to the initrd. In /etc/dracut.conf.d/50-mageia.conf, change add_drivers+=" ahci " to add_drivers+=" ahci vboxvideo " then run 'dracut -f' 2) Increase or decrease the plymouth DeviceTimeout value in /usr/share/plymouth/plymouth.defaults and run 'dracut -f' The first is the better fix, but I don't know if we can automate it. The second is what I've done on the Live DVDs. I'm starting to think the best solution would be to revert the changes in plymouth. They are applied in a patch (sourced from upstream), so shouldn't be hard to remove.
Seeing the same thing after a 5->6 upgrade on real hardware, Intel Core2Duo, Intel 810 or later graphics, BCM4318 wifi.
CC: (none) => andrewsfarm
When booting the most recent live RC ISOs in VirtualBox, I'm seeing three "?" instead of the plymouth image.
(In reply to PC LX from comment #21) > When booting the most recent live RC ISOs in VirtualBox, I'm seeing three > "?" instead of the plymouth image. Please add 'plymouth.debug=stream:/dev/kmsg' to the boot command line, and attach the resulting /var/log/plymouth_debug.log, also the output from 'journalctl -ab'. What host system are you using for VirtualBox?
Created attachment 9390 [details] journalctl -ab output when booting Mageia-6-rc-LiveDVD-Xfce-x86_64-DVD.iso in virtualbox.
Created attachment 9391 [details] copy of /var/log/plymouth-debug.log when booting Mageia-6-rc-LiveDVD-Xfce-x86_64-DVD.iso in virtualbox.
Host system information: $ uname -a Linux marte 4.4.70-desktop-1.mga5 #1 SMP Fri May 26 13:42:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/release Mageia release 5 (Official) for x86_64 $ rpm -qa | grep -E 'kernel|virtualbox' | sort dkms-virtualbox-5.1.22-1.mga5 kernel-desktop-4.4.70-1.mga5-1-1.mga5 kernel-desktop-devel-4.4.70-1.mga5-1-1.mga5 kernel-desktop-devel-latest-4.4.70-1.mga5 kernel-desktop-latest-4.4.70-1.mga5 kernel-firmware-20160409-1.mga5 kernel-firmware-nonfree-20160914-1.mga5.nonfree kernel-userspace-headers-4.4.70-1.mga5 nvidia340-kernel-desktop-latest-340.96-6.mga5.nonfree virtualbox-5.1.22-1.mga5 virtualbox-doc-5.1.22-1.mga5
OK, you've hit the same problem as Rémi (see comment 19). But this shouldn't be happening with the Live DVD because the device timeout is set to 10 seconds. The plymouth debug log confirms that, but from the journal it is actually timing out after 5 seconds. I should be able to fix this on the Live DVDs by adding the vboxvideo driver to the initrd.
commit 2e82dec27838acd14667bd46005e6f2e10bf6d7b Author: Martin Whitaker <mageia@...> Date: Sun Jun 4 20:16:12 2017 +0100 live-dracut.conf: add vboxvideo to drivers in initrd Once more to stop plymouth falling back to text mode (mga#19642). --- Commit Link: http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=2e82dec27838acd14667bd46005e6f2e10bf6d7b
I thought that we were supposed to be using modesetting instead of vboxvideo in Cauldron now...
(In reply to David Walser from comment #28) > I thought that we were supposed to be using modesetting instead of vboxvideo > in Cauldron now... We use the 'modesetting' X11 driver, but that sits on top of the 'vboxvideo' drm device driver. plymouth uses the drm devices.
Thanks for the clarification.
Can it still happen and does it deserve an entry in the Errata?
It's cosmetic (no actual "bug" that users should be aware of), so I don't think it needs to go in the errata.
(In reply to Rémi Verschelde from comment #32) > It's cosmetic (no actual "bug" that users should be aware of), so I don't > think it needs to go in the errata. Unless we want to document a workaround for users that might be bothered by the cosmetic issue. But it might very well be fixed by comment 27, so let's see what testers say.
I just saw someone say on IRC on the weekend that they saw the issue, so it might not be fixed, but they might have been using RC ISOs, so them again, maybe it is.
I saw it after a 5>6 upgrade install using the RC, but a clean install on the same hardware didn't do it. That makes me think it can still happen, but it's much rarer now.
If you are using the nvidia340 driver (and quite likely, any other driver that doesn't support kernel mode setting), one of the things that may cause this bug is not having a video mode (e.g. vga=791) specified on the kernel command line. Bug 21248 means this will happen if you install from a Live DVD. Note that setting the video mode for grub2 is currently broken in drakboot (bug 21246), but you can work round that by manually adding a vga=... option in the "Append" text box.
(In reply to Martin Whitaker from comment #36) > If you are using the nvidia340 driver (and quite likely, any other driver > that doesn't support kernel mode setting), one of the things that may cause > this bug is not having a video mode (e.g. vga=791) specified on the kernel > command line. Does it have to be vga=xxx ? I've upgraded from 5 > 6 using grub2 and I have the video mode in /etc/default/grub as grub2 doesn't use vga= anymore from what I understood, also video mode was fine for mga5. Since the upgrade to mga6 grub2 only shows a text menu instead of the graphical one and also any screen shown by plymouth has those rectangles with the question marks inside ... Will see about the plymouth debugging from comment 22 and also the video mode selection.
CC: (none) => doktor5000
(In reply to Florian Hubold from comment #37) > (In reply to Martin Whitaker from comment #36) > > If you are using the nvidia340 driver (and quite likely, any other driver > > that doesn't support kernel mode setting), one of the things that may cause > > this bug is not having a video mode (e.g. vga=791) specified on the kernel > > command line. > > Does it have to be vga=xxx ? I've upgraded from 5 > 6 using grub2 and I have > the video mode in /etc/default/grub as grub2 doesn't use vga= anymore from > what I understood, also video mode was fine for mga5. Do you mean you have a video= option instead of a vga= option? I've not tried that. My comment was based on the behaviour of my machine that uses the nvidia340 driver. Without the vga= option, the driver doesn't create a legacy framebuffer device (and of course doesn't create a dri device either), so plymouth has nothing to display a graphical splash screen on. Adding the vga= option fixed this. I've not seen this problem with any other drivers, but all the ones I use create dri devices and support kernel mode setting, and ignore the vga= option anyway.
(In reply to Martin Whitaker from comment #38) > Do you mean you have a video= option instead of a vga= option? I've not > tried that. No, I don't have that at all. I've only got the following for grub2, as vga= seems to be deprecated with grub2 from what I read, e.g. https://www.gnu.org/software/grub/manual/grub.html#gfxpayload GRUB_CMDLINE_LINUX_DEFAULT="splash quiet nomodeset" GRUB_GFXMODE=1280x1024x32 GRUB_GFXPAYLOAD_LINUX=keep
(In reply to Florian Hubold from comment #39) > No, I don't have that at all. I've only got the following for grub2, as vga= > seems to be deprecated with grub2 from what I read, e.g. > https://www.gnu.org/software/grub/manual/grub.html#gfxpayload > > GRUB_CMDLINE_LINUX_DEFAULT="splash quiet nomodeset" > GRUB_GFXMODE=1280x1024x32 > GRUB_GFXPAYLOAD_LINUX=keep This will set the initial video resolution, but when the video driver gets loaded, it gets to choose a new resolution. At least on my hardware, all the free drivers choose the native LCD panel resolution. The nvidia340 driver appears to depend on the vga= option, and if that isn't present, selects text mode. I don't have the necessary hardware to test if the other NVIDIA proprietary drivers do the same.
@ Daniel Setting the "FOR_ERRATA6" keyword, because you told on discuss ml that you had looked there before mailing discuss@ml.m.o about this issue. Feel free to add the issue to the errata, if you edit rights in the wiki, we're much behind on adding issues that should have been added. If you have edit rights there, but would like to add it, then please say so and we'll give you the needed rights. Cheers, Marja
CC: (none) => mandrivaKeywords: (none) => FOR_ERRATA6
Thank you Marja. I did have edit rights and have added this bug to the errata. Feel free to update/edit and move as needed.
Thx, Daniel, updating the keyword :-)
Keywords: FOR_ERRATA6 => IN_ERRATA6
I have five computers with Mageia 6, three of them have this challenge. The graphic cards on the computers with this gray screen with the three question marks during booting are: NVIDIA GeForce GT 730 (2 computers) and NVIDIA GeForce FX 5200. # uname -a Linux HP-Compaq 4.14.18-desktop-1.mga6 #1 SMP Wed Feb 7 23:14:33 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
CC: (none) => ole.reier.ulland
(In reply to Ole Reier Ulland from comment #44) > I have five computers with Mageia 6, three of them have this challenge. The > graphic cards on the computers with this gray screen with the three question > marks during booting are: NVIDIA GeForce GT 730 (2 computers) and NVIDIA > GeForce FX 5200. Are you using the proprietary nvidia driver? If so, what is the output from cat /proc/cmdline
The two NVIDIA GeForce GT 730 using computers use graphics driver, "NVIDIA GeForce 420 series or later". The NVIDIA GeForce FX 5200 using computer use graphics driver, "NVIDIA GeForce FX series". I would be thankful if you could tell me how I always can tell whether a driver is proprietary or not. I do not know whether they are proprietary. The first 730 computer, 64-bits # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.14.18-desktop-1.mga6 root=/dev/mapper/HP--C--LVM-root ro nokmsboot splash quiet noiswmd resume=/dev/HP-C-LVM/swap audit=0 The second 730 computer, 64-bits # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.14.18-desktop-1.mga6 root=UUID=11246d91-d857-41fc-b59d-79edc257cdcd ro nokmsboot splash quiet noiswmd resume=UUID=d2e27d2e-7187-4a3b-abfc-6f27e555add2 audit=0 The 5200 computer, 32-bits # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.14.13-desktop-1.mga6 root=UUID=a2d6a56d-a6da-4ddc-bc73-bafcc2a79074 ro splash quiet noiswmd resume=UUID=cb3c3b0f-6b45-4e83-85ff-77082515e8a3 audit=0 vga=791
/etc/X11/xorg.conf has a Driver line. modesetting or nouveau is free, nvidia is proprietary. The nvidia-smi command will also tell you that proprietary is in use.
The two 730 computers have, Driver "nvidia" The 5200 computer has, Driver "nouveau"
For the two 730 computers, please try the fix described in comment 36. For the 5200 computer, please edit the boot command line when booting and add 'plymouth.debug=stream:/dev/kmsg'. After booting, attach the resulting /var/log/plymouth_debug.log file to this bug report. Also attach the system.log file created by running 'journalctl -ab > system.log' (when run as the root user).
For the one, not my main computer, the fix described in comment 36 seems to work. But for my main computer, with NVIDIA GeForce GT 730, the addition of "vga=791" did not only cause the gray screen with question marks to be changed into plymouth, but it also caused the computer to stop booting. The last line I can see is mounting network drive. Removing "vga=791" in grub2 did not make any difference. Adding "3" (run level 3) at the end of the command line in grub2 causes functioning command line terminal. I can ping 8.8.8.8. The command "startx" gave "xauth: file /home/[user]/.serverauth.2909 does not exist". Is there an other command than "startx" that will start the graphical environment? I will come back to the 5200 computer log files, but now I have a much more serious problem because my main computer with e-mails and everything is not bootable. I really need ideas about how to get my main computer bootable again. Anyone, please.
Created attachment 10021 [details] log file form my main computer that now will not boot. The attached file is the result of "journalctl -b" on my main computer with NVIDIA GeForce GT 730 that now after adding "vga=791" to the grub2 command line will not boot anymore, even if I remove the "vga_791". The computer had been running for a number of days since last reboot, but I can not remember to have made any other configuration changes since last reboot than this.
Hi, Ole! I would try what przemo suggests here: https://www.linuxquestions.org/questions/slackware-14/xauth-file-home-user-serverauth-1436-does-not-exist-4175576123/ (but being overcautious, I wouldn't delete the files, but instead move them into a sub-folder) Also, please not this is just a wild guess, but I suppose it won't make your situation worse. Good luck!
Ole Reier: After reading the log file, I notice it is «sddm» that is broken, somehow. I would open a new bug on this, against the sddm Source Rpm and attach the log file there, since this is another issue than this bug repport.
CC: (none) => cooker
(In reply to Ole Reier Ulland from comment #50) > The command "startx" gave "xauth: file > /home/[user]/.serverauth.2909 does not exist". Is there an other command > than "startx" that will start the graphical environment? IIRC, startx was deprecated a while ago. I believe the preferred way to start the graphical environment is systemctl start prefdm.service I think Johnny is right, and this is another issue. A possible workaround is to install and switch to another DM (e.g. LightDM).
(In reply to Martin Whitaker from comment #54) > IIRC, startx was deprecated a while ago. I believe the preferred way to > start the graphical environment is > > systemctl start prefdm.service A regular user can do this? (I.e. NOT using sudo or as root) It was me who suggested «startx». The point was to start the desktop (plasma, icewm, etc) without also starting the graphical login screen, to see if that worked. If sddm won't start, then lets bypass it.
You have to be root to run "systemctl start prefdm.service", I did, under run level 3, and it resulted only in blinking cursor upper left corner. There is no /home/[user]/.serverauth... file. I moved the /home/[user]/.Xauthority file and restarted, but nothing changed. So I moved it back. I started under run level 3, installed "lxdm" and ran "systemctl start lxdm.service", but that only resulted in a blinking cursor upper left corner.
It was suggested that I try different display managers. I installed gdm, lightdm and lxdm. Started them with "systemctl start gdm.service" etc. And they did not work either. Then Solbu suggested XFdrake, he suspected there was something that mattered with the graphics driver. I just went trough it without making any changes and then after reboot the display manager and plasma worked. I now consider the sddm problem solved.
Created attachment 10027 [details] 5200 computer "journalctl -ab > system.log This is a response to comment 49.
Created attachment 10028 [details] 5200 computer, "add 'plymouth.debug=stream:/dev/kmsg'. After booting, attach the resulting /var/log/plymouth_debug.log." This is a response to comment 49 too.
CC: (none) => egc
Created attachment 10214 [details] Plymouth log I add nouveau to dracut (and install the nonfree firmware) and put the vga=791 in the kernel options but plymouth still show only the marks. My card is Card:NVIDIA GeForce FX series: NVIDIA Corporation|NV34 [GeForce FX 5200] [DISPLAY_VGA] (rev: a1) This is my plymouth log
Created attachment 10215 [details] System log And this is my sytem log cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz root=UUID=0a4f3636-66dd-4ce1-82af-0e46c48eee84 ro plymouth.debug=stream:/dev/kmsg noiswmd vga=791 splash quiet
I have to set DeviceTimeout value to 15 in /usr/share/plymouth/plymouth.defaults and run dracut -f In my previous attempt i set the value to 10 but for this is not enough :( Also i have to remove noiswmd because some times produce never ending error messages
CC: (none) => heninj
System upgraded from full upadated mga 6 to 7RC by internet and find again with this issue
Keywords: (none) => 7RC
Created attachment 11059 [details] plymouth log for mga 7/cauldron I also add the line add_drivers+=" nouveau " To /etc/dracut.conf.d/50-mageia.conf And modify DeviceTimeout in /usr/share/plymouth/plymouthd.defaults Like is suggested in preious comments but still not plymouth screen :(
Created attachment 11060 [details] System log for mga 7/Cauldron
I remove vga=791 from boot options and i could see the plymouth screen :) Hope some one find this useful
Keywords: (none) => FOR_ERRATA7
But do note that for other hardware/drivers, removing the vga= option stops the plymouth screen being shown.
CC: heninj => (none)
Keywords: FOR_ERRATA7 => IN_ERRATA7CC: (none) => yves.brungard_mageia
I don't see this on my VM any more, and I think this is OLD.
Resolution: (none) => OLDStatus: REOPENED => RESOLVED
In the previous try I have set https://moviedle.io/ the value to 10 but for this it is not enough.
CC: (none) => lanikane68
I have the same bug as yours before. https://driftboss2.co/ https://1001tips.co/
CC: (none) => tonyadam0175
CC: (none) => fri