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

Re: Bad Debian/Alpha potato rescue floppy image?

On 27 Mar 2000, David Huggins-Daines wrote:

> Date: 27 Mar 2000 11:32:50 -0500
> From: David Huggins-Daines <dhd@linuxcare.com>
> To: PinkFreud <sauron@eriador.mirkwood.net>
> Cc: debian-alpha@lists.debian.org, debian-boot@lists.debian.org
> Subject: Re: Bad Debian/Alpha potato rescue floppy image?
> Adam Di Carlo <adam@onshore.com> writes:
> > >After downloading the rescue image, though, I found that it
> > >didn't appear to work.  At first, I attributed the problem to a bad
> Which one?  2.2.8?  2.2.9-pre?  Christian's old set?  We need details.
> Things are changing very fast.

Hrm.  Not sure, offhand.  This disk was downloaded from the images-1.44
directory under potato/, probably ~ 3/24.

> In fact, the new rescue disks aren't bootable by MILO at all because
> there is no space for it (this is MILO's fault for being a pig, aboot
> and APB both fit on a floppy with the kernel just fine).  You should
> be using a separate disk with MILO and linload.exe to get into MILO,
> then boot the rescue disk from there.

This box used to run RH 5.2, so it already had a dos partition with MILO
on it.  I tried both with the older MILO included with RH 5.2, and with
the copy of MILO you use on the MILO boot floppy.

Oddly enough, the alpha reported a bad image when attempting to boot the 
MILO disk included with potato - once again, this was something I was able
to read under Linux.  Hrm.

I seem to have been batting 1.000 there.

> > >Attached to this email is the new rescue image for potato (Alpha).  You
> > >should find that everything is the same - even the kernel, when
> > >uncompressed, should match the kernel on your original rescue disk.
> As noted above it's not really the same.

Well, it certainly worked for me to get the system booted.  :)

Also, there appears to be another bug in MILO where it can't read ext2
filesystems with 4k blocks.  Unfortunately, mke2fs seems to create ext2
filesystems >512 megs with 4k blocks, by default.

Stefan Reinauer <stepan@users.sourceforge.net> (current MILO 
maintainer) gave me this bit of info:

>Ruediger Oertel from SuSE wrote on this issue:

>Maybe hda1 is formatted with ext2 with 4k blocksize ? MILO can
>not read this, while current kernels can. 4k blocksize is default
>for partitions >512M since e2fsprogs-1.16 or so. You can select a
>different blocksize when formatting the partition in YaST in the
>format-expert menu (or with "-b 1024 -Onone" when using the commandline).

While this would be best fixed in MILO, where the problem lies, would it
at least be possible to implement a workaround in the installation
program?  I had to jump to a shell and create a filesystem

Whew.  Did I cover enough?  :)

Mike Edwards

Reply to: