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
manually.
Whew. Did I cover enough? :)
Mike Edwards
PinkFreud
Reply to: