From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686; en-US;
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.
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.
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
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.
*** 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
* 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
Yes, it only occurs sometimes, hence why it's proving to be difficult to track
down and fix
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
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
[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.