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:
Please explain what you did. Did you just resize the partition, or did you shrink the filesystem first?
1. shrink partition sda2 (ext4) 2. expand partition sda1 (vfat) Is it due to the version (1.41.5) of e2fsprogs?
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
(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.
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
Yeah, this is not a bug in e2fsprogs. Reopening. I also reproduced it today in a totally different way, after messing with system time.
Fine, I'm fixing the summary then.
This is actually quite nasty. Raising severity and adding F12Blocker.
This should be fixed with recent versions of plymouth.
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".
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?