Your message dated Tue, 29 Jan 2013 20:48:06 -0600 with message-id <[email protected]> and subject line Close bug report 699212 has caused the Debian Bug report #699212, regarding initscripts: checkfs.sh halts on un-configured luks filesystem (fstab set to noauto) 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.) -- 699212: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699212 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: initscripts Version: 2.88dsf-13.1+squeeze1 Severity: important --------------------------------------------------- Note: This bug report is against Testing, not Squeeze. It is being written from a separate Squeeze installation due to other difficulties not yet resolved. Please disregard the additional system information provided by "reportbug". --------------------------------------------------- Short version: Upgraded from squeeze to testing. Machine stopped booting properly. Preliminary conclusion: checkfs.sh from initscripts package should never halt a boot due to failure to check a filesystem configured with the "noauto" option in /etc/fstab. The particulars of this case get a bit more complicated. Bear with me... Goal (Fullfilled with Squeeze, broken with testing): LUKS encryption on top of mdraid, with unattended boot into full network-enabled mode. This server is semi-headless. Grub is configured with its console on a serial port (but I also occasionally use the monitor/kbd). The disks are divided into two md-raid sets. The first is "/". The second is encrypted with LUKS. initramfs and cryptdisks have been configured to not prompt for a LUKS password at boot so that the machine can come up onto the network when booted remotely (and without operator assistance at the keyboard or serial terminal). The LUKS partition is configured in /etc/fstab to mount at /var/lib/libvirt with the "noauto" option. Once booted (and typically from within an SSH session), I run cryptdisks_start, supply a LUKS passphrase, and finally run the mount command (mount /var/lib/libvirt). With Debian testing, the behavior is this: Boot Grub A couple unimportant kernel boot messages appear Physical console has no new output, no capability to receive input (Locked up? Confusion sets in... Then, finally, realization!) Serial port has a "Ctrl+D or login" prompt to correct the failed fsck on the LUKS partition which was never opened. -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages initscripts depends on: ii coreutils 8.5-1 GNU core utilities ii debianutils 3.4 Miscellaneous utilities specific t ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii mount 2.17.2-9 Tools for mounting and manipulatin ii sysv-rc 2.88dsf-13.1+squeeze1 System-V-like runlevel change mech ii sysvinit-utils 2.88dsf-13.1+squeeze1 System-V-like utilities Versions of packages initscripts recommends: ii e2fsprogs 1.41.12-4stable1 ext2/ext3/ext4 file system utiliti ii psmisc 22.11-1 utilities that use the proc file s initscripts suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---I have dug into this a little deeper and now realize that there is already a perfectly reasonable solution to this problem. Bug report 699212 is to be withdrawn. /etc/fstab should specify both the "noauto" and "nofail" options for any device which may not exist at boot. Alternatively, one can also specify "auto" as the fstype and achieve the same behavior. References: mount(8): nofail - Do not report errors for this device if it does not exist. fsck(8): -A Walk through the /etc/fstab file and try to check all file systems in one run. <snip> fsck normally does not check whether the device actually exists before calling a file system specific checker. Therefore non-existing devices may cause the system to enter file system repair mode during boot if the filesystem specific checker returns a fatal error. The /etc/fstab mount option nofail may be used to have fsck skip non-existing devices. fsck also skips non-existing devices that have the special file system type auto
--- End Message ---
_______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel

