Description of Problem:
fsck.minix hangs on s390.
Version-Release number of selected component (if applicable):
Linux version 2.4.9-9.1 (firstname.lastname@example.org) (gcc version 2.95.3
20010315 (release)) #1 SMP Wed Oct 31 15:33:39 CET 2001
Steps to Reproduce:
1. dd if=/dev/zero of=/tmp/minix.img bs=1M count=10
2. mkfs.minix /tmp/minix.img
(3. mount /tmp/minix.img. copy a couple of files. unmount. <-- just did
this to verify the functionality of the minix.img, though it is not a
necessary step to recreate the failure)
4. fsck.minix -lavsmf /tmp/minix.img
Expected Results:Forcing filesystem check on /tmp/minix.img.
(these are the results from repeating the steps on i686)
2 0100644 1 /sanity
3 0100755 1 /sanity_color
4 0100644 1 /sanity.kdeadmin
5 0100644 1 /sanity.man-pages
6 0100644 1 /sanity.mpage
6 inodes used (0%)
146 zones used (1%)
5 regular files
0 character device files
0 block device files
0 symbolic links
The process can't be interrupted w/ <^-C> or w/ kill -9 <pid>.
Created attachment 37302 [details]
fsck.minix strace-interrupted by killing ssh session (after 5+ minutes)
Since it's hanging in a sync() call, it looks suspiciously like a kernel
problem. Any ideas, Arjan?
does the same happen with fsck.ext2 ?
maybe kupdated died again...
will try fsck.ext2 once the s/390 is back online.
didn't mean to change to assigned...
switching back to NEEDINFO
removed s/390 minix support in newest util-linux, but fsck.ext2 needs to be
I've never seen a problem w/ fsck.ext2 / e2fsck.
Exact steps followed in original report for ext2 - no problems. Creating and
checking ext fs's has been one of the things tested very regularly. No
problems are known. Closing.