Bug 51208
| Summary: | fsck occurs on ext3 '/' partition after install | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Public Beta | Reporter: | Mike Sklar <sklarm> |
| Component: | anaconda | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | roswell | CC: | john_hull, notting, sct |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | ia64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-10-17 03:25:32 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: | |||
|
Description
Mike Sklar
2001-08-08 14:37:16 UTC
Have you seen this on any ia32 machines? No, just on ia64. The few ia32 machines I've installed on have booted fine. I just did an upgrade of a 7.1 dual PII machine w/current errata and it does it as well: Checking root file system "/dev/hda5 is mounted. e2fsck: Cannot continue, aborting." I commented out the fsck error > 2 code in rc.sysinit on the box for now. snowhare *** Bug 52445 has been marked as a duplicate of this bug. *** We (Red Hat) really need to fix this before next release. *** Bug 50472 has been marked as a duplicate of this bug. *** *** Bug 51004 has been marked as a duplicate of this bug. *** *** Bug 53519 has been marked as a duplicate of this bug. *** This is happening with re0908.2-ia64 * re0910.0-ia64 * German FTP Full Server TUI install This is still happening with the re0910.0-ia64 tree. The installer does not exit cleanly though. I see the following error just before reboot: "unmount /mnt/sysimage failed (16)" It blinks by so fast the one could easily miss it. Oddly enough, this did *not* happen with a German HTTP Minimal install of 0910.0-ia64. Yes, it only occurs sometimes, hence why it's proving to be difficult to track down and fix I didn't got the error. Scenarios: - Minimal install, German, TUI, from HTTP - Minimal install, French, TUI, from Hard Disk - Default Workstation (only Gnome), English, GUI, NFS, USB Keyboard and Mouse It was dettected here: * test tree re0917.1 IA64 * test case IA64 / French / NFS / Full Workstation / GUI install Also detected here: * test tree re0924.1 * test cases IA64 / English / NFS / Everything / GUI * test cases IA64 / German / FTP / Full Server / TUI * test cases IA64 / French / NFS / Full Workstation / GUI Yes, I've got a test case that reproduces it every time now... working on narrowing down the cause. Two things to ask here: First, what reason for the fsck is being given? (e2fsck will tell you why a fsck happens, explaining for example "too many mounts since last fsck", "fsck forced because filesystem was not cleanly unmounted" or "fsck forced because of error on fs". Unclean shutdown shouldn't trigger auto-fsck for ext3, so the next question is, is the filesystem being mounted as ext3 or is it in fact ext2? This is a particularly important question since user space can specify ext3 in /etc/fstab but the kernel might still load the root fs as ext2: the root filesystem is not mounted the same way as other filesystems. "cat /proc/mounts" to find out for sure what filesystem type has been used for the root mount. I've been using ext3 on all my 7.1beta builds, and consistently get a fsck after what I feel is a clean shutdown of the machine (following the prompts after installation). [root@busted5 root]# uname -a Linux busted5 2.4.7-2smp #1 SMP Tue Aug 14 04:31:14 EDT 2001 ia64 unknown [root@busted5 root]# cat /etc/issue Red Hat Linux release 7.1.94 (Roswell) Kernel \r on an \m [root@busted5 root]# cat /proc/mounts /dev/root / ext3 rw 0 0 /proc /proc proc rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 /dev/sda1 /boot/efi vfat rw 0 0 none /dev/pts devpts rw 0 0 none /dev/shm tmpfs rw 0 0 automount(pid822) /misc autofs rw 0 0 Stephen -- the initial case I know of only happens after install because installs are mounting ext3 as ext2 during the install for some reason lost in the depths of June that I don't remember at the moment... the root fs doesn't get unmounted cleanly because something to do with Chinese font installation, still looking at it. Mike -- are you saying that you see this on *every* boot and not just the first boot after install? If so, then there maybe something else at work here. No I don't see fsck issues after every boot, just the first boot after install Workaround will be in next tree build. ... and the true bug remains a mystery. :( Except, removing the Chinese packages that cause the problem don't fix it, as something else then causes it. Wheeeeeeeee. will be fixed with kernel > 2.4.9-7.1 or later. Looks fixed with 2.4.9-7.4. If this is seen on later kernels, please reopen the bug fixed in latest releases. |