booting from ISO image on HD?
laota
can i, by any mechanism, boot from a bootable ISO image on a hard
disk(instead of burning it into a blank CD, and boot from CDROM)?
for example, i have following ISOs on /dev/hda1:
/
-knoppix.iso;
-slax.iso;
-sarge-netinst.iso
can i, at the bootloader stage(or any other stage), specify some ISO by
path name, and then booting from it, just as if i have a real bootable
CD in the CDROM? i have done some research into the knoppix 'bootfrom'
cheatcode, but it is for knoppix, only.
is pervasive support of 'boot ISO on HD' possible theoretically?? are
there any opensource project doing a similar job? any help would be
appreciated! thanks.
Robert.Lai
Tauno Voipio
The CD booting mechanism (El Torito) is based on
a BIOS service which replaces the floppy drive
with a floppy image on the CD.
AFAIK, to do something similar for a CD image on
a hard disk would need a BIOS addition.
--
Tauno Voipio
tauno voipio (at) iki fi
Peter T. Breuer
> can i, by any mechanism, boot from a bootable ISO image on a hard
> disk(instead of burning it into a blank CD, and boot from CDROM)?
Sure - you can boot into it (rather than "from it", as you phrased it).
You will need a little init ramdisk that mounts the image loopback and
then does a pivot root onto the mount - standard fare for init ramdisk
images.
Peter
laota
I have read the El Torito standard, but I couldn't quite catch it. :(
I am not familiar with BIOS. What does "a BIOS addition" mean? Can
normal
programmers add some customized services into BIOS? or, it is just
pre-defined by the manufacturer?
Do you know any good sites where I can get some BIOS related knowledge?
laota
But, what should i do after pivot_root? executing what? Can you make it
more clear?
Several days ago, I have successfully booted Knoopix and Slax LiveCD
through customized initrd files for each one. I extract the initrd file
from the ISO image ,modify the /linuxrc within the inird file, specify
the customized initrd file in the 'initrd=' kernel parameter, and make
it! At the beginning of the /linuxrc file, I add some commands which
mount the ISO file to some place like /dev/hdd(hardlink to a loopback
device, really ugly....). So, the following device-probing code of
/linuxrc will believe that some CDROM device does exist and booting
happily.
But, my initrd mechanism does have many drawbacks. For each ISO, I have
to provide a modified version of initrd. No common initrd is possible,
because in most cases, I have to insmod the loop kernel module(e.g.
loop.ko for 2.6.x kernel) before mounting the loopback device, you
know the loop module should be of the same version as the kernel image
in the ISO image, so... tedious. My mentor is also not happy with my
proposal, he wants some sort of pervasive support.(Oh My Godness...).
So, it seems that the initrd solution is a liitle bit too high level.
(Maybe BIOS solution? I don't know... )
So, I feel a little bit depressed now. It is possible on earth to 'boot
ISO on HD' theoretically?? It would be nice if there are some similar
projects I can ture to.
Anyway, thanks Peter.
Robert.Lai
Peter T. Breuer
> But, what should i do after pivot_root? executing what?
A new init, I would say. Don't you want to run your init system once
the new root is in place? I'd want to exec /sbin/init 3 or something
like that.
> Can you make it
> more clear?
I'm not going to write the pivot root script, since I recall the last
time I did one it took me days of painful experiment to avoid all the
pitfalls that should have been obvious - but then I was squeezing the
image down as far as I could ... Oh, very well, here's one I did:
# mount proc on ramdisk
mount /proc
depmod -a
while read module options; do
case $module in ""|'#'*) continue ;; esac
modprobe $module $options
done < /etc/modules
raidstart -a || raidstart /dev/md/1
# mount real root on ramdisk
mount /rootfs || exit 1
cd /rootfs || exit 2
mkdir -p initrd || exit 3
mount -ro remount /rootfs
# unmount proc and pivot to real root with ramdisk
# mounted on /initrd
umount /proc
pivot_root . initrd || exit 4
# remount and have a look around
mount /proc
umount /initrd
umount /proc
exec chroot . sbin/init <dev/console >dev/console 2>&1 || sh
#
#umount /initrd
#blockdev --flushbufs /dev/ram0
> Several days ago, I have successfully booted Knoopix and Slax LiveCD
> through customized initrd files for each one. I extract the initrd file
> from the ISO image ,modify the /linuxrc within the inird file, specify
> the customized initrd file in the 'initrd=' kernel parameter, and make
> it! At the beginning of the /linuxrc file, I add some commands which
> mount the ISO file to some place like /dev/hdd(hardlink to a loopback
> device, really ugly....). So, the following device-probing code of
> /linuxrc will believe that some CDROM device does exist and booting
> happily.
OK, whatever.
> But, my initrd mechanism does have many drawbacks. For each ISO, I have
> to provide a modified version of initrd. No common initrd is possible,
> because in most cases, I have to insmod the loop kernel module(e.g.
> loop.ko for 2.6.x kernel) before mounting the loopback device,
Well, you can always do that on spec. It doesn't matter if it fails -
it's either already in kernel or nothing worse can happen since you will
fail elsewhere lower down anyway now.
> you
> know the loop module should be of the same version as the kernel image
> in the ISO image,
Sure, but that goes without saying. One generally matches the initrd to
the kernel, since it is usually used to house some modules. I usually
have a few trees in there ...
% ls lib/modules/
2.2.18pre18-SMP/ 2.4.3-SMP-XFS/ 2.4.6-SMP-XFS/ 2.4.8-SMP-XFS/
> so... tedious. My mentor is also not happy with my
> proposal, he wants some sort of pervasive support.(Oh My Godness...).
> So, it seems that the initrd solution is a liitle bit too high level.
> (Maybe BIOS solution? I don't know... )
I really don't see the problem .. you can boot the kernel of your
choice with the initrd of your choice as target, no? If your kernel does
not support iso9660 then you are stuffed, so I don't see why you should
cmplain about being stuffed if it does not support loop. What's in a
name? The idea is that either you build what you need to boot into your
kernel, or you put it in the initrd, and in the latter case you have to
match the initrd to the kernel.
> So, I feel a little bit depressed now. It is possible on earth to 'boot
> ISO on HD' theoretically??
I believe your boss wants an all-in-one solution, all in a cd image
rather than having a cd image plus a kernel plus a ramdisk image plus a
cd image. As far as I'm concerned, there's no difference, since you can
put all those three things in one file and manage the trick via offsets
or other magic. You still have to boot your kernel or its bootloader,
however, and that needs bios support or other support. For example,
booting freedos and then running loadlin is a good way to start out.
But, no, the bios CANNOT "boot from" an arbitrary place on an arbitrary
hard disk - the best you can do is place some boot record in the boot
sequence of some boot loader that will do it after the bios has booted
IT. If I were you I would place the kernel image bundle on disk, then
generate a boot record file (512B) that will boot it while it is in that
place, then add that boot record file reference to windows boot.ini
file.
> It would be nice if there are some similar
> projects I can ture to.
It's not clear what you want.
Peter
laota
many valuable adivces.
Yes, my boss did require an all-in-one solution. Booting from a
bootable ISO image should have exactly the same performances as booting
from CDROM. That is, kernel image, modules, application programs and so
on, shoule be of no differences. So, I have no right to boot a
customized kernel image and only regard the bootable ISO image as a
normal data ISO image. Sorry for my poor English. I hope you can
understand the case.
definitely true!
> As far as I'm concerned, there's no difference, since you can
> put all those three things in one file and manage the trick via offsets
> or other magic. You still have to boot your kernel or its bootloader,
~~~~~~~~~~~~~~~the one on ISO image?
> however, and that needs bios support or other support. For example,
oh... BIOS......
> booting freedos and then running loadlin is a good way to start out.
nice! a new idea! Using LOADIN to chain-load the isolinux(for example)
on the ISO image? Are there any tools similar to LOADIN under
Linux?(or, only freedos can do)
Is it possible not bringing up an OS and booting from the ISO on HD
directly?(I know, it is not easy...)
> But, no, the bios CANNOT "boot from" an arbitrary place on an arbitrary
> hard disk - the best you can do is place some boot record in the boot
> sequence of some boot loader that will do it after the bios has booted
> IT. If I were you I would place the kernel image bundle on disk, then
> generate a boot record file (512B) that will boot it while it is in that
> place, then add that boot record file reference to windows boot.ini
> file.
retrieve the boot record file from ISO or create a new one? it is
chain-load, isn't it?
Enrique Perez-Terron
> Nice. Thank you, Peter.
> But, what should i do after pivot_root? executing what? Can you make it
> more clear?
After pivot_root, exec /sbin/init.
> Several days ago, I have successfully booted Knoopix and Slax LiveCD
> through customized initrd files for each one. I extract the initrd file
> from the ISO image ,modify the /linuxrc within the inird file, specify
> the customized initrd file in the 'initrd=' kernel parameter, and make
> it! At the beginning of the /linuxrc file, I add some commands which
> mount the ISO file to some place like /dev/hdd(hardlink to a loopback
> device, really ugly....).
Stop. Mount has two arguments, a device and a directory.
In English (Unixish) people say they mount the device on the directory.
Not the "on the device".
In the case of a loopback mount, the device is the loopback device.
Before the actual mounting, the mount program sets up the association
between the loopback device and the underlying file (the iso image).
> So, the following device-probing code of
> /linuxrc will believe that some CDROM device does exist and booting
> happily.
It seems like you are thinking that the "device-probing code" infers
something from the fact that the link resides in the /dev/directory?
Or from the fact that the link has a name starting with "hd"?
What "device-probing code" are you referring to?
Also be aware that a hard link is nothing but another file name.
That is, if /dev/hdd is a hard link to /dev/loop1, then /dev/hdd and
/dev/loop1 are two equivalent names of the same file. There is no
way to tell which name is the "right" one.
> But, my initrd mechanism does have many drawbacks. For each ISO, I have
> to provide a modified version of initrd. No common initrd is possible,
> because in most cases, I have to insmod the loop kernel module(e.g.
> loop.ko for 2.6.x kernel) before mounting the loopback device, you
> know the loop module should be of the same version as the kernel image
> in the ISO image, so... tedious.
But wait a minute, to run an initrd, you need a kernel! If the kernel is
on the CD, how can you boot it from an initrd???
I suppose you are first booting a kernel, and the special initrd, from
some other device, but you want that kernel to boot another kernel?
In the following, I suppose you have the right kernel running.
What shell runs your linuxrc? You need one that has the capability
to test the name of the kernel. Are you using nash? From nash's
manpage, it seems nash cannot do this. Find a statically linked shell,
or include in the initrd the files required for dynamic linking.
I suggest ash, it is much smaller:
$ ldd /bin/ash
linux-gate.so.1 => (0x00440000)
libc.so.6 => /lib/libc.so.6 (0x00b7f000)
/lib/ld-linux.so.2 (0x00b61000)
$ ldd /bin/bash
linux-gate.so.1 => (0x00f4c000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x003dd000)
libdl.so.2 => /lib/libdl.so.2 (0x00cd1000)
libc.so.6 => /lib/libc.so.6 (0x00b7f000)
/lib/ld-linux.so.2 (0x00b61000)
$ ls -l /bin/ash
-rwxr-xr-x 1 root root 98356 Jun 16 2004 /bin/ash
$ ls -l /bin/bash
-rwxr-xr-x 1 root root 686520 May 10 2005 /bin/bash
For dynamic linking you also need /lib/ld-linux.so (a symbolic link)
and whatever that link points to.
> My mentor is also not happy with my
> proposal, he wants some sort of pervasive support.(Oh My Godness...).
Does he actually know what he wants? It may be your job to help him know
better what he wants.
> So, it seems that the initrd solution is a little bit too high level.
> (Maybe BIOS solution? I don't know... )
Bios is not a good idea. A bios is very tightly adapted to the specific
hardware of the computer, and cannot easily be transferred to other computers.
Also, the bios is stored in a flash ram (it used to be a rom, then a prom
or eprom, so it is often still referred to as a prom). I suppose this flash
ram does not usually have much more capacity than required by the bios it
contains. The special code you need will likely not fit in whatever free
room remains.
> So, I feel a little bit depressed now. It is possible on earth to 'boot
> ISO on HD' theoretically??
Absolutely. You need a specialized boot loader that creates the initrd
on the fly, extracting the required module from the iso image. If the
module is not there, assume it is compiled-in into the kernel itself.
English: "Why on earth". "Possible at all".
-Enrique
Peter T. Breuer
>> I believe your boss wants an all-in-one solution, all in a cd image
>> rather than having a cd image plus a kernel plus a ramdisk image plus a
>> cd image.
> definitely true!
>> As far as I'm concerned, there's no difference, since you can
>> put all those three things in one file and manage the trick via offsets
>> or other magic. You still have to boot your kernel or its bootloader,
> ~~~~~~~~~~~~~~~the one on ISO image?
Well, the one in your compound image (which may be one you have
extracted from the iso image via an external reader, but then you have
to make sure it supports loop intrinsically or else extract a loop
module to load for it in the initrd from the iso image too).
I get the idea - your boss wants you to package a knoppix image for
booting from harddisk as a single drop-in lump/package on disk. Well,
you could do that IF you are prepared to track knoppix changes and
compensate for them. But the end user couldn't just take (a) your tools
and (b) a knoppix image and (c) run your tools to produce a single image
on disk that then can be "booted" directly, because you don't know where
the knoppix kernel will have gone in the image in future releases.
If I remember a knoppix iso structure correctly, it is essentially just
a kernel and an initrc script which mounts a second single large file
on the cd as a compressed loopback filesystem, and then does a pivot
root into it. So you might argue that the kernel would be easy to find
always, and that it probably certainly has loop support, either
intrinsically or as a module - or does the knoppix compressed block device
driver work without the intervening loop layer? I forget. It is a
compressed block device that knoppix has a driver for - I remember
that. Nice idea. Not a compressed file system.
>> however, and that needs bios support or other support. For example,
> oh... BIOS......
>> booting freedos and then running loadlin is a good way to start out.
> nice! a new idea! Using LOADIN to chain-load the isolinux(for example)
> on the ISO image?
Well, I fear that's not possible. But since you are talking about
knoppix, why don't you extract the knoppix FS image file from the cdrom
and put it in a compound file on disk? The start of the file could
contain a kernel that you put there, followed by an ramdisk image that
you put there .... You could use loadlin to boot that "file", which is
what you want. If you get the boot parameters right, I think the kernel
will load the ramdisk image at the given offset (given by you, that
is), and at that point you can losetup the rest of the file with an
offset in order to get at the knoppix fs image. You can skip
the probes that knoppix does in its initrc and just tell it directly.
The point is that loadlin boots a file.
> Are there any tools similar to LOADIN under
> Linux?(or, only freedos can do)
No - one can't load an o/s from the protected mode that the kernel puts
one in in order to run a multiuser o/s. One has to be in real mode, i.e.
either in the bios or in DOS (i.e. emulating an 8086). That's why I
suggested using freedos, which would allow you to run some scripts to
configure the situation before running loadlin to start the configured
image, and would allow you to boot a FILE with loadlin.
> Is it possible not bringing up an OS and booting from the ISO on HD
> directly?(I know, it is not easy...)
>> But, no, the bios CANNOT "boot from" an arbitrary place on an arbitrary
>> hard disk - the best you can do is place some boot record in the boot
>> sequence of some boot loader that will do it after the bios has booted
>> IT. If I were you I would place the kernel image bundle on disk, then
>> generate a boot record file (512B) that will boot it while it is in that
>> place, then add that boot record file reference to windows boot.ini
>> file.
> retrieve the boot record file from ISO or create a new one? it is
> chain-load, isn't it?
You would have to create an entirely new boot record, by mounting the
file temporarily loopback, running lilo with a lilo.conf that pointed
at the mounted vmlinuz and /boot areas, and I suspect that lilo will
want t write a map file somewhere on disk ... with luck it'll be in the
loopback image, and with luck the loop driver will translate the block
mapping info out to disk sectors for lilo ... this might require
liasing with the lilo author and a kernel driver author if it doesn't
work out first shot, because the driver or lilo functionality might not
have been implemented, although it should have been.
I think. (it's hard to see far with so many variables).
Peter
laota
Enrique Perez-Terron wrote:
> On Sat, 14 Jan 2006 13:23:41 +0100, laota <laot...@gmail.com> wrote:
>
> > Nice. Thank you, Peter.
> > But, what should i do after pivot_root? executing what? Can you make it
> > more clear?
>
> After pivot_root, exec /sbin/init.
>
> > Several days ago, I have successfully booted Knoopix and Slax LiveCD
> > through customized initrd files for each one. I extract the initrd file
> > from the ISO image ,modify the /linuxrc within the inird file, specify
> > the customized initrd file in the 'initrd=' kernel parameter, and make
> > it! At the beginning of the /linuxrc file, I add some commands which
> > mount the ISO file to some place like /dev/hdd(hardlink to a loopback
> > device, really ugly....).
>
> Stop. Mount has two arguments, a device and a directory.
>
> In English (Unixish) people say they mount the device on the directory.
> Not the "on the device".
oh.. yes. My expression is not accurate.
>
> In the case of a loopback mount, the device is the loopback device.
> Before the actual mounting, the mount program sets up the association
> between the loopback device and the underlying file (the iso image).
>
> > So, the following device-probing code of
> > /linuxrc will believe that some CDROM device does exist and booting
> > happily.
>
> It seems like you are thinking that the "device-probing code" infers
> something from the fact that the link resides in the /dev/directory?
> Or from the fact that the link has a name starting with "hd"?
>
> What "device-probing code" are you referring to?
>
just as you said. The Knoppix /linuxrc enumerates /dev/hd?, /dev/sd?
and so on to find CDROM. So, I just make a 'fack CDROM' by means of
loopback device.
> Also be aware that a hard link is nothing but another file name.
> That is, if /dev/hdd is a hard link to /dev/loop1, then /dev/hdd and
> /dev/loop1 are two equivalent names of the same file. There is no
> way to tell which name is the "right" one.
>
yeah, I know, they are of the same inode.
/dev/hdd is a hard link to /dev/loop1, then all the work is actually
done by loopback. It is ugly. :(
>
> > But, my initrd mechanism does have many drawbacks. For each ISO, I have
> > to provide a modified version of initrd. No common initrd is possible,
> > because in most cases, I have to insmod the loop kernel module(e.g.
> > loop.ko for 2.6.x kernel) before mounting the loopback device, you
> > know the loop module should be of the same version as the kernel image
> > in the ISO image, so... tedious.
>
> But wait a minute, to run an initrd, you need a kernel! If the kernel is
> on the CD, how can you boot it from an initrd???
The kernel image is extracted from ISO image too. Then, all the kernel
image and modified initrd is provided to the bootloader.
>
> I suppose you are first booting a kernel, and the special initrd, from
> some other device, but you want that kernel to boot another kernel?
>
> In the following, I suppose you have the right kernel running.
>
> What shell runs your linuxrc? You need one that has the capability
> to test the name of the kernel. Are you using nash? From nash's
> manpage, it seems nash cannot do this. Find a statically linked shell,
> or include in the initrd the files required for dynamic linking.
>
> I suggest ash, it is much smaller:
yes, it is ash
>
> $ ldd /bin/ash
> linux-gate.so.1 => (0x00440000)
> libc.so.6 => /lib/libc.so.6 (0x00b7f000)
> /lib/ld-linux.so.2 (0x00b61000)
> $ ldd /bin/bash
> linux-gate.so.1 => (0x00f4c000)
> libtermcap.so.2 => /lib/libtermcap.so.2 (0x003dd000)
> libdl.so.2 => /lib/libdl.so.2 (0x00cd1000)
> libc.so.6 => /lib/libc.so.6 (0x00b7f000)
> /lib/ld-linux.so.2 (0x00b61000)
> $ ls -l /bin/ash
> -rwxr-xr-x 1 root root 98356 Jun 16 2004 /bin/ash
> $ ls -l /bin/bash
> -rwxr-xr-x 1 root root 686520 May 10 2005 /bin/bash
>
> For dynamic linking you also need /lib/ld-linux.so (a symbolic link)
> and whatever that link points to.
>
> > My mentor is also not happy with my
> > proposal, he wants some sort of pervasive support.(Oh My Godness...).
>
> Does he actually know what he wants? It may be your job to help him know
> better what he wants.
Sorry again for my expression skill.... We just want a mechanism that
allows us to boot from bootable Linux ISO image on harddisk. Just
pervasive support of 'boot from ISO on HD'. You can not say, ok,
Knoppix ISO can boot, but Slax ISO will not work. He even mentioned the
Fedora Core 4 ISO(4 disks, the first one bootable, you know). He said
it would be nice to complete a installation work by this 'boot from ISO
on HD' mechanism... I just wonder, how can i change to the second ISO
after the installation work of the first one is done... :(
>
> > So, it seems that the initrd solution is a little bit too high level.
> > (Maybe BIOS solution? I don't know... )
>
> Bios is not a good idea. A bios is very tightly adapted to the specific
> hardware of the computer, and cannot easily be transferred to other computers.
> Also, the bios is stored in a flash ram (it used to be a rom, then a prom
> or eprom, so it is often still referred to as a prom). I suppose this flash
> ram does not usually have much more capacity than required by the bios it
> contains. The special code you need will likely not fit in whatever free
> room remains.
Exactly. BIOS is not a good solution, neither. Low level, lack of
portability and so on..
The Linux kernel always re-enumerates the perpheral devices by himself,
and then no longer make use of BIOS services.
> > So, I feel a little bit depressed now. It is possible on earth to 'boot
> > ISO on HD' theoretically??
>
> Absolutely. You need a specialized boot loader that creates the initrd
> on the fly, extracting the required module from the iso image. If the
> module is not there, assume it is compiled-in into the kernel itself.
>
hmmm.... then the bootloader should know the filesystem of my harddisk
and iso9660, isn't it ? I think these functions should be performed in
the 'stage 2' of this bootloader and leave the 'stage 1' programe
written in ASM(and compiled and install to the boot sector) untouched.
what do you think? maybe I can refer to the GRUB code.
yes, we can create a new initrd, but we still need the functions in the
original initrd on ISO, just extract and call the /linuxrc within the
original initrd?
> English: "Why on earth". "Possible at all".
haha, thanks, Enrique, sorry for my poor English
>
> -Enrique
Enrique Perez-Terron
> Enrique Perez-Terron wrote:
>> In English (Unixish) people say they mount the device on the directory.
>> Not the "on the device".
>
> oh.. yes. My expression is not accurate.
Ok, it was just to make sure no misunderstanding crept in. I am a bit
stupid sometimes :).
[...]
>> What "device-probing code" are you referring to?
>>
> just as you said. The Knoppix /linuxrc enumerates /dev/hd?, /dev/sd?
> and so on to find CDROM. So, I just make a 'fack CDROM' by means of
> loopback device.
Hm, since the goal is to be completely generic, you cannot just figure
out what that knoppix initrd is trying to do, and make replace it with
your own code... I don't think you can predict every concievably thing
a distro initrd can do.
I think it is necessary to understand the goal at a higher level, in
order to understand what is important, and what is not. For most distros,
the only purpose of the initrd is to 1) find out what kernel modules are
needed in order to mount the root file system, 2) insmod those modules,
mount the root file system, pivot root, and start /sbin/init. Or just
exit, instead of starting /sbin/init. The kernel will then look for
a program called init, and start it.
The thing that you are creating, will it be sent out to a number of
customers and run on a variety of systems? While it be run on a
specific kind of computers? Or on a specific computer? Where will
it reside, on another CD, on the hard disk? How does the user of this
system tell your program which iso image he wants to boot? etc.
Since we "know" there will be iso image files, we probably also know
there is a hard disk where that iso image resides. We know something
that the authors of the on-iso initrd did not know. You know how to
get the kernel going, and dont' really need the acrobatics the knoppix
initrd is doing. But then there is a catch: once you run the on-iso
init program, and this program runs the /etc/rc.d/rc.sysinit script
(or whatever that distro uses) the sysinit script may depend on some
things being left over from the initrd, like a mounted /proc. That is
the hard part. How to know what the next stage needs. Your solution
seems to be to run the on-iso initrd to get this right, but then I
guess you are telling this fails when that on-iso initrd supposes
things that are not the case in this environment.
>> Also be aware that a hard link is nothing but another file name.
>> That is, if /dev/hdd is a hard link to /dev/loop1, then /dev/hdd and
>> /dev/loop1 are two equivalent names of the same file. There is no
>> way to tell which name is the "right" one.
>>
> yeah, I know, they are of the same inode.
> /dev/hdd is a hard link to /dev/loop1, then all the work is actually
> done by loopback. It is ugly. :(
I don't think you should consider it "ugly". The initrd is usually
discarded right after the pivot-root, and the uglyness is gone. The
question is if it is fragile. What happens when the next distro iso
appears, and it does something a different way? What are the *real*
needs here.
The normal boot mechanism starts with the bios loading a boot loader
starting from a boot sector, and then the boot loader places in memory
three things: the kernel, the initrd, and *** a kernel command line ***.
This kernel command line contains the root= option.
The case of a knoppix is different because there is not root= string
before the kernel is started. The computer read the el-torito floppy
image, starts a kernel with the initrd, but then the initrd code
must find a suitable device file to mount as the root file system.
In your case it is /dev/loop1, but the knoppix initrd does not know that.
>> > But, my initrd mechanism does have many drawbacks. For each ISO, I have
>> > to provide a modified version of initrd. No common initrd is possible,
>> > because in most cases, I have to insmod the loop kernel module(e.g.
>> > loop.ko for 2.6.x kernel) before mounting the loopback device, you
>> > know the loop module should be of the same version as the kernel image
>> > in the ISO image, so... tedious.
>>
>> But wait a minute, to run an initrd, you need a kernel! If the kernel is
>> on the CD, how can you boot it from an initrd???
>
> The kernel image is extracted from ISO image too. Then, all the kernel
> image and modified initrd is provided to the bootloader.
What is running while this happens? Are you first doing a preliminary
run with a disk-booted linux, and processing the iso image to extract
the kernel and creating a special initrd, then constructing a boot
loader setup that can use these, and then rebooting, to use this boot
loader setup?
>> > My mentor is also not happy with my
>> > proposal, he wants some sort of pervasive support.(Oh My Godness...).
>>
>> Does he actually know what he wants? It may be your job to help him know
>> better what he wants.
>
> Sorry again for my expression skill....
Don't worry, your expression skills are quite good. The wrinkles we can
iron out as we find them.
> We just want a mechanism thatallows us to boot from bootable Linux ISO image on harddisk. Just
> pervasive support of 'boot from ISO on HD'. You can not say, ok,
> Knoppix ISO can boot, but Slax ISO will not work. He even mentioned the
> Fedora Core 4 ISO(4 disks, the first one bootable, you know). He said
> it would be nice to complete a installation work by this 'boot from ISO
> on HD' mechanism...
???
> I just wonder, how can i change to the second ISO
> after the installation work of the first one is done... :(
So, you have iso images on, say partition /dev/hda1, and you want to boot
the iso images there, and use them to install Fedora Core 4 to, say,
partition /dev/hda2?
This CD wants to start with its own boot loader, that asks the user if he
wants a graphical install, or whatever, and the user responds by supplying
the kernel command line keywords. Then this boot loader loads a huge initrd
containing the Anaconda program, which does the installation.
Whatever the solution is, this will be rather specific to the FC4 and the
Anaconda program. Anaconda asks what installation media you want to install
from. You can say harddisk, nfs, ftp, or cdrom. If you loop-mount all four
CD's, you can create a single directory containing symbolic links to each
rpm file on all the CDs.
But this has nothing to do with booting. This is running specialized programs
that come on a CD, and asks a user to insert the other CDs or specify an FTP
server. Being completely generic at this level is only possible if you create
a virtual computer, something like vmware...
If this problem is too big, look at the specific needs and decide how to
make the problem smaller by excluding something.
>> > So, it seems that the initrd solution is a little bit too high level.
>> > (Maybe BIOS solution? I don't know... )
>>
>> Bios is not a good idea. A bios is very tightly adapted to the specific
>> hardware of the computer, and cannot easily be transferred to other computers.
>> Also, the bios is stored in a flash ram (it used to be a rom, then a prom
>> or eprom, so it is often still referred to as a prom). I suppose this flash
>> ram does not usually have much more capacity than required by the bios it
>> contains. The special code you need will likely not fit in whatever free
>> room remains.
>
> Exactly. BIOS is not a good solution, neither. Low level, lack of
> portability and so on..
> The Linux kernel always re-enumerates the perpheral devices by himself,
> and then no longer make use of BIOS services.
>
>> > So, I feel a little bit depressed now. It is possible on earth to 'boot
>> > ISO on HD' theoretically??
>>
>> Absolutely. You need a specialized boot loader that creates the initrd
>> on the fly, extracting the required module from the iso image. If the
>> module is not there, assume it is compiled-in into the kernel itself.
>>
> hmmm.... then the bootloader should know the filesystem of my harddisk
> and iso9660, isn't it ? I think these functions should be performed in
> the 'stage 2' of this bootloader and leave the 'stage 1' programe
> written in ASM(and compiled and install to the boot sector) untouched.
> what do you think? maybe I can refer to the GRUB code.
I think Peter had some very good ideas here, much better than creating a
new grub.
> yes, we can create a new initrd, but we still need the functions in the
> original initrd on ISO, just extract and call the /linuxrc within the
> original initrd?
I question whether you need this. Just get the kernel running with a reasonable
set of things mounted, perhpas the /proc, or perhaps not. Most likely
just the /dev/loop, and let the sysinit scripts cope. Or start out with
the assumption that they will all cope, and see what can be done for those
that don't
>
>> English: "Why on earth". "Possible at all".
>
> haha, thanks, Enrique, sorry for my poor English
Oh, your English is quite good! Mine isn't perfect either. I just fell for the
temptation to hint at the question "why on earth do you need this... " in an
indirect way. Just like playing a small game with myself. :)
-Enrique
Unruh
>hi, everyone. i ran into by a problem recently.
>can i, by any mechanism, boot from a bootable ISO image on a hard
>disk(instead of burning it into a blank CD, and boot from CDROM)?
No. When you boot your system has no idea whatsoever about filesystems of
anything like that. It cannot find files. It cannot read directories. It
can read raw bytes off of numerically designated sectors of the disk (via
the bios). It cannot translate anything. In the case of floppies or cdroms
(which are treated as a floppy) the system loads the very first sectors
into memory jumps to them and continues. In the case of hard drives the
system loads certain sectors on the disk and jumps to the loaded bytes.
>for example, i have following ISOs on /dev/hda1:
>/
> -knoppix.iso;
> -slax.iso;
> -sarge-netinst.iso
>can i, at the bootloader stage(or any other stage), specify some ISO by
>path name, and then booting from it, just as if i have a real bootable
>CD in the CDROM? i have done some research into the knoppix 'bootfrom'
No.
>cheatcode, but it is for knoppix, only.
>is pervasive support of 'boot ISO on HD' possible theoretically?? are
>there any opensource project doing a similar job? any help would be
>appreciated! thanks.
There just is not enough room on the MBR to do anything fancy. Now, with
grub, which uses the bootloader to load up the second stage grub loader
which then takes over and loads up whatever else, one has more options, so
it may be theoretically possible.
> Robert.Lai
Unruh
>Thanks, Tauno.
>I have read the El Torito standard, but I couldn't quite catch it. :(
>I am not familiar with BIOS. What does "a BIOS addition" mean? Can
>normal
>programmers add some customized services into BIOS? or, it is just
No.
>pre-defined by the manufacturer?
It is predefined and burned in. You might be able to generate your own bios
image and burn it in (many are on eeproms) but if you screw up even a bit,
you throw away your computer and buy a new one. There is then no way back
in.
Peter T. Breuer
>>can i, at the bootloader stage(or any other stage), specify some ISO by
>>path name, and then booting from it, just as if i have a real bootable
>>CD in the CDROM? i have done some research into the knoppix 'bootfrom'
> No.
Actuallllllly ... if it is grub, he can use it to read the fs and boot
a kernel there, with appropriate arguments for his needs, BUT he won't
have grub, since grub is large enough (mini-o/s size) to need to have
been installed on the hard disk beforehand.
> There just is not enough room on the MBR to do anything fancy. Now, with
> grub, which uses the bootloader to load up the second stage grub loader
> which then takes over and loads up whatever else, one has more options, so
> it may be theoretically possible.
But one would have had to install grub on the hard disk first, which is
what he does not want. I think.
Peter
iforone
hi;
this seems to apply to your situation;
http://www.knoppix.net/wiki/Win_Partition
though i could be wrong