Hello,
Please find attached a patch to build i386/x86_64 kernel directly
bootable. It may be usefull for rescue floppies and installation
floppies.
System sector count is updated by tools/bluid.c at offset 495. The
system could be up to 32 Mb long.
-- support any drive geometry --
Disk geometry detection assumes that no error raises on first track.
First track is read sector by sector and the first error determinates
the sectors per track count. Next, reads are performed track by track.
Tested on floppy H2/S18 and harddisk H16/S63. Should work on
every exotic drive supporting Int13h CHS.
-- cmdline support --
If ram_size (offset 504) bit 13 is set, the kernel cmdline
is load from the sector following the kernel image.
If Ctrl, Alt, Shift or CapsLock is pressed the kernel cmdline is
prompted until Enter key. BackSpace is supported.
Regards,
-pascal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pascal Bellard wrote:
> Hello,
>
> Please find attached a patch to build i386/x86_64 kernel directly
> bootable. It may be usefull for rescue floppies and installation
> floppies.
Pascal,
In commit f8eeaaf4180334a8e5c3582fe62a5f8176a8c124, build.c has already
changed, and I don't believe it's very compatible with this change.
See
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8eeaaf4180334a8e5c3582fe62a5f8176a8c124
Also, we'll need to see comments from H. Peter Anvin on this patch.
CC'ing him.
> System sector count is updated by tools/bluid.c at offset 495. The
> system could be up to 32 Mb long.
>
> -- support any drive geometry --
>
> Disk geometry detection assumes that no error raises on first track.
> First track is read sector by sector and the first error determinates
> the sectors per track count. Next, reads are performed track by track.
> Tested on floppy H2/S18 and harddisk H16/S63. Should work on
> every exotic drive supporting Int13h CHS.
>
> -- cmdline support --
>
> If ram_size (offset 504) bit 13 is set, the kernel cmdline
> is load from the sector following the kernel image.
>
> If Ctrl, Alt, Shift or CapsLock is pressed the kernel cmdline is
> prompted until Enter key. BackSpace is supported.
>
> Regards,
>
> -pascal
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDJyKhaI0dwg4A47wRAjMoAJ9laL5kvIzkbJAxigSJahqkdnmx8gCg6dOy
V6ML9fJQjmfjcdxNGnbSuZ0=
=7P9o
-----END PGP SIGNATURE-----
Frank Sorenson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Pascal Bellard wrote:
>
>>Hello,
>>
>>Please find attached a patch to build i386/x86_64 kernel directly
>>bootable. It may be usefull for rescue floppies and installation
>>floppies.
>
>
> Pascal,
>
> In commit f8eeaaf4180334a8e5c3582fe62a5f8176a8c124, build.c has already
> changed, and I don't believe it's very compatible with this change.
>
> See
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8eeaaf4180334a8e5c3582fe62a5f8176a8c124
>
> Also, we'll need to see comments from H. Peter Anvin on this patch.
> CC'ing him.
>
Geometry detection by looking for error returns is fundamentally broken.
Way too many non-traditional floppies (USB, IDE...) do not handle this
at all, they will return successfully, with the data being the data from
a sector from another track, and thus you end up with aliasing and a
corrupt boot. You can do it with fingerprinting, but that's complex and
error-prone.
In short, this made sense in 1991, but it hasn't made sense for a very
long time now. Resurrecting bootsect.S is *NOT* a good idea.
-hpa
> Frank Sorenson wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Pascal Bellard wrote:
>>
>>>Hello,
>>>
>>>Please find attached a patch to build i386/x86_64 kernel directly
>>>bootable. It may be usefull for rescue floppies and installation
>>>floppies.
>>
>>
>> Pascal,
>>
>> In commit f8eeaaf4180334a8e5c3582fe62a5f8176a8c124, build.c has already
>> changed, and I don't believe it's very compatible with this change.
>>
>> See
>> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8eeaaf4180334a8e5c3582fe62a5f8176a8c124
>>
>> Also, we'll need to see comments from H. Peter Anvin on this patch.
>> CC'ing him.
>>
>
> Geometry detection by looking for error returns is fundamentally broken.
> Way too many non-traditional floppies (USB, IDE...) do not handle this
> at all, they will return successfully, with the data being the data from
> a sector from another track, and thus you end up with aliasing and a
> corrupt boot. You can do it with fingerprinting, but that's complex and
> error-prone.
>
The bootblock code is 497 bytes long. It must as simple as possible.
Complex algorithms like fingerprinting can't be used.
Geometry detection works with usual floppies. This patch goal is to
support them like < 2.6 bootblocks did and fix 1M limitation and
special formatting like 1.68M floppies.
Geometry detection may work with non-traditional floppies but is not
designed to.
BTW, if this kind of floppies doesn't handle error, it's a bug in the
firmware, but not in bootblock code !
> In short, this made sense in 1991, but it hasn't made sense for a very
> long time now. Resurrecting bootsect.S is *NOT* a good idea.
>
1.44M floppies are told dead for more than 10 years. In 2005 most of
computers are sold with these drives. Sometime I have to boot with
a floppy when nothing works (blush).
Kernel code is always growing. The bootblock spares filesystem and
external kernel loader overhead.
While linux kernel has a floppy driver the bootblock is usefull.
Now two solutions:
- without this patch = linux kernel are never directly bootable
- with this patch = linux kernel is directly bootable with some
devices.
What is the better idea ?
-pascal
Frank,
I have built a new patch based on linux-2.6.13-git12 to avoid build.c
conflict.
Regards,
-pascal
> Pascal Bellard wrote:
>> Hello,
>>
>> Please find attached a patch to build i386/x86_64 kernel directly
>> bootable. It may be usefull for rescue floppies and installation
>> floppies.
>
> Pascal,
>
> In commit f8eeaaf4180334a8e5c3582fe62a5f8176a8c124, build.c has already
> changed, and I don't believe it's very compatible with this change.
>
> See
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8eeaaf4180334a8e5c3582fe62a5f8176a8c124
>
> Also, we'll need to see comments from H. Peter Anvin on this patch.
> CC'ing him.
Hello!
> Now two solutions:
>
> - without this patch = linux kernel are never directly bootable
> - with this patch = linux kernel is directly bootable with some
> devices.
>
> What is the better idea ?
The first, as long as nobody really needs direct booting. Code bloat.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
The first myth of management is that it exists.
Pascal Bellard wrote:
>
> Now two solutions:
>
> - without this patch = linux kernel are never directly bootable
> - with this patch = linux kernel is directly bootable with some
> devices.
>
> What is the better idea ?
>
The former, based on the *huge* number of emails of "it doesn't work on
my platform" we kept getting, and getting, and getting.
It would be another matter if it was a high-value feature, but it's not.
-hpa
On Sat, 17 Sep 2005 17:56:08 +0200, Jesper Juhl wrote:
>> This is probably a stupid suggestion, but here it goes anyway: the
>> kernel has to be written on disk by something, right?
>>
>> So if the "something" knows (or can get to know) the sector/tracks
>> layout of the disk it's writing the kernel onto, it could store this
>> information in the bootblock (is there space for that?). The bootblock
>> code would then just read this info and use it.
>>
>> Of course, this would mean that making a kernel-bootable floppy
>> wouldn't be as simple as cp'ing the kernel image to /dev/fdwhatever,
>> but if a script/program designed to do this was included with the
>> kernel source (it wouldn't be too big ...) ...
>>
> I may be missing something here, but if you are going to do something
> like that, then why not just use a real bootloader instead?
I'm not too much into this stuff, I don't even know the technical
differences betwen booting from kernel-on-floppy or from a bootloader.
My proposal was just to work around the "what's the track layout"
issue in the kernel-on-floppy direct boot. Maybe you could see it like
a delayed bootloader process ... don't know.
But as I mentioned, it was probably just a stupid suggestion :)
--
Giuseppe "Oblomov" Bilotta
Axiom I of the Giuseppe Bilotta
theory of IT:
Anything is better than MS
On 9/17/05, Giuseppe Bilotta <[email protected]> wrote:
> On Wed, 14 Sep 2005 11:42:12 +0200 (CEST), Pascal Bellard wrote:
>
> > The bootblock code is 497 bytes long. It must as simple as possible.
> > Complex algorithms like fingerprinting can't be used.
> >
> > Geometry detection works with usual floppies. This patch goal is to
> > support them like < 2.6 bootblocks did and fix 1M limitation and
> > special formatting like 1.68M floppies.
> >
> > Geometry detection may work with non-traditional floppies but is not
> > designed to.
>
> This is probably a stupid suggestion, but here it goes anyway: the
> kernel has to be written on disk by something, right?
>
> So if the "something" knows (or can get to know) the sector/tracks
> layout of the disk it's writing the kernel onto, it could store this
> information in the bootblock (is there space for that?). The bootblock
> code would then just read this info and use it.
>
> Of course, this would mean that making a kernel-bootable floppy
> wouldn't be as simple as cp'ing the kernel image to /dev/fdwhatever,
> but if a script/program designed to do this was included with the
> kernel source (it wouldn't be too big ...) ...
>
I may be missing something here, but if you are going to do something
like that, then why not just use a real bootloader instead?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Wed, 14 Sep 2005 11:42:12 +0200 (CEST), Pascal Bellard wrote:
> The bootblock code is 497 bytes long. It must as simple as possible.
> Complex algorithms like fingerprinting can't be used.
>
> Geometry detection works with usual floppies. This patch goal is to
> support them like < 2.6 bootblocks did and fix 1M limitation and
> special formatting like 1.68M floppies.
>
> Geometry detection may work with non-traditional floppies but is not
> designed to.
This is probably a stupid suggestion, but here it goes anyway: the
kernel has to be written on disk by something, right?
So if the "something" knows (or can get to know) the sector/tracks
layout of the disk it's writing the kernel onto, it could store this
information in the bootblock (is there space for that?). The bootblock
code would then just read this info and use it.
Of course, this would mean that making a kernel-bootable floppy
wouldn't be as simple as cp'ing the kernel image to /dev/fdwhatever,
but if a script/program designed to do this was included with the
kernel source (it wouldn't be too big ...) ...
--
Giuseppe "Oblomov" Bilotta
"Da grande lotter? per la pace"
"A me me la compra il mio babbo"
(Altan)
("When I grow up, I will fight for peace"
"I'll have my daddy buy it for me")
On 9/18/05, Giuseppe Bilotta <[email protected]> wrote:
> On Sat, 17 Sep 2005 17:56:08 +0200, Jesper Juhl wrote:
>
> >> This is probably a stupid suggestion, but here it goes anyway: the
> >> kernel has to be written on disk by something, right?
> >>
> >> So if the "something" knows (or can get to know) the sector/tracks
> >> layout of the disk it's writing the kernel onto, it could store this
> >> information in the bootblock (is there space for that?). The bootblock
> >> code would then just read this info and use it.
> >>
> >> Of course, this would mean that making a kernel-bootable floppy
> >> wouldn't be as simple as cp'ing the kernel image to /dev/fdwhatever,
> >> but if a script/program designed to do this was included with the
> >> kernel source (it wouldn't be too big ...) ...
> >>
> > I may be missing something here, but if you are going to do something
> > like that, then why not just use a real bootloader instead?
>
> I'm not too much into this stuff, I don't even know the technical
> differences betwen booting from kernel-on-floppy or from a bootloader.
> My proposal was just to work around the "what's the track layout"
> issue in the kernel-on-floppy direct boot. Maybe you could see it like
Actually, DOS/Windows works that way. FAT filesystem stores the number
of sectors per track in its boot sector.
> a delayed bootloader process ... don't know.
>
> But as I mentioned, it was probably just a stupid suggestion :)
You are too humble. It's not you, but linux bootsect.S stupid IMHO. ;)
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
>>>> So if the "something" knows (or can get to know) the sector/tracks
>>>> layout of the disk it's writing the kernel onto, it could store this
>>>> information in the bootblock (is there space for that?). The bootblock
>>>> code would then just read this info and use it.
>
> Actually, DOS/Windows works that way. FAT filesystem stores the number
> of sectors per track in its boot sector.
Gujin installer creates the filesystem (and the partition table if
needed), the MBR with the disk geometry, and chain a simple bootloader
or a menu based bootloader on the created FAT filesystem when told to
do so.
So if you just want to put a kernel and initrd on a floppy, and the
floppy is big enough, you just do:
$ mkdir tmp
$ cd tmp
$ wget http://heanet.dl.sourceforge.net/sourceforge/gujin/install-1.2.tar.gz
$ tar xvzf install-1.2.tar.gz
$ ./instboot tiny.bin /dev/fd0
$ mcopy /boot/vmlinuz-2.6.13 a:
$ mcopy /boot/initrd-2.6.13 a:
And you reboot with the floppy still inside the drive.
If you want to put them on your USB thumb drive, and your PC can
boot USB flash drives as a floppy (lot of BIOS bugs there), you
just change the line (double check that your USB key is /dev/sda):
$ ./instboot tiny.bin /dev/fd0
by:
$ ./instboot tiny.bin /dev/sda --disk=BIOS:0x00 --geometry=/dev/sda
I personnally better like a partition table on my USB drives, so
I am more used to erase manually the partition table:
$ dd if=/dev/null of=/dev/sda bs=512 count=64 # blank the head of the disk
and then type:
$ ./instboot boot.bin /dev/sda --disk=BIOS:0x00 --geometry=/dev/sda \
--mbr-device=/dev/sda --partition_index=1
When booted from this key, the PC will boot the kernel named vmlinuz*
and load the initrd/initramfs named initrd* (tiny.bin does not contain
the graphic menu management).
I will not say that I tested it lately, but you may also want to put
your kernel and initrd on a bootable CDROM - without having the usual
Gujin menu - then you just do:
$ mkdir tmpdir
$ cp /boot/vmlinuz-2.6.13 tmpdir
$ cp /boot/initrd-2.6.13 tmpdir
$ ./instboot tiny.bin tmpdir/tiny.bcd
$ mkisofs -untranslated-filenames -no-emul-boot -boot-load-size 4 \
-b tiny.bcd tmpdir -o boot.iso
$ cdrecord boot.iso
It is usually better (and will work for all those configuration)
to put the kernel and its initrd inside a directory named "/boot",
but I am highjicking a thread so want to keep it simple...
Etienne.