Fedora Linux Support Community & Resources Center
  #1  
Old 6th November 2010, 03:30 AM
Mack Offline
Registered User
 
Join Date: Mar 2006
Location: Central California
Posts: 109
linuxfirefox
Can't give root password for boot fsck

UPDATE: This is a bug: https://bugzilla.redhat.com/show_bug.cgi?id=636628

Evidently the problem is with plymouth because a workaround is to add "rd_NO_PLYMOUTH" to the kernel boot options. I don't get a prompt for my disk encyrption pass phrase---just a flashing cursor---but that's a small price to pay for being able to run fsck when the root filesystem wasn't umounted properly.

-------------------------------------

Hello and thanks for reading this.

I have fully updated f13 (as of today) on a laptop with all ext2 file systems (It has nothing but flash memory.) If it's shut down without unmounting all file systems, it drops to a shell and asks for the root password to run fsck when it's rebooted. Every key press is treated as though it were <enter>, with a response to the effect that the password is incorrect.

Is there any way out of this?

Thanks for any suggestions!

Last edited by Mack; 4th December 2010 at 04:06 AM. Reason: A workaround for the problem has been found.
Reply With Quote
  #2  
Old 6th November 2010, 04:07 AM
jpollard Online
Registered User
 
Join Date: Aug 2009
Location: Waldorf, Maryland
Posts: 6,847
linuxfedorafirefox
Re: Can't give root password for boot fsck

Make sure you don't have a function key set (like caps lock).

I have seen this - but it has (in the past) cleared up as soon as the
keyboard is set right. If this is a reduced keyboard, there can be
multiple function keys that operate like the shift lock (or num lock)
keys that can cause this.
Reply With Quote
  #3  
Old 6th November 2010, 04:29 AM
Mack Offline
Registered User
 
Join Date: Mar 2006
Location: Central California
Posts: 109
linuxfirefox
Re: Can't give root password for boot fsck

Thanks very much for the reply, but that's not it.

Another hint, though it may be irrelevant: The filesystem is encrypted, so I'm first prompted for the password. Booting text mode (deleting "rhgh" from the kernel options) the prompt for the password is almost as wide as the screen because it includes the UUID of the partition. When I type in the passphrase, I get a strin of *'s till I come to the edge of the screen. Then each character I type produces a copy of the entire line. Nevertheless, the passphrase is accepted.
Reply With Quote
  #4  
Old 6th November 2010, 09:43 AM
marriedto51 Offline
Registered User
 
Join Date: Jul 2009
Location: England, UK
Posts: 910
linuxfedorafirefox
Re: Can't give root password for boot fsck

I don't know about the specific problem with entering the password, but can you perhaps get round it by booting a live CD (or the install/rescue DVD), running fsck manually and then rebooting?

You probably have good reasons for sticking with ext2, but in my experience migrating to ext3 means that you just get a "Recovering journal" message at boot time in this sort of situation, and no need to run fsck.
Reply With Quote
  #5  
Old 6th November 2010, 12:50 PM
jpollard Online
Registered User
 
Join Date: Aug 2009
Location: Waldorf, Maryland
Posts: 6,847
linuxfedorafirefox
Re: Can't give root password for boot fsck

Quote:
Originally Posted by Mack View Post
Thanks very much for the reply, but that's not it.

Another hint, though it may be irrelevant: The filesystem is encrypted, so I'm first prompted for the password. Booting text mode (deleting "rhgh" from the kernel options) the prompt for the password is almost as wide as the screen because it includes the UUID of the partition. When I type in the passphrase, I get a strin of *'s till I come to the edge of the screen. Then each character I type produces a copy of the entire line. Nevertheless, the passphrase is accepted.
That sounds more like a bug somewhere.
Reply With Quote
  #6  
Old 6th November 2010, 05:53 PM
Mack Offline
Registered User
 
Join Date: Mar 2006
Location: Central California
Posts: 109
linuxfirefox
Re: Can't give root password for boot fsck

Thanks for the replies.

It does seem that there's a bug here, but I'm not sure what to file it against---init, nash, fsck, maybe cryptsetup? I also don't have the sort of hard information that's most useful developers and don't know how to get it. Any suggestions before I try bugzilla would be greatly appreciated.

I did manage to get around this as marriedto51 suggests by booting a live image and running fsck on the unclean partitions, though the first time it happened I didn't have a live image with me and I really really really needed to be able to boot.

I've experimented a lot since then and found other weird problems that might be related, but might not be, too. Other Bad Things happen, but it's hard to see a connection to the keyboard input problem while trying to boot.

After booting from a live image, start by running "cryptsetup luksOpen ..." to decrypt the partition, setting up block devices /dev/mapper/xxx and /dev/dm-n for the unencrypted partition. At this point, typically fsck reports that /dev/mapper/xxx either is not an ext2 partition or that its superblock is bad. The same holds for the alternate superblock e2fsck suggests.

Nevertheless, I can mount it ("mount -t ext2 /dev/mapper/xxx /mnt"), cd to it, etc, and umount it without errors. At this point I can usually---but not always---run fsck normally to correct errors. I get this same behavior even when the partition was unmounted cleanly and is error free. Furthermore, this problem doesn't seem to occur using the /dev/dm-n device rather than the /dev/mapper/xxx device.

I use ext2 rather than a journaled file system because the "hard drives" on this computer are all flash memory mounted with options noatime and nodiratime to reduce unnecessary writing.
Reply With Quote
  #7  
Old 6th November 2010, 07:18 PM
stevea Offline
Registered User
 
Join Date: Apr 2006
Location: Ohio, USA
Posts: 8,836
linuxfedorafirefox
Re: Can't give root password for boot fsck

Quote:
Originally Posted by Mack View Post
Thanks for the replies.
....

I use ext2 rather than a journaled file system because the "hard drives" on this computer are all flash memory mounted with options noatime and nodiratime to reduce unnecessary writing.
Yeah well - that is a wrong-headed error. To accomodate fast new technology you chose an old slow filesystem known for unreliable crash recovery. There are no "unnecessary writes", merely writes that you won't appreciate until you need to recover from a crash or test access time to trace a security breach.

"noatime" already includes "nodiratime", so if you use the former , then the latter is meaningless. These mount features cause the OS not NOT update the file metadata access time (the fstat/stat dates) for all files(including dirs) vs just dirs.

Using ext2 means you have no journal. That is completely independent of whether the access times are updated. The disadvantage of zero journal is that if your system crashes you are likely to lose files and recent write data and maybe the whole filesystem - just like in the bad old days.

The next fact on the list is that ext2 (and very early ext3) does lousy block allocation, so when you write to one file you're splashing it over a larger number of large flash blocks. ext4 is currently as fast as any Unix file system including zfs and btrfs (tho' btrfs has more future potential I think).

Linux has TRIM support - which is a way to advise the SSD drive that certain blocks are unused. If you don't use TRIM (if your SSD supports it) then disk writes get progressively slower and slower since the drive has to do a lot of last-minute garbage collection to allocate new space. So far only hdparm and the ext4 file system support TRIM, and hdparm is just a manual command method.

So if you have an SSD drive:

1/ If your drive supports TRIM then you really want to use EXT4 file systems and mount with the "discard" option to enable TRIM - or else accept dramatic performance degradation as the drive sees more use.
2/ REGARDLESS of the filesystem type you want to mount with "noatime". If you need to know access times for backup purposes then "relatime" is a good compromise. If you use "mutt" you need your head examined.
3/ The journal is a thorny topic: approaches are
A/ mount with no journal and risk a catastrophic loss
B/ mount with the journal set to another (slower) drive.
C/ use journalling and accept that you are buying some FS protection in exchange for SSD lifespan.
D/ Some filesystems will only journal the metadata (so you lose the last written data but the filesys can recover), sadly not any that support TRIM.

Yes you want to minimize the writes, but killing the journal is pretty dubious, especially when you KNOW the drive will start to fail in a few years of use.

Of course you may want to put your swap on an SSD and there is no TRIM support there. You probably want to minimize that by playing with the "swapiness" parameter.

There are a load of writes taking place in /var/log, primarily from rsyslog and also from X11. If you are not having an issue you might drop /var/log/message, but personally I'd retain /var/log/security.

Consider putting /tmp in a ramdisk with an fstab of ... if you have lots of dram.
none /tmp tmpfs defaults 0 0

---------- Post added at 02:18 PM GMT ---------- Previous post was at 02:13 PM GMT ----------

Of yeah you may want "elevator=noop" on the kernel lines of grub.conf or else
echo noop > /sys/block/sda/queue/scheduler
in your rc.local. This causes the disk scheduler to not optimize for rotating disk, tho' it's unclear that it saves much time.

There are lots of other interesting approaches - such as mounting a ram based unionfs on top of the SSD file system, then only syncing to SSD periodically. Some performance issues there.
__________________
None are more hopelessly enslaved than those who falsely believe they are free.
Johann Wolfgang von Goethe

Last edited by stevea; 6th November 2010 at 07:30 PM.
Reply With Quote
  #8  
Old 6th November 2010, 08:57 PM
Mack Offline
Registered User
 
Join Date: Mar 2006
Location: Central California
Posts: 109
linuxfirefox
Re: Can't give root password for boot fsck

stevea, thanks for all of the tips!

Quote:
Yeah well - that is a wrong-headed error. To accomodate fast new technology you chose an old slow filesystem known for unreliable crash recovery. There are no "unnecessary writes", merely writes that you won't appreciate until you need to recover from a crash or test access time to trace a security breach
There's more to the story in this case, I think. I have a tiny 4 GB SSD and use a fast 32 GB internally installed usb pendrive for /usr and some data directories. There's debate about journalling on older SSD's, and I don't have grounds for a well founded opinion. But I think it's a bad idea to update a journal every five seconds on a pendrive. I could turn down the frequency, but still it seems like a bad idea since its essentially read only.

Quote:
1/ If your drive supports TRIM then you really want to use EXT4 file systems and mount with the "discard" option to enable TRIM - or else accept dramatic performance degradation as the drive sees more use.
2/ REGARDLESS of the filesystem type you want to mount with "noatime". If you need to know access times for backup purposes then "relatime" is a good compromise. If you use "mutt" you need your head examined.
3/ The journal is a thorny topic: approaches are
A/ mount with no journal and risk a catastrophic loss
B/ mount with the journal set to another (slower) drive.
C/ use journalling and accept that you are buying some FS protection in exchange for SSD lifespan.
D/ Some filesystems will only journal the metadata (so you lose the last written data but the filesys can recover), sadly not any that support TRIM.
I'll look into TRIM for the ssd, though I suspect it's too old. It's also soldered to the MB, so I'm inclined to be relentless in cutting down on writes.

I've used Unison for backups and haven't had any trouble with mounting "noatime" since it's really mtime or ctime that matters. I think....
Even though I don't use mutt, I may need to have my head examined.

It is true that not journalling is somewhat risky, but I've lived without it on this computer for several years (Fedora 9) and never had a serious mishap.
Well, maybe that isn't quite true. My wife, traveling alone with this computer, let the battery run out. She didn't lose anything after running fsck, but didn't enjoy the experience. Ext2 may not be good for married people.

Quote:
Of course you may want to put your swap on an SSD and there is no TRIM support there. You probably want to minimize that by playing with the "swapiness" parameter.
I have enough RAM and just dispensed with a swap partition entirely. I've had one in the past for hibernation, but turned off swapiness entirely.

Quote:
There are a load of writes taking place in /var/log, primarily from rsyslog and also from X11. If you are not having an issue you might drop /var/log/message, but personally I'd retain /var/log/security.
I've been concerned about this. In F9, I modified the init scripts to put /var on a ram disk. I'd copy it to flash memory when shutting down and copy the last saved version from flash memory to the ram disk when booting. I've given up on that scheme. It dramatically increases boot time. If anything goes seriously wrong, the relevant part of /var/log/messages will be lost. And SELinux really really hates it.

Quote:
Consider putting /tmp in a ramdisk with an fstab of ... if you have lots of dram.
none /tmp tmpfs defaults 0 0
This is a great suggestion for any setup, I think. I've got this and more or less live fill time on /tmp, even on desktops. The 2 GB of dram on this machine is ample.

Quote:
Of yeah you may want "elevator=noop" on the kernel lines of grub.conf or else
echo noop > /sys/block/sda/queue/scheduler
in your rc.local. This causes the disk scheduler to not optimize for rotating disk, tho' it's unclear that it saves much time.
I have "elevator=deadline", just because I'd seen it recommended for ssd's. I'm definitely out of my depth when it comes to kernel internals. I'll try noop instead.

Quote:
There are lots of other interesting approaches - such as mounting a ram based unionfs on top of the SSD file system, then only syncing to SSD periodically. Some performance issues there
That's an interesting idea. I hadn't thought of that. Within reasonable bounds I'm not too concerned about performance. I don't know if 2 GB of ram is enough for such an arrangement.

---------

There's still the matter of what must be a bug somewhere that prevents giving a root password while booting. I suspect that it's gone relatively unnoticed because journalling file systems are covering for it.

Thanks again for taking the time to answer in such detail!
Reply With Quote
  #9  
Old 4th June 2011, 01:44 PM
geeky Offline
Registered User
 
Join Date: Jun 2011
Posts: 2
linuxubuntufirefox
Re: Can't give root password for boot fsck

I just wanted to post a follow up reply to this. I can see this thread is months old and I don't know this forums rules as I'm not regularly a fedora user. I thought it might interest people to know this has still not been fixed and is being exhibited in RHEL6.1 ... paid, licensed, commercial version.

It was sheer luck I came upon this thread and haven't found any others after looking for a solution to this problem for a few hours. I am working remotely on equipment and can't remotely mount media to do an offline repair of the filesystems but I do have console access via other means.

The fact you cannot fsck file systems after an unclean dismount is insane and the fact it is not only in fedora but somehow made its way to the latest version of commercially supported redhat is a joke.
Reply With Quote
  #10  
Old 4th June 2011, 02:28 PM
marko Offline
Registered User
 
Join Date: Jun 2004
Location: Laurel, MD USA
Posts: 6,050
linuxfirefox
Re: Can't give root password for boot fsck

I don't think I see this, I had to fsck my Atom machine recently due to a short power glitch (it has a cheap SSD ). I was able to enter the root password and I was using Fedora 14 x86_64

But I never use LVM and I notice in the bug report there was mention of LVM (inferred from the console showing "/dev/mapper/vg0-root" ), maybe LVM is involved too.
Reply With Quote
  #11  
Old 4th June 2011, 05:26 PM
Mack Offline
Registered User
 
Join Date: Mar 2006
Location: Central California
Posts: 109
linuxfirefox
Re: Can't give root password for boot fsck

Hi geeky and marko,

I know you've already found the bug report, geeky, at https://bugzilla.redhat.com/show_bug.cgi?id=636628, since I'm on the mailing list for it. It's a workaround, rather than a fix, but I've found it completely satisfactory to add rd_NO_PLYMOUTH to the kernel boot line. Without Plymouth, there is no prompt for the passphrase if your filesystem is encrypted, just a flashing cursor on a black screen. But there's no problem running fsck if necessary.

marko, this problem doesn't seem to be related to LVM. The machine I had such a problem with is a little ASUS 701 that's all flash memory which I have formatted ext2 without LVM. Plymouth is just for show. I really haven't missed it a bit.
Reply With Quote
  #12  
Old 7th June 2011, 01:42 AM
geeky Offline
Registered User
 
Join Date: Jun 2011
Posts: 2
linuxubuntufirefox
Re: Can't give root password for boot fsck

Yeah thanks Mack, I would have never known exactly what to look for in the way of troubleshooting which boot component was responsible. It could have been several things and I'd have been digging for many hours through bug complaints trying to find it if not for this post. I never would have known they replaced RHGB with this new plymouth junk.

I think redhat is big on selling their training and have kind of let go on the community aspect a bit to much. I'm finding much more relevant information related to supporting RHEL in the fedora forums then anywhere else. Future component and change-list like updates seem better found here. For instance, I was just looking at how kudzu got cut from RHEL6 and replaced with HAL for hardware detection etc and everything follows the fedora roadmap.

I'm a debian user for desktop usually but for servers redhat is still my favorite choice for something commercially supported. It looks like the fedora community is doing as good or a better job then the redhat one to me.

Quote:
Originally Posted by Mack View Post
Hi geeky and marko,

I know you've already found the bug report, geeky, at https://bugzilla.redhat.com/show_bug.cgi?id=636628, since I'm on the mailing list for it. It's a workaround, rather than a fix, but I've found it completely satisfactory to add rd_NO_PLYMOUTH to the kernel boot line. Without Plymouth, there is no prompt for the passphrase if your filesystem is encrypted, just a flashing cursor on a black screen. But there's no problem running fsck if necessary.

marko, this problem doesn't seem to be related to LVM. The machine I had such a problem with is a little ASUS 701 that's all flash memory which I have formatted ext2 without LVM. Plymouth is just for show. I really haven't missed it a bit.
Reply With Quote
Reply

Tags
boot, fsck, password, root

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Never give out your password - Did not know their are exceptions Adunaic Wibble 15 6th October 2010 10:58 PM
Boot to Grub and recovery root password gp6778 Using Fedora 5 30th July 2009 09:40 AM
how to give apache password??? Mr_raj Servers & Networking 2 30th June 2008 06:48 PM
Single user mode: Give root password for maintenance Plankton Using Fedora 2 13th June 2007 05:16 PM


Current GMT-time: 18:01 (Saturday, 20-09-2014)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat