[Qemu-devel] QEMU with KNOPPIX

[Qemu-devel] QEMU with KNOPPIX

[Kuniyasu Suzaki]

Dear,

We released new Japanese KNOPPIX that includes QEMU/Windows and QEMU/Linux.

The QEMU/Widows can run KNOPPIX with KNOPPIX-CD only. It doesn't need
to install, because KNOPPIX can boot from CD-ROM on QEMU. Furthermore
it doesn't require Administrator. It is very convenient. The detail is 
described in the following URL.
    http://unit.aist.go.jp/it/knoppix/qemu/index-en.html

If you boot KNOPPIX from CD-ROM, you can use QEMU/Linux from KDE-Menu.
You can set up network environment with "/etc/qemu/QEMU-network-enabler.sh" 
command on KNOPPIX/QEMU.

Iso image is downloadable from following URL.
    ftp://ring.aist.go.jp/pub/linux/knoppix/iso/knoppix_v3.4_20040517-20040820.iso
    http://ring.aist.go.jp/pub/linux/knoppix/iso/knoppix_v3.4_20040517-20040820.iso
Bittorrent is also available.
    http://http://unit.aist.go.jp/it/knoppix/knoppix_v3.4_20040517-20040820.iso.torrent 
    MD5: d872effcc85721e663b7afd0d0076a17

Have fun. :-)

------
suzaki

Re: [Qemu-devel] QEMU with KNOPPIX

[John R. Hogerhuis]

On Wed, 2004-08-25 at 00:09, Kuniyasu Suzaki wrote:
> Dear,
> 
> We released new Japanese KNOPPIX that includes QEMU/Windows and QEMU/Linux.
> 

Great work! Somebody finally did it (many have threatened)... This will
become the perfect way to ease users into Linux. Between this and user
mode networking, any Windows user without even administrative rights
should be able to pop up Linux on any given machine.

-- John.

Re: [Qemu-devel] QEMU with KNOPPIX

[Kuniyasu Suzaki]

 >>From: "John R. Hogerhuis" <jhoger@pobox.com>
 >>Subject: Re: [Qemu-devel] QEMU with KNOPPIX
 >>
 >>On Wed, 2004-08-25 at 00:09, Kuniyasu Suzaki wrote:
 >>> 
 >>> We released new Japanese KNOPPIX that includes QEMU/Windows and QEMU/Linux.
 >>
 >>Great work! Somebody finally did it (many have threatened)... This will
 >>become the perfect way to ease users into Linux. Between this and user
 >>mode networking, any Windows user without even administrative rights
 >>should be able to pop up Linux on any given machine.
 >>
 >>-- John.

Thank you, but I just in inculde QEMU to KNOPPIX. Main work is done by
"QEMU on Windows".
    http://www.h7.dion.ne.jp/~qemu-win/index.html

I want to propose "QEMU on Windows" to include original KNOPPIX. I
just post a message to KNOPPIX forum/idea.
   http://www.knoppix.net/forum/viewtopic.php?t=12858

If you have any suggestions, please post.

------
suzaki

Re: [Qemu-devel] QEMU with KNOPPIX

[John R. Hogerhuis]

On Wed, 2004-08-25 at 22:19, Kuniyasu Suzaki wrote:

> If you have any suggestions, please post.

Need to think of some ways to speed it up. It took several minutes to
load.

Where are the possible optimizations?

Could we do a "save state" type operation and jump straight to loaded
Knoppix desktop?

Seems to be a lot of CDROM activity. That is the nature of Knoppix, and
that definitely slows Knoppix down, but for some reason it sounded
really choppy to me. I'm wondering if there is anything we can do to
speed up cd access. Maybe on a machine with a lot of RAM it could be
read into RAM, or perhaps just copied to hard drive in one step and run
from there. Some or all apps could be decompressed. I think Knoppix has
something like this.

It's a complex set up, but some profiling might be in order... see how
well QEMU translation cache is performing, and see if there is a lot of
time spent in certain types of code that could be sped up in QEMU.


I agree with you that Kazu's recent QEMU on Windows was indeed the heavy
lifting, but there's still plenty to do on (Knoppix On (QEMU On
Windows)) to make it really usable. Which I think it can be, and on some
machines maybe it already is...

-- John.

Re: [Qemu-devel] QEMU with KNOPPIX

[Kuniyasu Suzaki]

Thank you for your good response.

 >>From: "John R. Hogerhuis" <jhoger@pobox.com>
 >>Subject: Re: [Qemu-devel] QEMU with KNOPPIX
 >>
 >>On Wed, 2004-08-25 at 22:19, Kuniyasu Suzaki wrote:
 >>
 >>> If you have any suggestions, please post.
 >>
 >>Need to think of some ways to speed it up. It took several minutes to
 >>load.
 >>
 >>Where are the possible optimizations?

One idea is to cancel auto-configuration of KNOPPIX because QEMU has
fixed devices. For example,
   boot: knoppix noscsi nousb nopcmcia lang=us screen=800x600 desktop=wmaker

To use light desktop-manager is another key point, because KDE is heavy.

 >>Could we do a "save state" type operation and jump straight to loaded
 >>Knoppix desktop?

This ides sound nice, because it is resemble to my research topic. :-)
   Network Transferable Computer.
   http://staff.aist.go.jp/k.suzaki/English/NTC/

 >>Seems to be a lot of CDROM activity. That is the nature of Knoppix, and
 >>that definitely slows Knoppix down, but for some reason it sounded
 >>really choppy to me. I'm wondering if there is anything we can do to
 >>speed up cd access. Maybe on a machine with a lot of RAM it could be
 >>read into RAM, or perhaps just copied to hard drive in one step and run
 >>from there. Some or all apps could be decompressed. I think Knoppix has
 >>something like this.

Yes, root File System of KNOPPIX is stored to a compressed loop-back
device. It is called "CLOOP". KNOPPIX has boot option to move CLOOP file
to hard disk or RAM disk. It takes time to boot, but response makes
better.

But I think the option is not valuable on QEMU. It makes slow boot on QEMU.
To make short-cut of boot is most important.

 >>It's a complex set up, but some profiling might be in order... see how
 >>well QEMU translation cache is performing, and see if there is a lot of
 >>time spent in certain types of code that could be sped up in QEMU.
 >>
 >>
 >>I agree with you that Kazu's recent QEMU on Windows was indeed the heavy
 >>lifting, but there's still plenty to do on (Knoppix On (QEMU On
 >>Windows)) to make it really usable. Which I think it can be, and on some
 >>machines maybe it already is...

------
suzaki

Re: [Qemu-devel] QEMU with KNOPPIX

[John R. Hogerhuis]

On Thu, 2004-08-26 at 00:57, Kuniyasu Suzaki wrote:

> Yes, root File System of KNOPPIX is stored to a compressed loop-back
> device. It is called "CLOOP". KNOPPIX has boot option to move CLOOP file
> to hard disk or RAM disk. It takes time to boot, but response makes
> better.
> 
> But I think the option is not valuable on QEMU. It makes slow boot on QEMU.
> To make short-cut of boot is most important.
> 

How long does it take to transfer the CLOOP file to hard disk?

I would think that you could do it just once, say and drop it in My
Documents, or wherever the user wants, with a pointer to the file in the
registry. Don't have the virtual machine do it (that's slow), have the
script that starts QEMU copy the file to the host's hard disk before
running QEMU. Also put a version number there. Then read some version
number off the Knoppix disk... if they match, and the file is already on
the hard drive don't copy it again. So you get a one-time hit, for
hopefully a big performance gain and the user won't see it again until a
new version of knoppix-qemu-win comes out (BTW, what is a good name for
this? kqw? something short... I actually registered a domain when I
thought of this possibility sometime back, "linsitu" if that makes any
sense to anyone...)

Might be a cool, general way to do this transparently in QEMU. What if
there was a option/feature in QEMU, that as it reads from a CD-ROM, it
builds a cache of it on the hard disk. Maybe it saves some unique info
from cd, and the hash for some random blocks. Then when QEMU is started
again with the same disk, it hashes those blocks and decides whether it
already has cached any/all of that cd on hard disk. If it has it reads
from cache of that cd on hard disk. Then you would have something that
could work with any bootable linux cd without any tweaking.

But booting a suspended image will probably save a lot of time so either
one is worth some focus.

I don't think the QEMU engine itself is off the hook either. There are
definitely things that could be squeezed there, the question is, is
there any low-hanging fruit which would provide a measurable performance
gain...

-- John.

Re: [Qemu-devel] QEMU with KNOPPIX

[Johannes Schindelin]

Hi,

On Thu, 26 Aug 2004, Kuniyasu Suzaki wrote:
>  >>From: "John R. Hogerhuis" <jhoger@pobox.com>
>  >>Could we do a "save state" type operation and jump straight to loaded
>  >>Knoppix desktop?

Last time I checked with Win98, the network state wouldn't be
reinitialized. So, everything but network was okay after loadvm. I think
it has to do with slirp's DHCP state not being saved, but I didn't have
time to check up on that.

Ciao,
Dscho

Re: [Qemu-devel] QEMU with KNOPPIX

[Piotr Krysik]

Hi,

Probably a lot of CPU is spend on decompressing 
in CLOOP driver. Maybe it could be possible to 
do decompression natively and not under emulated 
CPU.

You can start with an exercise. Setup CLOOP on 
your host (e.g. run Knoppix natively), then run 
another Knoppix inside Qemu, but give it access 
to your CLOOP device as an ide drive:
  qemu ... -cdrom /dev/cdrom -hda /dev/<your cloop>
Now try to use your host cloop device inside Qemu. 
E.g. mount it instead of guest cloop:
  mount ... /dev/hda <guest cloop mount point>
Play with it. If the performance difference 
is substantial, it may justify extra effort 
to implement cloop compatible Qemu disk format 
(I guess qcow is not compatible with cloop), 
so it can be used on Windows.

I didn't try this, so cannot guarantee that it 
will work. Contact me if you would like to try 
this and need assistance.


Regards,

Piotrek

--- "John R. Hogerhuis" <jhoger@pobox.com> wrote:

> On Wed, 2004-08-25 at 22:19, Kuniyasu Suzaki wrote:
> 
> > If you have any suggestions, please post.
> 
> Need to think of some ways to speed it up. It took
> several minutes to
> load.
> 
> Where are the possible optimizations?
> 
> Could we do a "save state" type operation and jump
> straight to loaded
> Knoppix desktop?
> 
> Seems to be a lot of CDROM activity. That is the
> nature of Knoppix, and
> that definitely slows Knoppix down, but for some
> reason it sounded
> really choppy to me. I'm wondering if there is
> anything we can do to
> speed up cd access. Maybe on a machine with a lot of
> RAM it could be
> read into RAM, or perhaps just copied to hard drive
> in one step and run
> from there. Some or all apps could be decompressed.
> I think Knoppix has
> something like this.
> 
> It's a complex set up, but some profiling might be
> in order... see how
> well QEMU translation cache is performing, and see
> if there is a lot of
> time spent in certain types of code that could be
> sped up in QEMU.
> 
> 
> I agree with you that Kazu's recent QEMU on Windows
> was indeed the heavy
> lifting, but there's still plenty to do on (Knoppix
> On (QEMU On
> Windows)) to make it really usable. Which I think it
> can be, and on some
> machines maybe it already is...
> 
> -- John.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 




		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Re: [Qemu-devel] QEMU with KNOPPIX

[Johannes Schindelin]

Hi,

On Thu, 26 Aug 2004, Piotr Krysik wrote:
>
> Probably a lot of CPU is spend on decompressing
> in CLOOP driver. Maybe it could be possible to
> do decompression natively and not under emulated
> CPU.

This sounds like a good test case for the new hd image abstraction
layer... Does the layer include the abstraction for cdroms?

Ciao,
Dscho

Re: [Qemu-devel] QEMU with KNOPPIX

[Kuniyasu Suzaki]

 >>From: "John R. Hogerhuis" <jhoger@pobox.com>
 >>Subject: Re: [Qemu-devel] QEMU with KNOPPIX
 >>
 >>On Thu, 2004-08-26 at 00:57, Kuniyasu Suzaki wrote:
 >>
 >>> But I think the option is not valuable on QEMU. It makes slow boot on QEMU.
 >>> To make short-cut of boot is most important.
 >>
 >>How long does it take to transfer the CLOOP file to hard disk?
 >>
 >>I would think that you could do it just once, say and drop it in My
 >>Documents, or wherever the user wants, with a pointer to the file in the
 >>registry. Don't have the virtual machine do it (that's slow), have the
 >>script that starts QEMU copy the file to the host's hard disk before
 >>running QEMU. Also put a version number there. Then read some version

Excuse me. My explanation looks bad. KNOPPIX on QEMU/Windows boot with
iso image. QEMU cann't boot KNOPPIX from CLOOP directly.

The current version of "KNOPPIX on QEMU/Windows" is not smart. 
  >qemu.exe -L . -m 128 -boot a -fda qemu-boot.img -hda \\.\d -hdachs 1407,16,63 -user-net -enable-audio -localtime

The bad points are following.
 1. We have to prepare DF boot image "qemu-boot.img".
 2. The current QEMU/Windows can to use "-cdrom \\.\d" option.
    We have to use "-hda \\.\d-hdachs 1407,16,63" option.

The desirable option is the following.
  >qemu.exe -L . -m 128 -boot d -cdrom \\.\d -user-net -enable-audio -localtime

One key point of KNOPPIX with QEMU/Windows is that it boots form
CD-ROM. It does not require hard disk.

Anyway I want to speed up the boot time. The short-cut by taking
snapshot-of-boot makes it possible.

 >>number off the Knoppix disk... if they match, and the file is already on
 >>the hard drive don't copy it again. So you get a one-time hit, for
 >>hopefully a big performance gain and the user won't see it again until a
 >>new version of knoppix-qemu-win comes out (BTW, what is a good name for
 >>this? kqw? something short... I actually registered a domain when I
 >>thought of this possibility sometime back, "linsitu" if that makes any
 >>sense to anyone...)
 >>
 >>Might be a cool, general way to do this transparently in QEMU. What if
 >>there was a option/feature in QEMU, that as it reads from a CD-ROM, it
 >>builds a cache of it on the hard disk. Maybe it saves some unique info
 >>from cd, and the hash for some random blocks. Then when QEMU is started
 >>again with the same disk, it hashes those blocks and decides whether it
 >>already has cached any/all of that cd on hard disk. If it has it reads
 >>from cache of that cd on hard disk. Then you would have something that
 >>could work with any bootable linux cd without any tweaking.
 >>
 >>But booting a suspended image will probably save a lot of time so either
 >>one is worth some focus.
 >>
 >>I don't think the QEMU engine itself is off the hook either. There are
 >>definitely things that could be squeezed there, the question is, is
 >>there any low-hanging fruit which would provide a measurable performance
 >>gain...
 >>
 >>-- John.

------
suzaki

Re: [Qemu-devel] QEMU with KNOPPIX

[Kuniyasu Suzaki]

 >>From: Piotr Krysik <piotrek_priv@yahoo.com>
 >>Subject: Re: [Qemu-devel] QEMU with KNOPPIX
 >>
 >>Hi,
 >>
 >>Probably a lot of CPU is spend on decompressing 
 >>in CLOOP driver. Maybe it could be possible to 
 >>do decompression natively and not under emulated 
 >>CPU.
 >>
 >>You can start with an exercise. Setup CLOOP on 
 >>your host (e.g. run Knoppix natively), then run 
 >>another Knoppix inside Qemu, but give it access 
 >>to your CLOOP device as an ide drive:
 >>  qemu ... -cdrom /dev/cdrom -hda /dev/<your cloop>
 >>Now try to use your host cloop device inside Qemu. 

Yes, this idea might be effective on QEMU/Linux.
Same idea is used on user-mode-linux of our KNOPPIX.
   http://unit.aist.go.jp/it/knoppix/uml/index-en.html

But we cann't mount CLOOP file on Windows.

 >>E.g. mount it instead of guest cloop:
 >>  mount ... /dev/hda <guest cloop mount point>
 >>Play with it. If the performance difference 
 >>is substantial, it may justify extra effort 
 >>to implement cloop compatible Qemu disk format 
 >>(I guess qcow is not compatible with cloop), 
 >>so it can be used on Windows.
 >>
 >>I didn't try this, so cannot guarantee that it 
 >>will work. Contact me if you would like to try 
 >>this and need assistance.
 >>
 >>
 >>Regards,
 >>
 >>Piotrek

------
suzaki

Re: [Qemu-devel] QEMU with KNOPPIX

[Piotr Krysik]

Hi,

It can work in Windows, if you implement support 
of cloop-compatible image format in Qemu executable.

Just look at qcow compressed image format. Qemu 
doesn't require any additional services from host 
OS. The decompression is implemented by Qemu and 
is transparent for guest.

The example I gave is meant to help you evaluate 
benefits before starting implementation of cloop 
image format for Qemu.


Regards,

Piotrek

--- Kuniyasu Suzaki <k.suzaki@aist.go.jp> wrote:
>  >>From: Piotr Krysik <piotrek_priv@yahoo.com>
>  >>Subject: Re: [Qemu-devel] QEMU with KNOPPIX
>  >>
>  >>Hi,
>  >>
>  >>Probably a lot of CPU is spend on decompressing 
>  >>in CLOOP driver. Maybe it could be possible to 
>  >>do decompression natively and not under emulated 
>  >>CPU.
>  >>
>  >>You can start with an exercise. Setup CLOOP on 
>  >>your host (e.g. run Knoppix natively), then run 
>  >>another Knoppix inside Qemu, but give it access 
>  >>to your CLOOP device as an ide drive:
>  >>  qemu ... -cdrom /dev/cdrom -hda /dev/<your
> cloop>
>  >>Now try to use your host cloop device inside
> Qemu. 
> 
> Yes, this idea might be effective on QEMU/Linux.
> Same idea is used on user-mode-linux of our KNOPPIX.
>   
> http://unit.aist.go.jp/it/knoppix/uml/index-en.html
> 
> But we cann't mount CLOOP file on Windows.
> 
>  >>E.g. mount it instead of guest cloop:
>  >>  mount ... /dev/hda <guest cloop mount point>
>  >>Play with it. If the performance difference 
>  >>is substantial, it may justify extra effort 
>  >>to implement cloop compatible Qemu disk format 
>  >>(I guess qcow is not compatible with cloop), 
>  >>so it can be used on Windows.



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: [Qemu-devel] QEMU with KNOPPIX

[Johannes Schindelin]

Hi,

On Fri, 27 Aug 2004, Piotr Krysik wrote:
>
> It can work in Windows, if you implement support
> of cloop-compatible image format in Qemu executable.
>
> Just look at qcow compressed image format. Qemu
> doesn't require any additional services from host
> OS. The decompression is implemented by Qemu and
> is transparent for guest.

Hint: for space reasons, the cloop image is an ISO9660 formatted Linux
system, so you probably have to have an ISO9660 enabled (not module)
kernel, and you probably have to specify the kernel separately via
"-kernel", as the cloop image (at least to my knowledge) does not contain
a valid boot loader.

Ciao,
Dscho

Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1239 bytes --]

Hi,

On Fri, 27 Aug 2004, Johannes Schindelin wrote:

> On Fri, 27 Aug 2004, Piotr Krysik wrote:
> >
> > It can work in Windows, if you implement support
> > of cloop-compatible image format in Qemu executable.
> >
> > Just look at qcow compressed image format. Qemu
> > doesn't require any additional services from host
> > OS. The decompression is implemented by Qemu and
> > is transparent for guest.
>
> Hint: for space reasons, the cloop image is an ISO9660 formatted Linux
> system, so you probably have to have an ISO9660 enabled (not module)
> kernel, and you probably have to specify the kernel separately via
> "-kernel", as the cloop image (at least to my knowledge) does not contain
> a valid boot loader.

Okay, so I hacked together a driver which is able to read at least the
newest Knoppix image (from 3.6EN).

Only problem: When you start it with

qemu -hda /cdrom/KNOPPIX/KNOPPIX \
  -kernel /cdrom/boot/isolinux/linux24 \
  -initrd /cdrom/boot/isolinux/minirt24.gz \
  -append root=/dev/hda

Knoppix believes it runs from the HD (installed version) and does not
recreate /etc/fstab, and then just stops.

Any Knoppix hackers out there? Maybe one can trick Knoppix into recreating
all these files nontheless?

Ciao,
Dscho

[-- Attachment #2: Type: APPLICATION/x-gunzip, Size: 3020 bytes --]

Re: Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX

[Juergen Lock]

On Fri, Aug 27, 2004 at 08:01:14PM +0000, Johannes Schindelin wrote:

> Okay, so I hacked together a driver which is able to read at least the
> newest Knoppix image (from 3.6EN).
> 
> Only problem: When you start it with
> 
> qemu -hda /cdrom/KNOPPIX/KNOPPIX \
>   -kernel /cdrom/boot/isolinux/linux24 \
>   -initrd /cdrom/boot/isolinux/minirt24.gz \
>   -append root=/dev/hda
> 
> Knoppix believes it runs from the HD (installed version) and does not
> recreate /etc/fstab, and then just stops.

Well... If you look at /cdrom/boot/isolinux/isolinux.cfg you can see the
APPEND lines it uses, e.g.
	APPEND ramdisk_size=100000 init=/etc/init lang=de apm=power-off vga=791 initrd=minirt24.gz nomce quiet BOOT_IMAGE=knoppix

 So it starts /etc/init inside the initrd, which calls /linuxrc.
You'll have to hack that to mount /KNOPPIX uncompressed from hda
instead of via cloop from /cdrom/KNOPPIX/KNOPPIX, and maybe pass
-cdrom /dev/cdrom to qemu too as it also mounts that to /cdrom.

 HTH,
	Juergen

Re: Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX

[Fabrice Bellard]

I'll merge your cloop patch ASAP.

Fabrice.

Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 27 Aug 2004, Johannes Schindelin wrote:
> 
> 
>>On Fri, 27 Aug 2004, Piotr Krysik wrote:
>>
>>>It can work in Windows, if you implement support
>>>of cloop-compatible image format in Qemu executable.
>>>
>>>Just look at qcow compressed image format. Qemu
>>>doesn't require any additional services from host
>>>OS. The decompression is implemented by Qemu and
>>>is transparent for guest.
>>
>>Hint: for space reasons, the cloop image is an ISO9660 formatted Linux
>>system, so you probably have to have an ISO9660 enabled (not module)
>>kernel, and you probably have to specify the kernel separately via
>>"-kernel", as the cloop image (at least to my knowledge) does not contain
>>a valid boot loader.
> 
> 
> Okay, so I hacked together a driver which is able to read at least the
> newest Knoppix image (from 3.6EN).
> 
> Only problem: When you start it with
> 
> qemu -hda /cdrom/KNOPPIX/KNOPPIX \
>   -kernel /cdrom/boot/isolinux/linux24 \
>   -initrd /cdrom/boot/isolinux/minirt24.gz \
>   -append root=/dev/hda
> 
> Knoppix believes it runs from the HD (installed version) and does not
> recreate /etc/fstab, and then just stops.
> 
> Any Knoppix hackers out there? Maybe one can trick Knoppix into recreating
> all these files nontheless?
> 
> Ciao,
> Dscho
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU with KNOPPIX

[Fabrice Bellard]

John R. Hogerhuis wrote:
> On Wed, 2004-08-25 at 22:19, Kuniyasu Suzaki wrote:
> 
> 
>>If you have any suggestions, please post.
> 
> 
> Need to think of some ways to speed it up. It took several minutes to
> load.
> 
> Where are the possible optimizations?
> 
> Could we do a "save state" type operation and jump straight to loaded
> Knoppix desktop?

Doing a save state and a restore state is  a very good idea. The KNOPPIX 
"boot" would be instantaneous. The current load/save code is almost 
ready to do that. There are still problems with timers, PCI and network, 
but it should be easy to solve.

Fabrice.

Re: [Qemu-devel] QEMU with KNOPPIX

[Kuniyasu Suzaki]

 >>From: Fabrice Bellard <fabrice@bellard.org>
 >>Subject: Re: [Qemu-devel] QEMU with KNOPPIX
 >>
 >>Doing a save state and a restore state is  a very good idea. The KNOPPIX 
 >>"boot" would be instantaneous. The current load/save code is almost 
 >>ready to do that. There are still problems with timers, PCI and network, 
 >>but it should be easy to solve.

It sounds nice! Short-cut of boot time on KNOPPIX is most desirable.

It's perfect if it can be reusalbe on QEMU/Linux and QEMU/Windows.
Our Japanese KNOPPIX includes both QEMU. :-)

------
suzaki

Re: Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX

[Johannes Schindelin]

Hi,

On Fri, 27 Aug 2004, Juergen Lock wrote:

> On Fri, Aug 27, 2004 at 08:01:14PM +0000, Johannes Schindelin wrote:
>
> > Knoppix believes it runs from the HD (installed version) and does not
> > recreate /etc/fstab, and then just stops.
>
> Well... If you look at /cdrom/boot/isolinux/isolinux.cfg you can see the
> APPEND lines it uses, e.g.
> 	APPEND ramdisk_size=100000 init=/etc/init lang=de apm=power-off vga=791 initrd=minirt24.gz nomce quiet BOOT_IMAGE=knoppix
>
>  So it starts /etc/init inside the initrd, which calls /linuxrc.
> You'll have to hack that to mount /KNOPPIX uncompressed from hda
> instead of via cloop from /cdrom/KNOPPIX/KNOPPIX, and maybe pass
> -cdrom /dev/cdrom to qemu too as it also mounts that to /cdrom.

Yes, I was aware of Knoppix running inside a ramdisk which mounts the
cloop image. My question should have been more like: "does anybody have a
good idea how to actually *use* the now available read-only HD image?"

Thinking about it, maybe the easiest method would be to modify the initial
ramdisk so it does not mount the cloop device, but /dev/hda (note: this is
no partition, i.e. not /dev/hda1, but /dev/hda). That should work nicely.

In other news, I was been told that http://www.topologilinux.com/ has a
coLinux-System on the Live CD, so in order to demonstrate Linux, you could
include that...

Ciao,
Dscho

coLinux and Re: Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX

[Kuniyasu Suzaki]

Hi,

 >>From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
 >>Subject: Re: Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX
 >>
 >>In other news, I was been told that http://www.topologilinux.com/ has a
 >>coLinux-System on the Live CD, so in order to demonstrate Linux, you could
 >>include that...

Interesting. :-)
Our Japanese KNOPPIX includes coLinux.
    http://unit.aist.go.jp/it/knoppix/colinux/index-en.html

Topologilinux is a linux which boot from NTFS/FAT of Windows2000/XP.
Our Japanese KNOPPIX has same function. It also includes "install2win.bat" 
batch file to install KNOPPIX to NTFS/FAT of Windows2000/XP.
    http://unit.aist.go.jp/it/knoppix/win/index-en.html

It uses boot loader "grubinstall.exe" to boot linux on
NTFS/FAT. "grubinstall.exe" is also used on topologilinux.
   http://www.geocities.com/lode_leroy/grubinstall/

------
suzaki