Plymouth corruption
I've just finished installing 5.0 64-bit using the text mode installer and where the Plymouth glowing Trisquel logo is supposed to glow I get a corruption of the screen.
I've had 4.5 working on this laptop (Thinkpad T61 with the Nvidia NVS 140) before and did not have that problem. The live disc shows the logo glowing correctly before I get to the desktop.
So I'm only having this problem after installing. I've done nothing to the install (no custom packages or anything).
The Nouveau driver is installed.
Does anyone have an idea of what could be wrong? Should I run any commands and paste the output here for reference?
I cannot take a photo right now, but the corrupted Plymouth screen can be described as being black with a few pink artifacts in the top half and the green stripes (i.e. the actual Plymouth background) has been squashed into the bottom half.
I haven't noticed any other video glitches. When switching Visual Effects to Extra the windows wobble and do all they should without corruption or tearing.
Shutting down, however, it displays the glowing logo correctly.
Apologies for my multiple postings, but I've found this:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/713088
The photo in there is exactly what I get except with the Trisquel green instead of the purple.
I'll probably only get back to this issue nearer to the weekend. So in the meanwhile, if anyone is experiencing this, or has a solution, or has found something useful on the internet, please post here.
> Apologies for my multiple postings, but I've found this:
> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/713088
> The photo in there is exactly what I get except with the Trisquel
> green instead of the purple.
> I'll probably only get back to this issue nearer to the weekend.
> So in the meanwhile, if anyone is experiencing this, or has a
> solution, or has found something useful on the internet, please
> post here.
Any news? I had a problem like this and I'd like knowing if I have some chance to try installing it again, since the version of Trisquel I'm using is outdated and I have no access to repositories for installing new software.
No solution to offer, but I have this problem with a freshly installed 32-bit Trisquel 5.0 on an old Dell Vostro 400 desktop (64-bit machine).
I could not get it to work. I played around with /etc/default/grub and the /etc/grub,d/ files but I had no luck (those are the files where other people suggest changes should be made). It would either show the same mess or nothing at all. I do not have sufficient knowledge of the boot/startup process to diagnose this further.
I also tried doing the uvesafb fix (http://idyllictux.wordpress.com/2010/04/26/lucidubuntu-10-04-high-resolution-plymouth-virtual-terminal-for-atinvidia-cards-with-proprietaryrestricted-driver/) but that did not work either.
From what I've gathered the problem is that it takes too long for the Plymouth driver(?) to load before the desktop is ready. It seems to be because it starts too late (http://askubuntu.com/questions/79953/why-does-plymouth-start-so-late). But the live CD works correctly, so either the the installed settings differ from that of the live CD or the CD is just so much slower than the hard drive to allow it to load sooner. As a note, I upgraded the hard drive to a 7200 drive (was 5400 before) but I cannot imagine that that would play a role. I installed Fedora 16 on the exact same hardware and Plymouth worked correctly.
I've also got a Dell GX280 with onboard Intel graphics and Plymouth works correctly. It's running Trisquel 5 32-bit. Incidentally this machine has a 5400 hard drive.
My only suggestion right now is that if the corrupted graphics are too annoying you can edit /etc/default/grub and look for the line that says:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
and remove the "splash". If you do that, remember to run
# update-grub
when you're done. That should stop Plymouth from displaying, though I still got a very brief flash of some corrupted graphics but it was not the same as the corrupted Plymouth graphics,
Unfortunately, I won't be looking at this issue for a while because I'm running Debian on the Thinkpad now (without Plymouth, though) and I do not have any other hardware to test with.
If somebody wants to test this further:
- do an Ubuntu 11.04 (I think that's Trisquel 5's base) install on the same machine and see if the problem persists,
- do the installs on both 7200 and 5400 hard drives.
If Ubuntu works on the same machine with both drive speeds, or at least on the drive where Trisquel's Plymouth is corrupted, then the problem lies with Trisquel. I don't know if Trisquel makes any changes to startup, though.
Otherwise it could be that it just starts too late and a slower hard drive gives it enough time to load. In which case someone with a better understanding of the startup load order might be able to help?
OK, so I actually found another 5400 hard drive to put into the Thinkpad. My testing so far:
- 5400 vs 7200 hard drive makes no difference to Plymouth,
- Ubuntu 11.04 gives me a similarly corrupted Plymouth.
I found an interesting thing. When the corrupted image appears and I switch to another console (for example CTRL+ALT+F6) and switch back (CTRL+ALT+F7) immediately, the Plymouth animation actually works 100% for the remaining few seconds.
I'm now busy installing Ubuntu 11.10 to see if anything has changed there.
With Ubuntu 11.10 so far:
- Plymouth is still corrupted (similar graphical distortion)
- Switching the console when the garbled image appears and switching back causes Plymouth to display correctly for the very short remaining time.
I can confirm that comment 5 at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/723477 produces a minor (hacky) solution.
I removed vt.handoff=7 as per that comment and Plymouth does not corrupt now but there is quite a long time before the Plymouth even starts to show. And just before it appears, there is a flash of something that seems corrupted (mostly black with a few white marks).
Thanks for datailing your tests and researches!
I did some more testing using my Thinkpad. I measured the time from pressing the laptop's power button until some image from Plymouth appears and also the total time (including that) until I get the login screen. The times were measured with a stopwatch so the timing might off by ~ +1/-1 seconds. But for the sake of this experiment, it does not matter. I turned the laptop off after each test and started the timer when I powered on.
I tested with Trisquel 4.5, 5, Ubuntu 10.10, 11.04 and 11.10. For 5, 11.04, 11.10 I tested with both a standard install and with the solution I propose below.
From the results I conclude (as myself being the only subject) that:
1. the "long wait" mentioned in my comment #8 probably isn't related to this whole issue specifically. Trisquel 5 and all the Ubuntus took approximately the same time to show the Plymouth animation. However, 4.5's showed Plymouth and the login screen about 10 seconds earlier than the others. That explains why I thought 5 took very long before it showed Plymouth.
2. vt.handoff is (one of) the reason(s) why some graphics cards (I suspect mostly nvidea+nouveau) cause a corruption with Plymouth. I came across some other Ubuntu Plymouth related issues (I don't have the URLs anymore) that are also caused by the presence of vt.handoff.
[SOLUTION]
If you are experiencing Plymouth graphical corruption at startup similar to the image (https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/713088/+attachment/1829213/+files/IMG_20110204_080741.resized.jpg) attached to this Ubuntu bug report (https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/713088) then my solution is to remove the vt.handoff parameter from your grub configuration. The steps are as follows:
sudo gedit /etc/grub.d/10_linux
Find the line that has "vt.handoff" in it (it should be around line 70). Change it from:
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT vt.handoff=7"
to:
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT"
Save.
sudo update-grub
[END OF SOLUTION]
Daniel Molina, Hiawatha and others who are experiencing this issue, could you please try the above solution and confirm that it no longer corrupts the Plymouth animation?
I tried to install Trisquel 5 and I didn't experience the error! I had such experience with Trisquel 4.5, but I didn't reproduce it this time. The only problem was that brightness was very low an I was not be able to adjust it with the Fn key; it always indicated the maximum brightness in the notification of the top-right part of the screen, but it was false. It happened in the live session and later using the installation.
However, after the first upgrading of the system brightness problem was fixed. My graphic card is Intel Corporation 82852/855GM Integrated Graphics Device.
In the past I experienced problems with the video card, maybe it is a bit broken. Bad restarters, fixed patterns of colors in the screen, sometimes moving in some direction, bad behavior when playing during a time openarena, etc..
Let me make sure I understand you correctly.
Did you experience graphical corruption like in this image with a previous (<= 4.5) version of Trisquel but not with 5?
I have only used 4.5 and 5 and it only started happening for me with 5. This corresponds with changes made to Ubuntu 11.04 where, as far as I could tell, this specific problem started appearing or started being much more prominent. And it seems that this happens mostly with Nvidia graphics using the Nouveau driver. I have not seen a report of this happening with Intel graphics.
It is possible that something is wrong with your graphics chip and that it caused a similar corruption that we are experiencing, but for a different reason.
Unfortunately I don't know what could have gone wrong with the brightness switching. I'm not even sure where exactly that gets handled. But I don't think it has anything to do with Plymouth.
I think I was wrong; probably it is a different problem. It happened long time ago. Maybe I saw it in another machine.
I've tried a Trisquel 4.0 live session and now I think that I'm experiencing the problem I had in the past. I'll describe the case with the hope of help, not being off-topic.
If I try 4.0 "live without installing", I see a big blue trisquel in the middle of the screen, but after finishing the step, screen turns black and then the system doesn't respond (also to Ctr+Alt+PrtSc REISUB), so I have to switch off the computer pressing the power button. If I try "safe graphic mode" I see this message everytime on the screen changing the numbers xxxxx and yyyyy.
[sr0]Add: Sense: Unrecovered read Error
end_request: I/O error, dev sr0 sector xxxx
Buffer I/O error on device sr0, logical block yyyyy
But after some time it goes away and it carries me to the graphical login (I'd like adding that I tried it turning between tty1 and tty7).
I installed Trisquel 5 with the only problem of the brightness. The current situation, after upgrading, is that brightness cannot be set, but if I through out the power wire (and optionally entered in the correct site again) then I can control the brightness correctly with the Fn key. I always do this procedure because the default (fixed) level of bright is a bit low.
I hope that it be useful. Sorry for reporting without being sure.
Hi Daniel,
If you don't mind, could you post this as a new thread? I don't want to make this thread too long with unrelated issues. I will move this reply to your new thread when it's done. But I can give a quick thought about those issues:
- The first issue could be that your CD is damaged. Or there is a problem with some software that was used at that time. For example, there was a Debian bug of around the time 4.0.1 was released where it tries to read something from the CD when it should not. I don't have a 4.0 CD, but I do have the FSF usb card with 4.0. When I boot that in safe graphics mode, I get a lot of
/init: line 3: can't open /dev/sr0: No medium found
errors. After a quick search, I found an Ubuntu bug that might be related to my error. But my system boots successfully with both "Try without any changes" and "Safe graphics mode".
-For the second issue, what laptop are you using? I do not have any other laptops to test this on and I don't get that error with my Thinkpad.
Thanks very much for doing all of this investigation. Unfortunately, the above solution didn't work.
Thanks for trying that, though.
What graphics card are you using? And did the above change have *any* effect at all?
If you do CTRL+ALT+F6 when the corrupted image appears and then immediately thereafter CTRL+ALT+F7 what do you see? I get a brief flash of black (as it switches to the other console) and then it displays the Plymouth animation correctly (without removing vt.handoff in my case). If you aren't getting that then you might be having a different problem because the vt.handoff thing tries to maintain the video memory and by switching you clear that (http://askubuntu.com/questions/32999/what-is-vt-handoff-7-parameter-in-grub-cfg).
Could you try one more thing? Try to enable the framebuffer for Plymouth and see if it makes a difference:
sudo -s echo FRAMEBUFFER=y >>/etc/initramfs-tools/conf.d/splash update-initramfs -u
I would really like to get some sort of fix for this, even if it has to be done after the installation. In my opinion this could be a problem if someone wants to try Trisquel as their first GNU/Linux distro and they see a broken splash screen. It's easy for them to then claim that either "Linux is broken", or that because of "freedom extremism" the system is broken, even though this is an upstream/Ubuntu error.
I suppose I should track it on their side, but the bug report I mentioned in the beginning has not been resolved and if I use the proprietary Nvidia driver it does not cause corruption. Given that there does not seem to be a universal solution when using nouveau, using the proprietary driver will be their solution and this is not acceptable in our case.
Hi malberts,
First, to answer your question: I've got an NVIDIA Geforce 8300 GS video card installed (came with the machine). I didn't try your suggested solution, because "FRAMEBUFFER=y" was already in /etc/initramfs-tools/conf.d/splash
Although the corrupt screen used to be displayed for at least a few seconds during boot, it now only flashes for a moment before the boot screen is cleared, hence there is not enough time to try the CTRL-ALT-F6 and F7 test.
I'm not sure when this change happened: Either when I installed 64-bit Trisquel over 32-bit Trisquel, or when I changed the GRUB splash screen by replacing trisquel-grub.png with one of Khany's artwork pngs and doing an update-grub. The new splash actually displays correctly for a while before momentarily appearing corrupt.
If needed, I can put the old one back in place, and/or take the FRAMEBUFFER=y line out of /etc/initramfs-tools/conf.d/splash
Also, for the record, the vt.handoff=7 parameter is still removed from /etc/grub.d/10_linux, it's possible that *did* make a difference. I'll try putting that back in as well and see what happens.
Just to be sure, did you install 64-bit Trisquel 5 over 32-bit Trisquel 5 by formatting the hard drive? Or did you update it somehow? Or did you install 5 64 over an older 32-bit?
I don't think 32-bit vs 64-bit has anything to do with it, though. It corrupts on both 32- and 64-bit for me.
My theory is that Ubuntu changed something in 11.04 (Trisquel ~5) that was not there in 10.10 (Trisquel ~4.5) which was the last time Plymouth worked. One of those things are vt.handoff. Alternatively, it could be that around that time some part of software frozen at that time introduced a regression that has not been fixed as of Ubuntu 11.10.
Also, I don't think the GRUB background has an effect. I have only Trisquel on the Thinkpad GRUB never shows for me so I have a black screen until the corruption starts. I booted with SHIFT to force GRUB to show and the only difference is that the GRUB image (I tested the default and a custom) shows up until the corruption part and then gets corrupted along with the Plymouth splash.
With vt.handoff=7 present, when the corruption starts the GRUB image is squashed and corrupted into the top half and the Plymouth splash squashed into the bottom half. Though normally, my top half is black because GRUB is hidden. This lasts until GDM displays.
Without vt.handoff, the GRUB image displays, then a quick flash of corruption and then the working Plymouth splash for a few seconds until GDM displays. However, this corruption is now of only the GRUB image, or black with a few white lines in my case. It looks different compared to the corruption with vt.handoff - specifically, the Plymouth splash does not get squashed/corrupted with it. I wanted to take a photo but I cannot capture it quickly enough. When you get the flash, does yours also look different to what you get with vt.handoff present?
The reason that you are not seeing the splash with vt.handoff removed could be because your computer is faster than mine and by that time yours is done loading. [1]
You can leave the FRAMEBUFFER line as it was. I have been unable detect any difference, whether present or not.
To do the CTRL-ALT-F6 and F7 test you will have to put vt.handoff back in. I cannot get it to switch when it's removed.
Fedora 16 came out about a month after Ubuntu 11.10 and it has a working Plymouth animation on my Thinkpad. Fedora 16 has more up-to-date software so it is possible that a newer version of Nouveau (or something else) might have introduced a fix for this. Otherwise I will have to examine what really happens at boot time and compare what Ubuntu and Fedora do differently, but I'm sure if my knowledge is quite there yet.
-
[1] Using a stopwatch, from the point of pressing ENTER at GRUB it takes ~30 seconds to get to GDM. The flash of corruption starts at ~15 seconds then the working Plymouth splash at ~16 and that lasts until ~30 seconds when GDM pops up.
In going from 32-bit to 64-bit Trisquel, I reformatted the drive, so it was basically a new install. Testing: I left the FRAMEBUFFER line as-is, and tried the GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT" both with and without the vt.handoff=7 parameter.
The behavior is as you describe. With vt.handoff=7, I'm seeing the combined corrupted image for at least a good 7-10 seconds. Without it, I'm only seeing the single corrupted image for an aprox. one-second flash when the grub screen clears. I also tried the Ctrl-Alt-F6 and F7 test while vt.handoff=7 was back in, and that worked as described too.
It appears that either the workaround of removing vt.handoff=7 doesn't work under 32-bit, or I did it incorrectly. Since it worked for you under both versions, I'm assuming the latter. Either way, it's working for me now.