Very related to this bug report, to the point I think the problem is the same.
Assuming we use no "_netdev" option in /etc/fstab. I intentionally caused data corruption to one of my filesystems (ext4) mounted through iSCSI. The filesystem is mounted under /users at boot time, and does not contain any system-critical data. Data corruption was caused with something similar to: # dd if=/dev/zero of=/dev/itest4/users bs=512 count=3 skip=NN where NN is a couple of randomly picked blocks (e.g: 29000 and 90), and /dev/itest4/users is the logical volume (LV) where the "/users" filesystem lies. Setting the /users filesystem mount count to the maximum with "tune2fs -C" will force a fsck in next boot. So we reboot the machine (it is a virtual machine under KVM). And boot process freezes when arriving to the fsck part... and nothing can be done. No <Control+C>, no other tty's reponding. Rebooting in recovery mode from GRUB leads us to the same point: nothing can be done. So it is required to boot the system with an installation CDROM and pick "Repair a broken system". After all the required steps (connecting to iSCSI target, mounting root and executing shell) we can manually repair the corrupted /users filesystem with a fsck command. In my opinion, this (booting with an installation CDROM) shouldn't be necessary for non-critical filesystems such us "/users" (I am not talking about root or "/var"). For iSCSI imported filesystems during boot process, integrity must be checked in some way, and if errors are encountered, proper mechanisms should be provided to allow the administrator to fix the problem: entering single-user mode, etc. -- fsck in iscsi mounted filesystems is done at boot time https://bugs.launchpad.net/bugs/575715 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
