|
Bugzilla – Full Text Bug Listing |
| Summary: | yast2 repair "repair file system" not working. | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Casual J. Programmer <casualprogrammer> |
| Component: | YaST2 | Assignee: | Jiří Suchomel <jsuchome> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Major | ||
| Priority: | P5 - None | ||
| Version: | Alpha 2 | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | openSUSE 11.0 | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 355010 | ||
| Attachments: |
yast2logs
yast2logs yast2logs patch for /usr/share/YaST2/modules/OSRFsck.ycp yast2logs |
||
|
Description
Casual J. Programmer
2007-12-23 10:10:42 UTC
Created attachment 188619 [details]
yast2logs
Sorry, but the logfiles do not mention lauching yast2 repair at all. Please attach correct logs just after you see the problem. Created attachment 189027 [details]
yast2logs
This should cover it.
Was the error real or was it a false alarm? Which command did you use to actually fix the problem?
Looks like yast2-repair only attempts to repair the file system (using fsck.ext2 -p -f /dev/sdb1) when the check command (fsck.ext2 -n -f) returned 4 ("File system errors left uncorrected" according to man page). This time, the return value of the check command was 8 ("Operational error"). I'm not sure what should be done in that case... Matthias?
Actually the filesystem had some problems which were fixed in the process. I used the umount /media/WS6L-Extern1 e2fsck /dev/sdb1 commands as suggested in the info pane of yast2 repair. Not sure whether it matters that /dev/sdb1 is an external firewire drive which has no fstab entry as it is only used occasionally. Hm, and what the exact commands called by YaST (fsck.ext2 -n -f, fsck.ext2 -p -f). Do they work for you from command line? workstation6l:/home/cjp # umount /media/WS6L-Extern1 workstation6l:/home/cjp # fsck.ext2 -n -f /dev/sdb1 e2fsck 1.40.2 (12-Jul-2007) Pass 1: Checking inodes, blocks, and sizes Looks like it's working. Hm, so is everything fixed already? Does it still report error when you run yast2 repair? (Because yast reports "Error while iterating over blocks in inode 435272: Illegal triply indirect block found" after fsck.ext2 -n) Somewhat has changed here. Now at yast2-repair-2.16.2-18. Running yast2 repair now starts a job on /dev/sdb1 but never ( within the time I am willing to wait for it ) comes to an end. Running e2fsck returns: e2fsck /dev/sdb1 e2fsck 1.40.2 (12-Jul-2007) WS6L-Extern1 (/dev/sdb1): clean, 86713/24428544 files, 23143939/48839600 blocks almost immediately. Created attachment 189130 [details]
yast2logs
Created attachment 189133 [details]
patch for /usr/share/YaST2/modules/OSRFsck.ycp
Strange. Let's add verbose option to fsck.ext2: Patch OSRFsck.ycp, call 'ycpc -c OSRFsck.ycp', try again and attach new log.
OK, maybe I'm too impatient. It now ran through after 12min. Logs attached. Created attachment 189140 [details]
yast2logs
According to the last y2log, it looks like the check was correct now, right? Yes the check was OK, but the the drive was marked clean to begin with and the initial problem was that the check was never carried out in the first place but rather some kind of endless loop announcing it. Not sure how to recreate the situation. As far as I recall the drive / filesystem hadn't been checked for so many days and also in fact had quite some problems which were fixed. The initial problem was caused by the situation described in comment 4. fsck.ext2 first returned strange error code, so YaST doesn't really tried to do a repair attempt. Matthias, could I safely call the "repair" run of fsck.ext2 ("fsck.ext2 -p -f" call) when the "check" command ("fsck.ext2 -n") returned 8 ("Operational error" - the error message was "Error while iterating over blocks in inode 435272: Illegal triply indirect block found")? Yes, it should be safe to call the "repair" run after the "check" run returned 8. Mostly e2fsck returns 8, when something failed in initialisation error, but there might be cases where this is not the case. Running -p does not hurt as it operates safely, if it detects the requirement for additional corrections it will exit. Thanks, Matthias. Fixed in yast2-repair-2.16.4 |