| Summary: | screen goes blank after starting dracut with kernels compiled on F16 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | udo <udovdh> |
| Component: | dracut | Assignee: | dracut-maint |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | dracut-maint, harald, jonathan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-23 09:49:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
udo
2011-12-04 16:21:31 UTC
sounds like a malicious kernel module So if I compile the same 3.0.3 rt source and get the new F16 behaviour, what then? I believe I found the case of not booting. The screen still stays blank after starting ramdisk but mounting etc continues now and Xorg is started. I guess that the contents of /etc/mdadm.conf do matter. I noticed some lines were added to the original anaconda written config. So I hashed out the first two ARRAY lines, did a `make modules_install install` and booted successfully. So problem remaining is the dark screen (fbcon issue I think) and also this bug https://bugzilla.redhat.com/show_bug.cgi?id=759842 about Fedora kernels not starting /dev/md1. The fbcon issue was reproduced with the exact same config as the F15 kernel. Can a certain part of dmesg output help find the cause? (In reply to comment #4) > Can a certain part of dmesg output help find the cause? I am not a kernel developer, you should seek help there. If I compile same identical source and config on F15 and F16, in this case kernel 3.0.3 rt, and I get different results w.r.t. probably fbcon working fine (F15) or not (F16) it is of course not a fedora issue. The only thing changed is the distro. Also: I think I see this fbcon issue on my MythTV box (CRT TV via hdmi goes blue) as well as on the audio workstation (LCD monitor goes into powersave). After asking on #radeon we found that this helps: # cat /etc/dracut.conf.d/fbcon.conf add_drivers+="fbcon" Then do a new `make modules_install install` and all should be OK after a reboot. While upgrading (via yum) this very workstation I found: # diff -urN /etc/dracut.conf /etc/dracut.conf.rpmnew --- /etc/dracut.conf 2011-01-11 15:58:21.259948356 +0100 +++ /etc/dracut.conf.rpmnew 2011-11-17 11:22:50.000000000 +0100 @@ -1,7 +1,12 @@ # Sample dracut config file -# Specific list of dracut modules to use -#dracutmodules+="foo bar baz" +logfile=/var/log/dracut.log +fileloglvl=6 + +# Exact list of dracut modules to use. Modules not listed here are not going +# to be included. If you only want to add some optional modules use +# add_dracutmodules option instead. +#dracutmodules+="" # Dracut modules to omit #omit_dracutmodules+="" @@ -10,7 +15,7 @@ #add_dracutmodules+="" # additional kernel modules to the default -add_drivers+="fbcon radeon" +#add_drivers+="" # list of kernel filesystem modules to be included in the generic initramfs #filesystems+="" So that explains this problem. More severely is that the Changelog of this software does NOT mention this change at all, see e.g. http://fr2.rpmfind.net//linux/RPM/fedora/updates/16/x86_64/dracut-013-19.fc16.noarch.html So who made this change? The author? I did not find the git commit. This problem cost me some time, that is why I ask. (In reply to comment #9) > While upgrading (via yum) this very workstation I found: > > # diff -urN /etc/dracut.conf /etc/dracut.conf.rpmnew > --- /etc/dracut.conf 2011-01-11 15:58:21.259948356 +0100 > +++ /etc/dracut.conf.rpmnew 2011-11-17 11:22:50.000000000 +0100 > @@ -1,7 +1,12 @@ > # Sample dracut config file > > -# Specific list of dracut modules to use > -#dracutmodules+="foo bar baz" > +logfile=/var/log/dracut.log > +fileloglvl=6 > + > +# Exact list of dracut modules to use. Modules not listed here are not going > +# to be included. If you only want to add some optional modules use > +# add_dracutmodules option instead. > +#dracutmodules+="" > > # Dracut modules to omit > #omit_dracutmodules+="" > @@ -10,7 +15,7 @@ > #add_dracutmodules+="" > > # additional kernel modules to the default > -add_drivers+="fbcon radeon" > +#add_drivers+="" > > # list of kernel filesystem modules to be included in the generic initramfs > #filesystems+="" > and? you modified /etc/dracut.conf /etc/dracut.conf is %config(noreplace) so, any changes you made to /etc/dracut.conf are not discarded, but the original dracut.conf template, which comes with the packages, is saved as dracut.conf.rpmnew > > So that explains this problem. > More severely is that the Changelog of this software does NOT mention this > change at all, see e.g. > http://fr2.rpmfind.net//linux/RPM/fedora/updates/16/x86_64/dracut-013-19.fc16.noarch.html > > So who made this change? The author? > I did not find the git commit. > This problem cost me some time, that is why I ask. Which changes did I make? I did _not_ remove your add_drivers+="fbcon radeon" line, nor was it present in the default configuration file shipped with the dracut package. Thanks for explaining what I did. I do not remember that I changed this, though I am sure (certain!) that I did not change this on all three boxes where I see this. Only on this very box I had the rpmnew thing. On of the other two boxes (that is on) did *not* have an rpmnew for dracut.conf I did not see this problem there before going to F16. The combination of this issue, together with the failure to start /dev/md1 and thus no Xorg, no system, made me really look into this on the very first box I migrated to F16. It made me wait with F16 for this box as it ha encrypted root etc and I really need a console there. I will also check the 3rd box for dracut.conf.rpmnew, though I doubt it is there. I did not notice a non-working console there while on F15. (box is used once a month on average) |