Re: SV: loop: can't get info on device
#include * Eduard Bloch [Fri, Feb 21 2003, 10:20:45AM]: > > Yes, don't try extracting the kernel more than 7 times (assuming > > del_loop doesn't get called appropriately) ;-) > > Heh? IIRC this is dead code, I replaced loop-device operations with > direct losetup calls during the Woody freeze because of unexplainable > problems with our functions. Err, forget it. Gruss/Regards, Eduard. -- Letzte Worte eines Rennfahrers: "Ob der Mechaniker weiß, daß ich was mit seiner Freundin habe?" msg26008/pgp0.pgp Description: PGP signature
Re: SV: loop: can't get info on device
#include * Emile van Bergen [Fri, Feb 21 2003, 09:47:25AM]: > > I found a spot in boot-floppies where this could happen, and added a > > check. I think this will have to wait for r3 though. Do you see any > > possible workarounds in the find_unused_loop_device() code in > > losetup.c? > > Yes, don't try extracting the kernel more than 7 times (assuming > del_loop doesn't get called appropriately) ;-) Heh? IIRC this is dead code, I replaced loop-device operations with direct losetup calls during the Woody freeze because of unexplainable problems with our functions. Gruss/Regards, Eduard. -- Mit Kirch und Thoma geht's ins Medienkoma! -- Jörg Prante <[EMAIL PROTECTED]> msg26007/pgp0.pgp Description: PGP signature
Re: SV: loop: can't get info on device
(sorry)
On Fri, Feb 21, 2003 at 09:47:25AM +0100, Emile van Bergen wrote:
> I suspect with that things go wrong earlier, causing get_device() in
> extract_kernel.c to be called with an empty (non-null) image parameter.
It seems this can happen in extract_kernel.c, choose_and_install(), if
both Archive_dir and kernel_image_path are empty (""). Checked
concat_path() and this will indeed return an empty string in that case.
I have no idea where these variables are set up though.
Cheers,
Emile.
--
E-Advies / Emile van Bergen | [EMAIL PROTECTED]
tel. +31 (0)70 3906153| http://www.e-advies.info
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SV: loop: can't get info on device
Hi, On Thu, Feb 20, 2003 at 07:28:42PM -0700, Chris Tillman wrote: > I found a spot in boot-floppies where this could happen, and added a > check. I think this will have to wait for r3 though. Do you see any > possible workarounds in the find_unused_loop_device() code in > losetup.c? Yes, don't try extracting the kernel more than 7 times (assuming del_loop doesn't get called appropriately) ;-) I don't think the (needed) fix cures this particular problem though. If device would be null then losetup would be called as 'losetup (null) image' because of the sprintf in losetup.c, and then you wouldn't get the message as observed, but rather (null): No such file or directory Or is there a custom sprintf() being used? I suspect with that things go wrong earlier, causing get_device() in extract_kernel.c to be called with an empty (non-null) image parameter. Too bad ViewCVS doesn't do xrefs ;-). I don't have the full source here, so can't grep at the moment. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info msg26005/pgp0.pgp Description: PGP signature
Re: SV: loop: can't get info on device
On Thu, Feb 20, 2003 at 08:47:25AM +0100, Emile van Bergen wrote:
> Hi,
>
> On Thu, Feb 20, 2003 at 08:25:20AM +0100, Åke Wivänge wrote:
>
> > > That device is normally on the root.bin filesystem. Maybe
> > > it got deleted or hidden somehow? You should see many devices
> > > in /dev, including loop0-7.
> >
> > It's already there, and "makedeving" it again has no effect.
>
> I noticed that you can also get this message if the device node is
> there, and loop support has been compiled in the kernel, but you happen
> to call losetup /dev/loop0 without further arguments (and /dev/loop0
> isn't already set up).
>
> If that's the case, it would seem a script on the boot image you're
> using is broken. How do you boot? Directly from CD or from floppy?
> How did you obtain/create the floppies?
Good clue. I found a spot in boot-floppies where this could happen,
and added a check. I think this will have to wait for r3 though. Do
you see any possible workarounds in the find_unused_loop_device() code
in losetup.c?
Index: extract_kernel.c
===
RCS file: /cvs/debian-boot/boot-floppies/utilities/dbootstrap/extract_kernel.c,v
retrieving revision 1.61
diff -u -r1.61 extract_kernel.c
--- extract_kernel.c12 Aug 2002 15:32:30 - 1.61
+++ extract_kernel.c21 Feb 2003 02:25:06 -
@@ -62,6 +62,10 @@
else {
int ro = 1;
device = find_unused_loop_device();
+if (device == NULL) {
+ ERRMSG("set_loop couldn't find an unused loop device for %s", prtbuf);
+ return NULL;
+}
if (set_loop(device, diskimage, 0, &ro)) {
ERRMSG("set_loop couldn't create a loop device for %s", prtbuf);
return NULL;
--
"The way the Romans made sure their bridges worked is what
we should do with software engineers. They put the designer
under the bridge, and then they marched over it."
-- Lawrence Bernstein, Discover, Feb 2003
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SV: loop: can't get info on device
Hi, On Thu, Feb 20, 2003 at 08:25:20AM +0100, Åke Wivänge wrote: > > That device is normally on the root.bin filesystem. Maybe > > it got deleted or hidden somehow? You should see many devices > > in /dev, including loop0-7. > > It's already there, and "makedeving" it again has no effect. I noticed that you can also get this message if the device node is there, and loop support has been compiled in the kernel, but you happen to call losetup /dev/loop0 without further arguments (and /dev/loop0 isn't already set up). If that's the case, it would seem a script on the boot image you're using is broken. How do you boot? Directly from CD or from floppy? How did you obtain/create the floppies? Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
