This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 529285

Summary: Init maintenance mode is not usable
Product: [Fedora] Fedora Reporter: A. Mani <a.mani.cms>
Component: plymouthAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: fedora, jfrieben, krh, rstrode, seventhguardian, vedran
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-19 14:38:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 473303    

Description A. Mani 2009-10-15 19:23:03 EDT
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.
X86-64 

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)

reboot 


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 seventhguardian 2009-10-17 13:41:52 EDT
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 14:31:09 EDT
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 14:33:50 EDT
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 15:25:47 EDT
(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 16:35:18 EDT
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 16:52:00 EDT
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 17:00:44 EDT
Fine, I'm fixing the summary then.
Comment 8 Vedran Miletić 2009-10-18 07:24:20 EDT
This is actually quite nasty. Raising severity and adding F12Blocker.
Comment 9 Ray Strode [halfline] 2009-10-19 14:38:46 EDT
This should be fixed with recent versions of plymouth.
Comment 10 Joachim Frieben 2009-10-21 13:52:32 EDT
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 14:32:37 EDT
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?