* [Qemu-devel] QEMU with KNOPPIX
@ 2004-08-25 7:09 Kuniyasu Suzaki
2004-08-25 10:02 ` John R. Hogerhuis
0 siblings, 1 reply; 20+ messages in thread
From: Kuniyasu Suzaki @ 2004-08-25 7:09 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-25 7:09 [Qemu-devel] QEMU with KNOPPIX Kuniyasu Suzaki @ 2004-08-25 10:02 ` John R. Hogerhuis 2004-08-26 5:19 ` Kuniyasu Suzaki 0 siblings, 1 reply; 20+ messages in thread From: John R. Hogerhuis @ 2004-08-25 10:02 UTC (permalink / raw) To: qemu-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-25 10:02 ` John R. Hogerhuis @ 2004-08-26 5:19 ` Kuniyasu Suzaki 2004-08-26 6:13 ` John R. Hogerhuis 0 siblings, 1 reply; 20+ messages in thread From: Kuniyasu Suzaki @ 2004-08-26 5:19 UTC (permalink / raw) To: qemu-devel >>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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-26 5:19 ` Kuniyasu Suzaki @ 2004-08-26 6:13 ` John R. Hogerhuis 2004-08-26 7:57 ` Kuniyasu Suzaki ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: John R. Hogerhuis @ 2004-08-26 6:13 UTC (permalink / raw) To: qemu-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-26 6:13 ` John R. Hogerhuis @ 2004-08-26 7:57 ` Kuniyasu Suzaki 2004-08-26 9:34 ` John R. Hogerhuis 2004-08-26 11:41 ` Johannes Schindelin 2004-08-26 12:56 ` Piotr Krysik 2004-08-27 22:40 ` Fabrice Bellard 2 siblings, 2 replies; 20+ messages in thread From: Kuniyasu Suzaki @ 2004-08-26 7:57 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-26 7:57 ` Kuniyasu Suzaki @ 2004-08-26 9:34 ` John R. Hogerhuis 2004-08-27 5:58 ` Kuniyasu Suzaki 2004-08-26 11:41 ` Johannes Schindelin 1 sibling, 1 reply; 20+ messages in thread From: John R. Hogerhuis @ 2004-08-26 9:34 UTC (permalink / raw) To: qemu-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-26 9:34 ` John R. Hogerhuis @ 2004-08-27 5:58 ` Kuniyasu Suzaki 0 siblings, 0 replies; 20+ messages in thread From: Kuniyasu Suzaki @ 2004-08-27 5:58 UTC (permalink / raw) To: qemu-devel >>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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-26 7:57 ` Kuniyasu Suzaki 2004-08-26 9:34 ` John R. Hogerhuis @ 2004-08-26 11:41 ` Johannes Schindelin 1 sibling, 0 replies; 20+ messages in thread From: Johannes Schindelin @ 2004-08-26 11:41 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-26 6:13 ` John R. Hogerhuis 2004-08-26 7:57 ` Kuniyasu Suzaki @ 2004-08-26 12:56 ` Piotr Krysik 2004-08-26 15:49 ` Johannes Schindelin 2004-08-27 6:06 ` Kuniyasu Suzaki 2004-08-27 22:40 ` Fabrice Bellard 2 siblings, 2 replies; 20+ messages in thread From: Piotr Krysik @ 2004-08-26 12:56 UTC (permalink / raw) To: Kuniyasu Suzaki; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-26 12:56 ` Piotr Krysik @ 2004-08-26 15:49 ` Johannes Schindelin 2004-08-27 6:06 ` Kuniyasu Suzaki 1 sibling, 0 replies; 20+ messages in thread From: Johannes Schindelin @ 2004-08-26 15:49 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-26 12:56 ` Piotr Krysik 2004-08-26 15:49 ` Johannes Schindelin @ 2004-08-27 6:06 ` Kuniyasu Suzaki 2004-08-27 8:35 ` Piotr Krysik 1 sibling, 1 reply; 20+ messages in thread From: Kuniyasu Suzaki @ 2004-08-27 6:06 UTC (permalink / raw) To: qemu-devel >>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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-27 6:06 ` Kuniyasu Suzaki @ 2004-08-27 8:35 ` Piotr Krysik 2004-08-27 10:08 ` Johannes Schindelin 0 siblings, 1 reply; 20+ messages in thread From: Piotr Krysik @ 2004-08-27 8:35 UTC (permalink / raw) To: Kuniyasu Suzaki; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-27 8:35 ` Piotr Krysik @ 2004-08-27 10:08 ` Johannes Schindelin 2004-08-27 17:00 ` Cloop-Driver, was " Johannes Schindelin 0 siblings, 1 reply; 20+ messages in thread From: Johannes Schindelin @ 2004-08-27 10:08 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-27 10:08 ` Johannes Schindelin @ 2004-08-27 17:00 ` Johannes Schindelin 2004-08-27 20:40 ` Juergen Lock 2004-08-27 22:32 ` Fabrice Bellard 0 siblings, 2 replies; 20+ messages in thread From: Johannes Schindelin @ 2004-08-27 17:00 UTC (permalink / raw) To: qemu-devel [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-27 17:00 ` Cloop-Driver, was " Johannes Schindelin @ 2004-08-27 20:40 ` Juergen Lock 2004-08-29 13:52 ` Johannes Schindelin 2004-08-27 22:32 ` Fabrice Bellard 1 sibling, 1 reply; 20+ messages in thread From: Juergen Lock @ 2004-08-27 20:40 UTC (permalink / raw) To: Johannes Schindelin; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-27 20:40 ` Juergen Lock @ 2004-08-29 13:52 ` Johannes Schindelin 2004-08-30 4:32 ` coLinux and " Kuniyasu Suzaki 0 siblings, 1 reply; 20+ messages in thread From: Johannes Schindelin @ 2004-08-29 13:52 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* coLinux and Re: Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-29 13:52 ` Johannes Schindelin @ 2004-08-30 4:32 ` Kuniyasu Suzaki 0 siblings, 0 replies; 20+ messages in thread From: Kuniyasu Suzaki @ 2004-08-30 4:32 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Cloop-Driver, was Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-27 17:00 ` Cloop-Driver, was " Johannes Schindelin 2004-08-27 20:40 ` Juergen Lock @ 2004-08-27 22:32 ` Fabrice Bellard 1 sibling, 0 replies; 20+ messages in thread From: Fabrice Bellard @ 2004-08-27 22:32 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-26 6:13 ` John R. Hogerhuis 2004-08-26 7:57 ` Kuniyasu Suzaki 2004-08-26 12:56 ` Piotr Krysik @ 2004-08-27 22:40 ` Fabrice Bellard 2004-08-28 3:53 ` Kuniyasu Suzaki 2 siblings, 1 reply; 20+ messages in thread From: Fabrice Bellard @ 2004-08-27 22:40 UTC (permalink / raw) To: jhoger, qemu-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] QEMU with KNOPPIX 2004-08-27 22:40 ` Fabrice Bellard @ 2004-08-28 3:53 ` Kuniyasu Suzaki 0 siblings, 0 replies; 20+ messages in thread From: Kuniyasu Suzaki @ 2004-08-28 3:53 UTC (permalink / raw) To: qemu-devel >>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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2004-08-30 4:37 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-08-25 7:09 [Qemu-devel] QEMU with KNOPPIX Kuniyasu Suzaki 2004-08-25 10:02 ` John R. Hogerhuis 2004-08-26 5:19 ` Kuniyasu Suzaki 2004-08-26 6:13 ` John R. Hogerhuis 2004-08-26 7:57 ` Kuniyasu Suzaki 2004-08-26 9:34 ` John R. Hogerhuis 2004-08-27 5:58 ` Kuniyasu Suzaki 2004-08-26 11:41 ` Johannes Schindelin 2004-08-26 12:56 ` Piotr Krysik 2004-08-26 15:49 ` Johannes Schindelin 2004-08-27 6:06 ` Kuniyasu Suzaki 2004-08-27 8:35 ` Piotr Krysik 2004-08-27 10:08 ` Johannes Schindelin 2004-08-27 17:00 ` Cloop-Driver, was " Johannes Schindelin 2004-08-27 20:40 ` Juergen Lock 2004-08-29 13:52 ` Johannes Schindelin 2004-08-30 4:32 ` coLinux and " Kuniyasu Suzaki 2004-08-27 22:32 ` Fabrice Bellard 2004-08-27 22:40 ` Fabrice Bellard 2004-08-28 3:53 ` Kuniyasu Suzaki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).