|
Bugzilla – Full Text Bug Listing |
| Summary: | Shrinking ReiserFS during install makes fsck fail on reboot | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Jens Benecke <jens-novell> |
| Component: | YaST2 | Assignee: | Thomas Fehr <fehr> |
| Status: | RESOLVED FIXED | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Critical | ||
| Priority: | P5 - None | ||
| Version: | RC 1 | ||
| Target Milestone: | SUSE Linux 10.1 | ||
| Hardware: | 32bit | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | YaST2 installation log archive | ||
|
Description
Jens Benecke
2005-09-18 20:21:14 UTC
Created attachment 50254 [details]
YaST2 installation log archive
Here is the reiserfsck output from the partition: Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes bread: Cannot read the block (18876374): (Invalid argument). reiserfs_open: Your partition is not big enough to contain the filesystem of (18876374) blocks as was specified in the found super block. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb. Aborted This sounds not good. Raising severity to critical. As it looks the resize-tool does not modify the superblock of the resized filesystem correctly! Problem can happen if resized partition does not start on a cylinder boundary. Fixed in current SVN head. Fix will be available in SL 10.1. Hi, Thanks a lot for fixing this bug ... but ... are you leaving a critical file system destroying bug that effectively prevents an upgrade in the released product (10.0)? I suspect I don't see the "whole picture" behind this bug, but I can see the news headlines already: "SuSE Linux upgrade destroys harddisks" ... ;-) Isn't it possible to check for the described case where the partition might get treated wrongly, and then refuse to resize (for 10.0)? IMHO this would be much preferable. Thanks! Jens Backporting the fix to 10.0 is not the problem. I will do this and will make
an online update available. Unfortunately this will not help much, since most
people will resize during installation and the buggy version is on the DVD.
Fortunetaly the problem is not as bad as it looks at first sight. Effectly
the last some Megabytes of the fs get lost (the loss is smaller than a disk
cylinder, in your case it was 32k). One can rebuild the corrupted reiserfs
pretty easy the follwing way:
1) reiserfsck --rebuild-sb -y <device>
answer "y" to all questions asked an do not change the suggest size
2) reiserfsck --check -y <device>
this will tell you if anything is corrupted and how to call reiserfsck
next. I my testcases I had to call reiserfsck with option "--fix-fixable"
3) reiserfsck --fix-fixable -y /dev/hdb2
4) mount fixed reiserfs
I did the following testcases:
started filesystem with size of 2.0 Gig and about 200000 files that was 71% full
- resized to about 88% full loosing the last 5 Meg of the fs
--> no files lost/corrupted
- resized to about 93% full loosing the last 6 Meg of the fs
--> 13 files lost/corrupted
- resized to about 96% full loosing the last 6 Meg of the fs
--> no files lost/corrupted
- resized to about 99% full loosing the last 6 Meg of the fs
--> 231 files lost/corrupted
Hi, I understand the DVD images are already frozen. OK, I see there is not much one can do about this (maybe provide a "driver disk" with a fix that is loaded during install?) Thank you for the instructions about how to fix my partition. :-) Thank you also for tracking this bug down and doing the testcases! I'm gonna buy a 10.0 box when it's released... Jens |