Your message dated Tue, 29 Jan 2013 20:28:23 -0600
with message-id <[email protected]>
and subject line Close bug report
has caused the Debian Bug report #669686,
regarding checkfs.sh causes boot failure due to crypt / lvm
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.)
--
669686: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669686
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: initscripts
Version: 2.88dsf-13.1
Hi,
I just had a tough upgrade to squeeze. checkfs is failing and bombing
out on boot.
The reason appears to be related to the ordering of the initscripts
related to cryptdisks, lvm2, and mount.
In my configuration, root is an encrypted disk broken up into lvm2
volumes. This raid volume is unlocked by user password entry on boot.
This machine has several other encrypted disks; the keys to each of
these is found on the filesystem of one of the root array's disks.
In short, whereas the current init setup fires:
checkroot > cryptdisks-early > lvm2 > cryptdisks > checkfs > mount
My configuration would require
cryptdisks-early > lvm2 > checkroot > mountroot > cryptdisks > lvm2 >
checkfs > mount
In Etch and Lenny I didn't have any issues which is partly why I'm a
little confused. Is there anything that can be done to make this part of
boot less brittle?
Has a special runlevel for block devices should be created that runs
commands like these (and mdadm) in a loop, collecting the results of
each run, until nothing has changed before continuing and running a
checkfs that fails been discussed?
-BK
--- 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
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
