Your message dated Sat, 21 Nov 2009 19:46:12 -0500 with message-id <[email protected]> and subject line Re: Bug#557382: e2fsprogs: Throws endless list of errors when booting off read-only image has caused the Debian Bug report #557382, regarding e2fsprogs: Throws endless list of errors when booting off read-only image to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 557382: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557382 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: e2fsprogs Version: 1.41.8-1 Severity: normal I'm using qemu -hda <foo.img> to boot a debootstrapped Debian installation which is contained in an ext3 partition in the image file. Everything works fine when the file is chmod 6xx. However, an idea I had was setting it to 4xx to check for any accidental writes which would be impossible later on in case of converting the ext3 image into an ISO image for a live medium with only few controlled copy-on-write sections through aufs. The boot process then only reaches the end of the initramfs. When the boot process attempts to check the root file system, an unpleasant and (pseudo-)endless series of errors are thrown, effectively locking up the boot sequence: hda: task_pio_intr: status=0x41 { DriveReady Error } hda: task_pio_intr: error=0x04 { DriveStatusError } hda: possibly failed opcode: 0x39 I've seen those before, presumably on real broken hardware, and would intuitively expect something less worrysome in the situation mentioned above. Perhaps just a warning that the fsck cannot be run because it would need to write back some mount information as I would assume. As this bug is somehow the result of interaction between initscripts, fsck.ext3 and qemu, the reason might well be something else than what I think it is, but nevertheless it took me a while to figure out the causation and hence would call it a bug in fsck.ext3. The fstab file is empty in case this matters, the root device is indicated to the initramfs through an ext3 UUID kernel option. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages e2fsprogs depends on: ii e2fslibs 1.41.8-1 ext2/ext3/ext4 file system librari ii libblkid1 2.16.1-4 block device id library ii libc6 2.9-24 GNU C Library: Shared libraries ii libcomerr2 1.40.8-2 common error description library ii libss2 1.40.8-2 command-line interface parsing lib ii libuuid1 2.16.1-2 Universally Unique ID library e2fsprogs recommends no packages. -- no debconf information
--- End Message ---
--- Begin Message ---On Sat, Nov 21, 2009 at 08:21:52PM +0100, Josef Spillner wrote: > Package: e2fsprogs > Version: 1.41.8-1 > Severity: normal > > The boot process then only reaches the end of the initramfs. When the boot > process > attempts to check the root file system, an unpleasant and (pseudo-)endless > series > of errors are thrown, effectively locking up the boot sequence: > > hda: task_pio_intr: status=0x41 { DriveReady Error } > hda: task_pio_intr: error=0x04 { DriveStatusError } > hda: possibly failed opcode: 0x39 These messages come from the kernel running under qemu, because qemu is simulating errors from writing to the (read-only) disk. That's how it's reflecting the errors back to guest OS. There's absolutely nothing e2fsck can do about this, and no way for e2fsck to know that you have rudely made the disk read-only. So there's not much I can do in fsck.ext3 to fix this, sorry. - Ted
--- End Message ---
