Hi all :))
A time ago I was able to generate bootable Linux CD's just by
dd'ing a floppy containing a raw kernel image:
dd if=/dev/fd0 of=eltorito
After that, mkisofsing, toasting and booting. But now, depending
on the machine, I have 'invalid compressed format' errors, or even
ye olde register dump when the image was damaged :(
Booting directly from the floppy works, but booting with that
same image from a CD does not :(( I now I can use LILO, or better
yet, Syslinux or isolinux, but I'm just curious why I cannot boot raw
image-based CD's anymore.
Anyone knows what's happenning here?
Ra?l
On 29 November 2002 11:21, DervishD wrote:
> Hi all :))
>
> A time ago I was able to generate bootable Linux CD's just by
> dd'ing a floppy containing a raw kernel image:
>
> dd if=/dev/fd0 of=eltorito
>
> After that, mkisofsing, toasting and booting. But now, depending
> on the machine, ^^^^^^^^^
^^^^^^^^^^^^^^
Boot CD support is BIOS-dependent AFAIK. Maybe on those machines BIOS
floppy emulation from CD is broken?
OTOH if you can boot, say, 2.2 but not 2.4, that's a counterproof
for my theory.
> I have 'invalid compressed format' errors, or even
> ye olde register dump when the image was damaged :(
>
> Booting directly from the floppy works, but booting with that
> same image from a CD does not :(( I now I can use LILO, or better
> yet, Syslinux or isolinux, but I'm just curious why I cannot boot raw
> image-based CD's anymore.
--
vda
DervishD wrote:
>
> Hi all :))
>
> A time ago I was able to generate bootable Linux CD's just by
> dd'ing a floppy containing a raw kernel image:
>
> dd if=/dev/fd0 of=eltorito
>
> After that, mkisofsing, toasting and booting. But now, depending
> on the machine, I have 'invalid compressed format' errors, or even
> ye olde register dump when the image was damaged :(
>
> Booting directly from the floppy works, but booting with that
> same image from a CD does not :(( I now I can use LILO, or better
> yet, Syslinux or isolinux, but I'm just curious why I cannot boot raw
> image-based CD's anymore.
>
> Anyone knows what's happenning here?
I had this problem a while ago. It turned out to be a (widespread)
BIOS bug triggered be the disk-size probe of the kernel's boot loader.
The crude fix which worked for me: disable the probing for 2.88MB disks
by changing the first byte of the disksizes table at the end of bootsect.S
from 36 to 18.
The long explanation: The BIOS allows bigger-than-track-size reads
in El-Torito mode which confuses the probe routine which then assumes
a 2.88MB disk when the BIOS is actually emulating a 1.44MB disk.
In LBA mode that would be no problem but in CHS mode (which is used
by the loader) it does not work.
Ciao, ET.
Hi Denis :)
> > After that, mkisofsing, toasting and booting. But now, depending
> > on the machine, ^^^^^^^^^
> ^^^^^^^^^^^^^^
> Boot CD support is BIOS-dependent AFAIK. Maybe on those machines BIOS
> floppy emulation from CD is broken?
Not at all. I can boot using isolinux (or syslinux), for example.
The failure happens in all machines I've tested, but depending on the
machine, the particular fail is one or another: some of them
generate 'invalid compressed format', others just hang, etc...
But booting the same kernel using isolinux works :( That is, it
is not a mkisofs issue, nor a cdrecord issue, etc...
Thanks for your answer, Denis :)
Ra?l
Hi Edgar :)
> > Anyone knows what's happenning here?
> The long explanation: The BIOS allows bigger-than-track-size reads
> in El-Torito mode which confuses the probe routine which then assumes
> a 2.88MB disk when the BIOS is actually emulating a 1.44MB disk.
> In LBA mode that would be no problem but in CHS mode (which is used
> by the loader) it does not work.
I've tried too with a home-made boot loader which works in LBA
mode (I use it in my system and works OK) using a no-emulation boot
CD, but then the kernel is not even loaded :(
Thanks for the explanation :)) Why this did work on older kernels
but not on 2.4.x :????
Anyway, I think I will use a patched version of Isolinux. Less
complications and more power than a raw disk image :(
Ra?l
Followup to: <[email protected]>
By author: Edgar Toernig <[email protected]>
In newsgroup: linux.dev.kernel
>
> I had this problem a while ago. It turned out to be a (widespread)
> BIOS bug triggered be the disk-size probe of the kernel's boot loader.
>
It's not a bug, really. The fact of the matter is that the disk
geometry probe in bootsect.S pretty much only works for legacy
floppies... no IDE floppies, no USB floppies, no virtual floppies.
That, and the 1 MB limitation, is the reason it either needs to get
nuked or get some massive surgery. I am currently trying to get Linus
to accept a patch to put it out of its misery.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
H. Peter Anvin writes:
> Followup to: <[email protected]>
> By author: Edgar Toernig <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > I had this problem a while ago. It turned out to be a (widespread)
> > BIOS bug triggered be the disk-size probe of the kernel's boot loader.
> >
>
> It's not a bug, really. The fact of the matter is that the disk
> geometry probe in bootsect.S pretty much only works for legacy
> floppies... no IDE floppies, no USB floppies, no virtual floppies.
>
> That, and the 1 MB limitation, is the reason it either needs to get
> nuked or get some massive surgery. I am currently trying to get Linus
> to accept a patch to put it out of its misery.
FWIW, I still use bzdisk images frequently, and the 1MB limit really
is a serious problem for 2.5 kernels, and 2.4 kernels build with gcc-3.
I'm currently using a patched kernel where `make bzdisk' invokes a
user-specified script, which in my case goes roughly like:
===snip===
BOOTIMAGE=$1
LIBDIR=/home/mikpe/pkgs/linux-x86/make-zdisk/lib
FDIMAGE=/tmp/fdimage.$$
MTOOLSRC=/tmp/mtools.conf.$$
cat > $MTOOLSRC << EOF
drive v:
file="$FDIMAGE" cylinders=80 heads=2 sectors=18 filter
EOF
dd if=/dev/zero bs=72k count=20 of=$FDIMAGE
MTOOLSRC=$MTOOLSRC mformat v:
MTOOLSRC=$MTOOLSRC mcopy $LIBDIR/ldlinux.sys v:
MTOOLSRC=$MTOOLSRC mcopy $BOOTIMAGE v:linux
dd bs=512 count=1 conv=notrunc if=$LIBDIR/bootsect.img of=$FDIMAGE
dd bs=72k if=$FDIMAGE of=/dev/fd0
===snip===
The latest mtools are supposed to have direct support for image files,
which should eliminate the MTOOLSRC kludge.
All I'm really missing is a version of syslinux that understands enough
of MS-DOS FS layout to populate the FS and update the boot block without
having to mount the damn thing. That would eliminate the ldlinux.sys and
bootsect.img files, which I extracted from a syslinux-prepared floppy.
You can kill bootsect.S right now, IF you allow a user-specified script
to control how the boot floppy is prepared. Something like:
zdisk: $(BOOTIMAGE)
make-zdisk.sh $(BOOTIMAGE)
should be enough.
/Mikael
Mikael Pettersson wrote:
>
> FWIW, I still use bzdisk images frequently, and the 1MB limit really
> is a serious problem for 2.5 kernels, and 2.4 kernels build with gcc-3.
> I'm currently using a patched kernel where `make bzdisk' invokes a
> user-specified script, which in my case goes roughly like:
>
If you get my nobootsect patch:
ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/nobootsect-2.5.63-bk7-1.diff
... you will find something similar, but a bit more fleshed out.
This is the patch I'm trying to get Linus to accept.
-hpa
H. Peter Anvin writes:
> Mikael Pettersson wrote:
> >
> > FWIW, I still use bzdisk images frequently, and the 1MB limit really
> > is a serious problem for 2.5 kernels, and 2.4 kernels build with gcc-3.
> > I'm currently using a patched kernel where `make bzdisk' invokes a
> > user-specified script, which in my case goes roughly like:
> >
>
> If you get my nobootsect patch:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/nobootsect-2.5.63-bk7-1.diff
>
> ... you will find something similar, but a bit more fleshed out.
>
> This is the patch I'm trying to get Linus to accept.
That's similar to what you posted to LKML a while ago, and
it has the limitations of requiring mountable /dev/fd0, which
needs a magic entry in /etc/fstab ("user" privs, not "owner"),
and MS-DOS FS support in the kernel used for the build.
Those are the limitations I want to avoid. Do put this in a script
in the kernel, but please allow the user to override it via $PATH.
/Mikael
Mikael Pettersson wrote:
> >
> > This is the patch I'm trying to get Linus to accept.
>
> That's similar to what you posted to LKML a while ago, and
> it has the limitations of requiring mountable /dev/fd0, which
> needs a magic entry in /etc/fstab ("user" privs, not "owner"),
> and MS-DOS FS support in the kernel used for the build.
>
No, it doesn't (if you have SYSLINUX 2.02 or higher.)
-hpa
H. Peter Anvin writes:
> Mikael Pettersson wrote:
> > >
> > > This is the patch I'm trying to get Linus to accept.
> >
> > That's similar to what you posted to LKML a while ago, and
> > it has the limitations of requiring mountable /dev/fd0, which
> > needs a magic entry in /etc/fstab ("user" privs, not "owner"),
> > and MS-DOS FS support in the kernel used for the build.
> >
>
> No, it doesn't (if you have SYSLINUX 2.02 or higher.)
Cool. The one in RedHat 8 must be pretty old then.
I'll grab the latest and give it a try.
/Mikael
Hi Peter :)
H. Peter Anvin dixit:
> That, and the 1 MB limitation, is the reason it either needs to get
> nuked or get some massive surgery. I am currently trying to get Linus
> to accept a patch to put it out of its misery.
Please, try to convince Marcello and Alan, too. The 2.4 branch
will be a happier branch (well, assuming that the Linux kernel has
feelings, of course) without the raw kernel image booting. Anyway, it
doesn't seem to work for El Torito emulated floppies... I will be the
first who cry for this ancient code, but I think now it doesn't make
sense. Anyone uses floppies yet? Here in Spain a floppy is more
expensive than a 80 min. CD...
Ra?l
> > That, and the 1 MB limitation, is the reason it either needs to get
> > nuked or get some massive surgery. I am currently trying to get
> > Linus to accept a patch to put it out of its misery.
>
> Please, try to convince Marcello and Alan, too. The 2.4 branch
> will be a happier branch (well, assuming that the Linux kernel has
> feelings, of course) without the raw kernel image booting. Anyway, it
> doesn't seem to work for El Torito emulated floppies... I will be the
> first who cry for this ancient code, but I think now it doesn't make
> sense. Anyone uses floppies yet? Here in Spain a floppy is more
> expensive than a 80 min. CD...
Doesn't the in kernel bootloader have uses other than booting from
floppy? What if you want to boot from a custom network boot prom?
John.
DervishD wrote:
> Hi Peter :)
>
> H. Peter Anvin dixit:
>
>>That, and the 1 MB limitation, is the reason it either needs to get
>>nuked or get some massive surgery. I am currently trying to get Linus
>>to accept a patch to put it out of its misery.
>
> Please, try to convince Marcello and Alan, too. The 2.4 branch
> will be a happier branch (well, assuming that the Linux kernel has
> feelings, of course) without the raw kernel image booting. Anyway, it
> doesn't seem to work for El Torito emulated floppies... I will be the
> first who cry for this ancient code, but I think now it doesn't make
> sense. Anyone uses floppies yet? Here in Spain a floppy is more
> expensive than a 80 min. CD...
>
It doesn't work for anything but old legacy floppies. I have already
sent the code to Alan for 2.5-ac and to Andi for x86-64 (where it has
already been integrated); if anyone wants to try to persuade Marcelo to
integrate it, be my guest, the current patch is at:
ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/nobootsect-2.5.63-bk7-1.diff
It's already enough work to keep this patch up to date and trying to get
Linus to take it.
-hpa
John Bradford wrote:
>
> Doesn't the in kernel bootloader have uses other than booting from
> floppy? What if you want to boot from a custom network boot prom?
>
Then you probably need Etherboot. The in-kernel boot loader
(bootsect.S) will not help you.
-hpa
> > Doesn't the in kernel bootloader have uses other than booting from
> > floppy? What if you want to boot from a custom network boot prom?
> >
>
> Then you probably need Etherboot. The in-kernel boot loader
> (bootsect.S) will not help you.
Sorry, I was thinking about something completely different :-).
John.
Hi John :)
John Bradford dixit:
> > sense. Anyone uses floppies yet? Here in Spain a floppy is more
> > expensive than a 80 min. CD...
> Doesn't the in kernel bootloader have uses other than booting from
> floppy? What if you want to boot from a custom network boot prom?
I'm not aware of such uses :??? AFAIK, the in kernel bootloader
just exists for booting from raw floppies :?? Maybe HPA knows more
about this.
Ra?l
Hi Peter :)
H. Peter Anvin dixit:
> > Please, try to convince Marcello and Alan, too. The 2.4 branch
> > will be a happier branch (well, assuming that the Linux kernel has
> sent the code to Alan for 2.5-ac and to Andi for x86-64 (where it has
> already been integrated); if anyone wants to try to persuade Marcelo to
> integrate it, be my guest
If you want, I can prepare a patch for the 2.4 series, but if I
have had problems for a three-line diff to be included, think about
yours... If you think that Marcello will be inclined to accept this
patch I'll prepare it in your name.
> It's already enough work to keep this patch up to date and trying to get
> Linus to take it.
I suppose. But I think it won't do any harm :?? so it should be
accepted. The only think it does is to eliminate some bloat from the
kernel...
Ra?l
Followup to: <20030305170452.GD19439@DervishD>
By author: DervishD <[email protected]>
In newsgroup: linux.dev.kernel
>
> Hi Peter :)
>
> H. Peter Anvin dixit:
> > > Please, try to convince Marcello and Alan, too. The 2.4 branch
> > > will be a happier branch (well, assuming that the Linux kernel has
> > sent the code to Alan for 2.5-ac and to Andi for x86-64 (where it has
> > already been integrated); if anyone wants to try to persuade Marcelo to
> > integrate it, be my guest
>
> If you want, I can prepare a patch for the 2.4 series, but if I
> have had problems for a three-line diff to be included, think about
> yours... If you think that Marcello will be inclined to accept this
> patch I'll prepare it in your name.
>
I can ask him, at least.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
> > > sense. Anyone uses floppies yet? Here in Spain a floppy is more
> > > expensive than a 80 min. CD...
> > Doesn't the in kernel bootloader have uses other than booting from
> > floppy? What if you want to boot from a custom network boot prom?
>
> I'm not aware of such uses :??? AFAIK, the in kernel bootloader
> just exists for booting from raw floppies :?? Maybe HPA knows more
> about this.
No, it is only used for floppies, for some reason I was thinking of
something completely unrelated, ignore my previous post.
John.
On Wed, 2003-03-05 at 16:51, H. Peter Anvin wrote:
> It doesn't work for anything but old legacy floppies. I have already
> sent the code to Alan for 2.5-ac and to Andi for x86-64 (where it has
> already been integrated); if anyone wants to try to persuade Marcelo to
It seems completely inappropriate to remove a feature from the 'stable'
kernel tree.
Alan
Followup to: <[email protected]>
By author: Alan Cox <[email protected]>
In newsgroup: linux.dev.kernel
>
> It seems completely inappropriate to remove a feature from the 'stable'
> kernel tree.
>
Agreed. The only issue is whether or not it's too broken to be
considered a feature at this point (my feeling would be that it's not,
and should be removed in 2.5, not 2.4.)
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
H. Peter Anvin writes:
> Mikael Pettersson wrote:
> > >
> > > This is the patch I'm trying to get Linus to accept.
> >
> > That's similar to what you posted to LKML a while ago, and
> > it has the limitations of requiring mountable /dev/fd0, which
> > needs a magic entry in /etc/fstab ("user" privs, not "owner"),
> > and MS-DOS FS support in the kernel used for the build.
> >
>
> No, it doesn't (if you have SYSLINUX 2.02 or higher.)
Indeed. The SYSLINUX 2.02 + mtools combination works like a charm
for 'make bzdisk'. I'm happy with your nobootsect patch.
/Mikael
Followup to: <[email protected]>
By author: Mikael Pettersson <[email protected]>
In newsgroup: linux.dev.kernel
>
> Indeed. The SYSLINUX 2.02 + mtools combination works like a charm
> for 'make bzdisk'. I'm happy with your nobootsect patch.
>
Well, Linus keeps dropping it on the floor, so I don't know if we'll
see a working "make bzdisk" in the kernel any time soon :(
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Hi HPA :)
> > Indeed. The SYSLINUX 2.02 + mtools combination works like a charm
> > for 'make bzdisk'. I'm happy with your nobootsect patch.
> Well, Linus keeps dropping it on the floor, so I don't know if we'll
> see a working "make bzdisk" in the kernel any time soon :(
Do you know why?
Ra?l
DervishD wrote:
> Hi HPA :)
>
>
>>>Indeed. The SYSLINUX 2.02 + mtools combination works like a charm
>>>for 'make bzdisk'. I'm happy with your nobootsect patch.
>>
>>Well, Linus keeps dropping it on the floor, so I don't know if we'll
>>see a working "make bzdisk" in the kernel any time soon :(
>
>
> Do you know why?
>
No, especially not as it turns out I was wrong -- the patch is currently
in the snapshots.
-hpa
Hi HPA :)
H. Peter Anvin dixit:
> >>Well, Linus keeps dropping it on the floor, so I don't know if we'll
> >>see a working "make bzdisk" in the kernel any time soon :(
> > Do you know why?
> No, especially not as it turns out I was wrong -- the patch is currently
> in the snapshots.
;))) Nice, then. I'm waiting for 2.6 :)) (or 3.0, maybe... BUT I
DON'T WANT TO START A TROLL about kernel versioning XDD).
Ra?l