[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#603944: marked as done (retry mounting of root)

Your message dated Sat, 16 Apr 2016 23:26:53 +0100
with message-id <1460845613.3814.12.camel@decadent.org.uk>
and subject line Re: Updated patch
has caused the Debian Bug report #603944,
regarding retry mounting of root
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 owner@bugs.debian.org
immediately.)


-- 
603944: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603944
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: initramfs-tools
Version: 0.98

When using multipath, it is possible that mountroot() will race with
udev's renaming of /dev/disk/by-uuid/{rootfs-uuid} from /dev/sd?? to
/dev/mapper/something.  After multipath has grabbed the /dev/sd?? and
until udev completes the rename, mounting
/dev/disk/by-uuid/{rootfs-uuid} will fail with -EBUSY.

Here is a patch I've been using successfully for awhile.  Colin Watson
has suggested that:

> A poll/retry loop is generally a suboptimal way to do this kind of
> thing; what we really want is to wait for udev to tell us that it has
> finished with the event that triggered renaming of the device.

which does seem cleaner.

thanks,
-serge

diff -Nru initramfs-tools-0.98ubuntu2/debian/changelog initramfs-tools-0.98ubuntu3/debian/changelog
--- initramfs-tools-0.98ubuntu2/debian/changelog	2010-08-20 03:48:58.000000000 -0500
+++ initramfs-tools-0.98ubuntu3/debian/changelog	2010-08-24 22:31:31.000000000 -0500
@@ -1,3 +1,14 @@
+initramfs-tools (0.98ubuntu3) maverick; urgency=low
+
+  * Add retries to mountroot().  This is particularly needed when we
+    use multipath, because it is possible that mountroot() will race
+    with udev's renaming of /dev/disk/by-uuid/{rootfs-uuid} from
+    /dev/sd?? to /dev/mapper/something.  After multipath has grabbed
+    the /dev/sd?? and until udev completes the rename, mounting
+    /dev/disk/by-uuid/{rootfs-uuid} will fail with -EBUSY.
+
+ -- Serge Hallyn <serge.hallyn@canonical.com>  Tue, 24 Aug 2010 22:17:57 -0500
+
 initramfs-tools (0.98ubuntu2) maverick; urgency=low
 
   * The ramzswap device changed its interface so that the disk size needs to
diff -Nru initramfs-tools-0.98ubuntu2/scripts/local initramfs-tools-0.98ubuntu3/scripts/local
--- initramfs-tools-0.98ubuntu2/scripts/local	2010-08-20 03:48:58.000000000 -0500
+++ initramfs-tools-0.98ubuntu3/scripts/local	2010-08-24 22:16:17.000000000 -0500
@@ -86,10 +86,19 @@
 	# FIXME This has no error checking
 	[ -n "${FSTYPE}" ] && modprobe ${FSTYPE}
 
-	# FIXME This has no error checking
 	# Mount root
-	mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
-	mountroot_status="$?"
+	tries=0
+	ret=1
+	while [ $tries -lt 10 -a $ret -ne 0 ]; do
+		mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
+		ret=$?
+		if [ $ret -ne 0 ]; then
+			echo "failed attempt $tries to mount $ROOT as root"
+			sleep 1
+			tries=$((tries+1))
+		fi
+	done
+	mountroot_status=$ret
 	if [ "$LOOP" ]; then
 		if [ "$mountroot_status" != 0 ]; then
 			if [ ${FSTYPE} = ntfs ] || [ ${FSTYPE} = vfat ]; then

--- End Message ---
--- Begin Message --- 
On Mon, 2016-01-25 at 15:01 +0000, Ben Hutchings wrote:
> On Wed, 2015-12-09 at 20:35 +0000, Ben Hutchings wrote:
[...]
> > (Bear in mind that I have no experience of using multipath.)
> > 
> > If one path shows up quickly and the other rather later, can't we still
> > end up mounting the single-path device rather than the multipath
> > device?  How do we tell when multipath discovery is complete?
> > 
> > Does it even make sense to specify a multipath device by UUID rather
> > than by its device-mapper name?  This certainly isn't supported for
> > LVM.
> You need to answer these questions, otherwise I'm just going to close
> this bug.

Closing due to lack of response.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: