Bug 529285 - Init maintenance mode is not usable
Summary: Init maintenance mode is not usable
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
Blocks: F12Blocker, F12FinalBlocker
TreeView+ depends on / blocked
Reported: 2009-10-15 23:23 UTC by A. Mani
Modified: 2009-10-21 18:32 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2009-10-19 18:38:46 UTC

Attachments (Terms of Use)

Description A. Mani 2009-10-15 23:23:03 UTC
Description of problem:
After resizing boot partition of ~5GB to 2GB, the boot process stops claiming that there is an inconsistency in the boot partition file system (ext4). This happens even after fsck from a Parted Magic CD. 

The "press Control D to continue or supply root password ... " is not usable. After typing a single letter, the whole thing resets. Seems to be some blunder in coding.    

Version-Release number of selected component (if applicable):

Rawhide 3 days old.

How reproducible:

Partitions : Primary : vfat, ext4(/boot), xfs 
logical: ext4 (/home), ext4 (/) -both encrypted

Resize /boot and give free space to vfat partition with parted magic CD (-4.0)


Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 seventhguardian 2009-10-17 17:41:52 UTC
Please explain what you did.

Did you just resize the partition, or did you shrink the filesystem first?

Comment 2 A. Mani 2009-10-17 18:31:09 UTC
1. shrink partition sda2 (ext4) 
2. expand partition sda1 (vfat)

Is it due to the version (1.41.5) of e2fsprogs?

Comment 3 A. Mani 2009-10-17 18:33:50 UTC
More info (repeat of mail to test list):

Actually resizing led to overlapping partitions: logical /swap (sda5)
ended up as another primary due to resize of the primary ext4 /boot
partition (sda2) and sda1. Physically sda5 was next to sda2.
Before Resize:

DOS partition Table
primary sda1, 2
Extended -3
logicals :sda5, .. 7
primary sda4

Comment 4 seventhguardian 2009-10-17 19:25:47 UTC
(In reply to comment #2)
> 1. shrink partition sda2 (ext4) 
> 2. expand partition sda1 (vfat)

You need to shrink the filesystem (the "table" where the files are placed inside the partition) before resizing the partition itself. Otherwise you get a corrupted filesystem, which you did.

Moreover I can't see how this is related to fedora, since you've used parted magic to do the resizing.

Comment 5 A. Mani 2009-10-17 20:35:18 UTC
I think you have missed the main problem.  "press Control D to continue or supply root password for maintanence" was not usable. If the system has a problem then it should exit gracefully. 

The other problem seems to be basically due to e2fsprogs ... OK

Comment 6 Vedran Miletić 2009-10-17 20:52:00 UTC
Yeah, this is not a bug in e2fsprogs. Reopening. I also reproduced it today in a totally different way, after messing with system time.

Comment 7 seventhguardian 2009-10-17 21:00:44 UTC
Fine, I'm fixing the summary then.

Comment 8 Vedran Miletić 2009-10-18 11:24:20 UTC
This is actually quite nasty. Raising severity and adding F12Blocker.

Comment 9 Ray Strode [halfline] 2009-10-19 18:38:46 UTC
This should be fixed with recent versions of plymouth.

Comment 10 Joachim Frieben 2009-10-21 17:52:32 UTC
Thr problem is that despite using the journalling file system ext4, file system inconsistencies after an unclean system shutdown started to appear a few weeks ago. I had reported bug 523378 where this issue is described in detail. When this happens, I do not have the opportunity to even try to enter maintenance mode: the system announces automatic reboot and starts over within seconds. Only after the next reboot, a file system check is performed, and the system starts up as expected. However, several times during the last weeks, I was stuck in this automatic reboot cycle forcing me to reinstall the system because of irreparable file system corruption. This do not happen while F11 was installed. The issue seems to be related to the actual time zone (UTC+2) as the first error message is "Superblock last write time is in the future".

Comment 11 seventhguardian 2009-10-21 18:32:37 UTC
I've been using rawhide for awhile now, and never experienced any filesystem corruption.

I have, however, noticed that my bios clock gets reset from time to time. I then need to set it correctly, otherwise I end up with the "Superblock last write time is in the future" errors you mentioned. Is it possible that you are experiencing something similar instead of filesystem corruption?

Note You need to log in before you can comment on or make changes to this bug.