Re: booting from ISO image on HD?

On Sat, 14 Jan 2006 16:04:55 +0100, laota <laota.zju@xxxxxxxxx> wrote:

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
.

Relevant Pages

  • Re: booting from ISO image on HD?
    ... bootable ISO image should have exactly the same performances as booting ... That is, kernel image, modules, application programs and so ... >> through customized initrd files for each one. ... you can boot the kernel of your ...
    (comp.os.linux.misc)
  • Re: booting from ISO image on HD?
    ... I'm not going to write the pivot root script, ... > through customized initrd files for each one. ... I have to insmod the loop kernel module(e.g. ... The idea is that either you build what you need to boot into your ...
    (comp.os.linux.misc)
  • Re: booting from ISO image on HD?
    ... >> through customized initrd files for each one. ... > between the loopback device and the underlying file (the iso image). ... I have to insmod the loop kernel module(e.g. ... how can you boot it from an initrd??? ...
    (comp.os.linux.misc)
  • Re: [SOLVED] incredible solution Re: install of fedora FC4 with ASUS mobo
    ... after it tells u it cant find an image just press enter to boot normally ... The message you told about is the initrd that is being loaded. ... that, the kernel has been loaded, but not yet started. ... The CD too has a boot loader, ...
    (comp.os.linux.setup)
  • Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1?
    ... I've tried to make a new 7.1-BETA bootable ISO from the ... box to build a 7.x kernel though. ... However I'm unable to umount it! ... I'm now downloading a 7.1-BETA-livefs ISO and I'll try next to boot ...
    (freebsd-stable)