Hide Forgot
Description of problem: I put an invalid LABEL= directive in /etc/fstab (on non-system partition), which provoked a mount failure at next boot. However, upon mount failure, when I got the "Give root password for maintenance (or type control-D to continue):" message, nothing I type works. Each keypress makes it print "invalid password" and repeat the prompt. Even Control-D. Thus, the system was unusable, and I had to repair /etc/fstab via a live-CD. Version-Release number of selected component (if applicable): sysvinit-tools-2.86-27.x86_64 How reproducible: every time Steps to Reproduce: 1. echo 'LABEL=no-such /nowhere ext4 defaults 1 3' >> /etc/fstab 2. reboot 3. Actual results: typing anything at the "Give root password..." prompt is ineffective Expected results: typing ^D or root password has the desired effect Additional info:
I added something like that to my fstab, and I'm able to log in with sulogin fine.
Thanks for checking, Bill. Is selinux in enforcing mode for you? It is for me. Haven't yet tried without.
also, in sulogin.c, I see that read failure (right after that prompt) is ignored. Might be worth diagnosing when read returns -1: if (read(0, pass, sizeof(pass) - 1) <= 0) ret = NULL; else { for(i = 0; i < sizeof(pass) && pass[i]; i++) if (pass[i] == '\r' || pass[i] == '\n') { pass[i] = 0; break; } }
Might try booting w/o 'rhgb quiet', if you're booting that way at the moment.
I've just rebooted a few times. I tried removing "rhgb quiet". and later with enforcing=0. Neither helped or showed me any more information than I had already seen (I usually hit down-arrow, so I can watch dmesg output go by). I presume the above read syscall is failing. Any suggestion on how I can determine how/why?
The obvious-but-cheesy way would be to slap a strace in front of all the sulogin calls in rc.sysinit.
I've just tried that, by replacing each of the three sulogin lines by strace -o /root/sulog sulogin in /etc/rc.sysinit. However, that left me with a rolling reboot. Why? (and i didn't see any diagnostic -- could have missed it, though) At first I suspected it was the use of "strace" rather than "/usr/bin/strace", but I ruled that out when I saw the ". /etc/init.d/functions" line at the top. It sets PATH to include /usr/bin. Suggestions welcome. [hmm... still always with selinux enabled. I've lost the habit of trying with it disabled. will try that next] For now, I've restored rc.sysinit and fstab, rebooted (this is my primary system, after all) and am back to regularly-scheduled work.
I encountered this same problem after updating to F12. About half the time, the system thinks one of my disks is hosed (and encounters this problem). The other half, it thinks the disk is fine (and boots normally). Additionally, I tried single-user mode on one of the lucky boot-ups and found that my login shell was also broken. I couldn't see anything I typed. I could see output from commands, but the newlines were missing. So if I typed cat /etc/fstab I got my fstab, wrapped a few times.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug is present and doing just fine in Fedora 12 too. I just got bitten by it. See bug 531047 with a number of comments there. One should likely be closed as a duplicate.
*** This bug has been marked as a duplicate of bug 531047 ***