This bug/deficiency has a trivial solution, in my
view at least. Is there some reason the attached patch
should not be applied to the upstream original? There
is indeed a minute risk that the timing inside the
shell between the actions
# temp_loop=$(losetup -f)
# losetup $lo_options $temp_loop $image
might be intercepted by another system request, but
compared to the risk of fixating the script to always
use /dev/loop1, this must be a lesser hazard.
It seems, implicitly, that Pierre Pronchery did what
I often do, keep a handful loop-devices. Luckily, I
have never tried to use mkbimage at such occations.
Best regards
Mats Erik Andersson
[EMAIL PROTECTED]# dev-loop_indep_mkbimage.diff
#
# The dependency of a loop-device is made dynamic,
# instead of statically using /dev/loop1.
#
diff -Naur grub-0.97.orig/util/mkbimage grub-0.97.patched/util/mkbimage
--- grub-0.97.orig/util/mkbimage 2004-07-24 20:57:31.000000000 +0200
+++ grub-0.97.patched/util/mkbimage 2006-10-06 12:57:21.609356256 +0200
@@ -149,9 +149,10 @@
if [ "$offset" = "0" ] ; then
mkfs.$fs -F $image
elif [ `id -u` = "0" ] ; then
- losetup $lo_options /dev/loop1 $image
- mkfs.$fs /dev/loop1
- losetup -d /dev/loop1
+ temp_loop=$(losetup -f)
+ losetup $lo_options $temp_loop $image
+ mkfs.$fs $temp_loop
+ losetup -d $temp_loop
else
error must_be_root
fi
@@ -185,13 +186,14 @@
$cp ${image}1/$file ${image}:$file
done
elif [ "`id -u`" = "0" ] ; then
- losetup $lo_options /dev/loop1 $image
+ temp_loop=$(losetup -f)
+ losetup $lo_options $temp_loop $image
mkdir ${image}.mnt
- mount -t $fs /dev/loop1 ${image}.mnt
+ mount -t $fs $temp_loop ${image}.mnt
cp -a ${image}1/* ${image}.mnt/ && sync
umount ${image}.mnt
rmdir ${image}.mnt
- losetup -d /dev/loop1
+ losetup -d $temp_loop
else
error must_be_root
fi
