Bug 51208 - fsck occurs on ext3 '/' partition after install
Summary: fsck occurs on ext3 '/' partition after install
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: anaconda
Version: roswell
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brock Organ
: 50472 51004 52445 53519 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-08 14:37 UTC by Mike Sklar
Modified: 2007-04-18 16:35 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2001-10-17 03:25:32 UTC

Attachments (Terms of Use)

Description Mike Sklar 2001-08-08 14:37:16 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686; en-US;
0.7) Gecko/20010316

Description of problem:
After a installation of roswell and a clean shutdown of the machine
initiated by the installer, the following boot of the operating system on
my ia64s does a fsck of the '/' filesystem.

How reproducible:

Steps to Reproduce:
1.Install roswell on a ia64
2.boot the freshly installed OS
3.should see fsck occur on root filesystem

Actual Results:  fsck occurs

Expected Results:  a clean installation and shutdown would hopefull result
in no fsck having to be done.

Additional info:

Comment 1 Jeremy Katz 2001-08-14 00:44:55 UTC
Have you seen this on any ia32 machines?

Comment 2 Mike Sklar 2001-08-14 18:30:17 UTC
No, just on ia64. The few ia32 machines I've installed on have booted fine.

Comment 3 Benjamin Franz 2001-08-17 22:15:28 UTC
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.


Comment 4 Jeremy Katz 2001-08-23 20:48:24 UTC
*** Bug 52445 has been marked as a duplicate of this bug. ***

Comment 5 Glen Foster 2001-08-23 21:49:13 UTC
We (Red Hat) really need to fix this before next release.

Comment 6 Bill Nottingham 2001-08-24 02:24:34 UTC
*** Bug 50472 has been marked as a duplicate of this bug. ***

Comment 7 Bill Nottingham 2001-08-24 02:27:25 UTC
*** Bug 51004 has been marked as a duplicate of this bug. ***

Comment 8 Jeremy Katz 2001-09-10 19:58:21 UTC
*** Bug 53519 has been marked as a duplicate of this bug. ***

Comment 9 Michael A. McLean 2001-09-10 20:41:14 UTC
This is happening with re0908.2-ia64

Comment 10 Michael A. McLean 2001-09-11 16:02:15 UTC
* 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.

Comment 11 Michael A. McLean 2001-09-11 17:07:03 UTC
Oddly enough, this did *not* happen with a German HTTP Minimal install of

Comment 12 Jeremy Katz 2001-09-11 17:15:21 UTC
Yes, it only occurs sometimes, hence why it's proving to be difficult to track
down and fix

Comment 13 Josep Guallar-Esteve 2001-09-12 19:35:20 UTC
I didn't got the error.


- Minimal install, German, TUI, from HTTP
- Minimal install, French, TUI, from Hard Disk
- Default Workstation (only Gnome), English, GUI, NFS, USB Keyboard and Mouse

Comment 14 Josep Guallar-Esteve 2001-09-17 20:11:29 UTC
It was dettected here:

* test tree re0917.1 IA64
* test case IA64 / French / NFS / Full Workstation / GUI install

Comment 15 Josep Guallar-Esteve 2001-09-25 13:52:39 UTC
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

Comment 16 Jeremy Katz 2001-09-25 13:54:30 UTC
Yes, I've got a test case that reproduces it every time now...  working on
narrowing down the cause.

Comment 17 Stephen Tweedie 2001-10-02 16:52:06 UTC
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.

Comment 18 Mike Sklar 2001-10-02 16:56:20 UTC
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

[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

Comment 19 Jeremy Katz 2001-10-02 18:21:56 UTC
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.

Comment 20 Mike Sklar 2001-10-02 18:24:54 UTC
No I don't see fsck issues after every boot, just the first boot after install

Comment 21 Bill Nottingham 2001-10-12 02:29:43 UTC
Workaround will be in next tree build.

Comment 22 Bill Nottingham 2001-10-12 02:30:19 UTC
... and the true bug remains a mystery. :(

Comment 23 Bill Nottingham 2001-10-13 02:09:31 UTC
Except, removing the Chinese packages that cause the problem don't fix it, as
something else then causes it. Wheeeeeeeee.

Comment 24 Bill Nottingham 2001-10-19 15:37:54 UTC
will be fixed with kernel > 2.4.9-7.1 or later.

Comment 25 Jeremy Katz 2001-10-24 19:21:20 UTC
Looks fixed with 2.4.9-7.4.  If this is seen on later kernels, please reopen the bug

Comment 26 Bryan Leopard 2001-11-14 21:28:01 UTC
fixed in latest releases.

Note You need to log in before you can comment on or make changes to this bug.