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

Bug#46533: Let's make non-syslinux rescue floppies available, too.



On 3 Oct 1999, Adam Di Carlo wrote:

> > I suspect these problems have nothing to do with "syslinux" and everything
> > to do with quirky BIOS drivers. In any case, supplying alternative rescue
> > floppies may benefit some people who are bringing up Debian for the first
> > time. It's possible they don't have access to another system running Linux,
> > so they can't be expected to cook their own rescue floppy.
> 
> Ganesh, I completely agree with your diagnosis.  There are really
> quite a lot of people who are able to boot with SUSE or RedHat but for
> some reason can't boot with our stuff (generally hanging when it tries
> to load root.bin, or right at the front when it loads the kernel).
 
> I find these problems impossible to diagnose, etc.  It's strictly an
> i386 problem, too.

I had one of these last night with the slink boot floppies. The hardware
deteriorated as we experimented, so I got no useful data, but it certainly
fared better with Slackware boot disks and the RedHat installer, and with
direct kernel (no syslx or lilo).
 
> So if someone is able to hack the rescue disk creation and the top
> level makefile so we generate two "flavors" of rescue disk images (one
> for mkroot, one for syslinux as we do now), then I'd be very pleased
> and Debian users would be too.
 
> Anyone have other thoughts?  Volunteers?

I'll have a look into this; my fast network access has just been restored
after an annoying absence, but I have now secured a dual Celeron 500Mhz
thing to build i386 on. One of the infuriating things about the Makefile
is that it does

foo:
	$(MAKE) bar
	$(MAKE) baz

where it seems as though

foo:	bar baz

would not break make -j (by forcing make baz to wait for make bar), or -n
($(MAKE) explicitly ignores -n by "design"). So I'll fix that too.

I assume that for the time being we want to produce both types of images.

Mk


Reply to: