Bug 529285
| Summary: | Init maintenance mode is not usable | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | A. Mani <a.mani.cms> |
| Component: | plymouth | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | 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 18:38:46 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 473303 | ||
|
Description
A. Mani
2009-10-15 23:23:03 UTC
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? |