Bug#12122: marked as done (floppy creating problem )
Your message dated 13 Dec 1998 11:49:34 -0500
with message-id <firstname.lastname@example.org>
and subject line boot-floppies Bug closing: 'floppy creating problem'
has caused the attached bug report 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 I'm
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
(administrator, Debian bugs database)
Received: (at submit) by bugs.debian.org; 15 Aug 1997 22:47:14 +0000
Received: (qmail 21362 invoked from network); 15 Aug 1997 22:47:12 -0000
Received: from taurus.cus.cam.ac.uk (email@example.com@184.108.40.206)
by 220.127.116.11 with SMTP; 15 Aug 1997 22:47:12 -0000
Received: from gpp10 by taurus.cus.cam.ac.uk with smtp (Exim 1.654 #1)
id 0wzV9d-0000F5-00; Fri, 15 Aug 1997 23:47:37 +0100
To: Jesse Goldman <firstname.lastname@example.org>, email@example.com
Subject: Re: floppy creating problem
In-reply-to: Your message of "Fri, 15 Aug 1997 12:28:59 CDT."
Date: Fri, 15 Aug 1997 23:47:37 +0100
From: Giuliano Procida <firstname.lastname@example.org>
J. Goldman wrote to sr1-boot-floppies:
> I haven't used the boot-floppies package in ages but I need to make
> a custom rescue disk now and I'm having some problems. I recall that
> the old package, if it didn't find a diskette in the drive, would
> dump a "rescue1440.bin" type file in the /usr/src/boot-floppies
> directory which I could then dump to disk manually. Not only can't I
> get the package to do this anymore but there are a number of other
> strange errors which cause the package to crash. I've included the
> errors below. As far as I know, I've installed all the packages on
> which boot-floppies depends. Could you let me know what I'm doing
> wrong? Thanks very much..
> ioctl: LOOP_CLR_FD: No such device or address
boot-floppies needs loop support in the kernel and may also need to
check for/create a spare loop device. It should probably check the
loop features before doing anything else, failing gracefully if it
cannot continue. Perhaps even a preinst test, or is that a no-no?
If this is due to something else then that's still a bug. :-)
ps When can we expect a libc6 boot-floppies for unstable?
pps If umsdos ever gets hacked to work with the new 2.1 dcache scheme
it may become stable enough for me to have another go at a Debian
install on UMSDOS.