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

Reply via email to