i tried this on several machines with various floppy disks so bad cabling/drive/media can't be the reason. vmware-century ~ # fsck.ext2 /dev/fd0 e2fsck 1.39 (29-May-2006) Error determining size of the physical device: Device or resource busy vmware-century ~ # strace fsck.ext2 /dev/fd0 . . . . . munmap(0xb7f23000, 4096) = 0 open("/etc/mtab", O_RDONLY) = 3 stat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f23000 read(3, "rootfs / rootfs rw 0 0\ntmpfs / t"..., 1024) = 304 stat64("rootfs", 0xbfadf460) = -1 ENOENT (No such file or directory) stat64("tmpfs", 0xbfadf460) = -1 ENOENT (No such file or directory) stat64("192.168.178.5:/dat/chainsaw/readonly/gentoo", 0xbfadf460) = -1 ENOENT (No such file or directory) stat64("none", 0xbfadf460) = -1 ENOENT (No such file or directory) stat64("none", 0xbfadf460) = -1 ENOENT (No such file or directory) stat64("none", 0xbfadf460) = -1 ENOENT (No such file or directory) stat64("none", 0xbfadf460) = -1 ENOENT (No such file or directory) read(3, "", 1024) = 0 stat64("/", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=340, ...}) = 0 close(3) = 0 munmap(0xb7f23000, 4096) = 0 stat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0 open("/dev/fd0", O_RDONLY|O_EXCL) = 3 close(3) = 0 open("/dev/fd0", O_RDWR|O_EXCL|O_LARGEFILE) = 3 uname({sys="Linux", node="vmware-century", ...}) = 0 lseek(3, 1024, SEEK_SET) = 1024 read(3, "\270\0\0\0\240\5\0\0H\0\0\0w\5\0\0\255\0\0\0\1\0\0\0\0"..., 1024) = 1024 lseek(3, 2048, SEEK_SET) = 2048 read(3, "\3\0\0\0\4\0\0\0\5\0\0\0w\5\255\0\2\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 open("/dev/fd0", O_RDONLY|O_LARGEFILE) = -1 EBUSY (Device or resource busy) write(1, "Error determining size of the ph"..., 39Error determining size of the physical ) = 39 write(1, "device", 6device) = 6 write(1, ": ", 2: ) = 2 write(1, "Device or resource busy", 23Device or resource busy) = 23 write(1, "\n", 1 ) = 1 fsync(3) = 0 exit_group(8) = ? Process 4340 detached ##### Mounting /dev/fd0 works fine i think is is since glibc2.4 but i'm not sure Portage 2.1.1 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.15-jason-1-cs i686) ================================================================= System uname: 2.6.15-jason-1-cs i686 unknown Gentoo Base System version 1.12.5 Last Sync: Sun, 17 Sep 2006 01:00:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.2.11-r1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i586-pc-linux-gnu" CFLAGS="-O2 -march=i586 -fomit-frame-pointer -pipe" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/mail/dspam /var/bind /var/run/dspam" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=i586 -fomit-frame-pointer -pipe" DISTDIR="/var/portage/distfiles" FEATURES="autoconfig distcc distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" LANG="de_DE" LC_ALL="de_DE" LINGUAS="" MAKEOPTS="-j3" PKGDIR="/var/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 bzip2 cli crypt dlloader dri elibc_glibc fortran gd imap input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jpeg kernel_linux ldap libg++ lm_sensors mbox mysql ncurses nptl nptlonly pam pcre perl png ppds pppd readline reflection sasl session snmp spl ssl syslog tcpd tiff truetype udev unicode userland_GNU video_cards_apm video_cards_ark video_cards_ati video_cards_chips video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev video_cards_glint video_cards_i128 video_cards_i740 video_cards_i810 video_cards_imstt video_cards_mga video_cards_neomagic video_cards_nsc video_cards_nv video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa video_cards_vga video_cards_via video_cards_vmware video_cards_voodoo xml xml2 xorg zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
open("/dev/fd0", O_RDONLY|O_LARGEFILE) = -1 EBUSY (Device or resource busy) i dont really think that's a bug in e2fsprogs ... the kernel is preventing fsck from opening the device
i forget to tell that i use v1.39 of e2fsprogs
Can you use the floppy drive on this computer at all? For example, can you mount a floppy that was formatted by another computer?
Yes, I can. dd,mkfs and mount work well. Only E2fsck fails. I masked >=1.39 and e2fsck of e2fsprogs 1.38 works now again.
run 1.38 through strace ... i wonder if that version tries to open with O_LARGEFILE as well
Created attachment 97869 [details] contains the full strace of fsck 1.38 ( no error message)
1.38 does: open("/dev/fd0", O_RDONLY|O_EXCL) = 3 close(3) = 0 open("/dev/fd0", O_RDWR|O_LARGEFILE) = 3 open("/dev/fd0", O_RDONLY|O_LARGEFILE) = 4 1.39 does: open("/dev/fd0", O_RDONLY|O_EXCL) = 3 close(3) = 0 open("/dev/fd0", O_RDWR|O_EXCL|O_LARGEFILE) = 3 open("/dev/fd0", O_RDONLY|O_LARGEFILE) = -1 EBUSY (Device or resource busy)
Can you use lsof to see if anything else is accessing the floppy drive? I can't do much here as I don't have a floppy drive...
lsof tells, that nobody has openend (something from) /dev/fd0. Perhaps the hint in comment #8 from Spanky could by the solution.
unfortunately 1.38-r1 has been removed from portage some days ago :-(
Guys, this is a e2fsprogs bug because when a floppy is opened with O_EXCL it really means true exclusiveness access. So when fsck tries to opened it a second time it returns -EBUSY. There is already an open bug on the e2fsprogs bug page about the problem: http://sourceforge.net/tracker/index.php?func=detail&aid=1685391&group_id=2406&atid=102406
e2fsprogs-1.40 release notes: Fix e2fsck get_size logic so that it will work with the Linux floppy driver. The Linux floppy driver is a bit different from the other block device drivers, in that if the device has been opened with O_EXCL, it disallows another open(), even if the second open() does not have the O_EXCL flag. (Addresses Debian Bug: #410569)
