Qemu, kqemu or kvm?

What are the differences between the qemu, kqemu and kvm packages in the extra repo? Currently I'm using qemu with -kernel-kvm, is there any difference?

Nice 8)
btw: qemu is perfect to test liveCD images created with larch2 (see my sig)...

Similar Messages

Qemu, Kqemu, Kvm

I have recently started using the QEMU-launcher from the community repo. I am running Arch64 on an AMD Athlon 64 X2 6000+, emulating M$ Windows XP. I am wondering if I should use the QEMU accelerator, KQEMU, or KVM. From what I saw on the arch wiki about KVM, it looks like I need an i686... but I am using Arch64 on an AMD64... Also.... it looked like KQEMU is also just for i686... does anyone know? Also, if they are both good for Arch64, which one should I use, or should I use both? Please forgive me; I am a bit of a newbie, but I thought I should post this here as it pertains to workstation. Thanks in advance!

Nice 8)
btw: qemu is perfect to test liveCD images created with larch2 (see my sig)...

Qemu/kqemu in Arch ?

Looks like our devs got permission to distribute kqemu, and now we have qemu+kqemu in extra.
Sweeeet

Nice 8)
btw: qemu is perfect to test liveCD images created with larch2 (see my sig)...

Qemu+kqemu+winxp = crash

WinXP without kqemu works, but slow.
With kqemu it hangs on logo.
I boot it this way:
qemu -hda /dev/sda
(or file copied from /dev/sda)

Nice 8)
btw: qemu is perfect to test liveCD images created with larch2 (see my sig)...

Qemu with kvm is very, very slow

Hi!
I first installed kvm by following http://wiki.archlinux.org/index.php/Kvm
And I also tried the "using qemu with kvm support" method from http://wiki.archlinux.org/index.php/QEMU
With both methods, a VM is very, very slow (when i start an iso, you literally see it render the things, and after that when you get the grub menu, it takes ages for the pointer to move if you press the arrow keys).
I'm on a Dell laptop with Intel C2D cpu with VT support (and enabled in bios, I checked)
[dieter@dieter-dellD620-arch ~]$ egrep '^flags.*(vmx|svm)|model name' /proc/cpuinfo
model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow
model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow
[dieter@dieter-dellD620-arch ~]$ lsmod | egrep 'qemu|vbox|kvm'
kvm_intel 43752 0
kvm 169896 1 kvm_intel
[dieter@dieter-dellD620-arch ~]$ cat /etc/udev/rules.d/65-kvm.rules
KERNEL=="kvm", NAME="%k", GROUP="kvm", MODE="0660"
[dieter@dieter-dellD620-arch ~]$ ls -alh /dev/kvm
crw-rw---- 1 root kvm 10, 232 2009-07-18 17:12 /dev/kvm
[dieter@dieter-dellD620-arch ~]$ grep kvm /etc/group
kvm:x:78:dieter
anyone an idea?

damjan wrote:
try qemu-kvm-0.10.5, it's the stable qemu with additional kvm support:
http://sourceforge.net/projects/kvm/fil … z/download
also, in the qemu monitor you can check to see if kvm is used with "info kvm" .. should return "kvm support: enabled"
finally, the grub menu is using old BIOS APIs and cpu pooling since it's running in 16bit mode with no drivers. It uses up 100% of one of my cores when I leave a VM on the grub menu. Make sure you run a serious OS soon and check performance there.
Thanks
- i am using 0.10.5 (this is the version that Arch has packaged)
- it says kvm enabled, and you're right, once it goes out of grub, it goes much faster!
- apparently my keyboard arrows are just plainly being ignored

Kqemu doesn't accelerate qemu anymore under kernel 2.6.21

Up until a few days ago I still ran Arch with kernel 2.6.18-Arch #1 SMP. Qemu 0.9.0-1 with kqemu worked like a champ on that system when testing Linux live CD ISO's; the live CD ISO's ran at almost half the native speed on the virtual machine. At the time when I installed qemu + kqemu (April 07), the only binary kqemu module available in extra was for kernel 2.6.20. Hence, I compiled kqemu myself from source for 2.6.18. This kqemu module was working very well in accelerating qemu.
Then, a few days ago, I did a big 'pacman -Syu' which upgraded the kernel to 2.6.21. Qemu is still at v.0.9.0-1 but kqemu in extra comes compiled for kernel 2.6.21. This kqemu module doesn't work: it appears to be inserted into the kernel (e.g. I don't get the error "Could not open '/dev/kqemu'") but it doesn't provide any acceleration, i.e. there is no difference at all between running qemu with or without the command line parameter '-kernel-kqemu'. It runs incredibly slowly, so slowly as to be useless (if it even makes it to fully booting to the Desktop; often it freezes somewhere in the boot process). The same problem holds for a kqemu module that I compiled myself from source for kernel 2.6.21.
I'm using all the same configs that I used in the previous (functional) install, i.e.:
1. running qemu as follows:
$ qemu -cdrom /mnt/sdb2/home/robert/LinuxMint-3.0.iso -hda qemulinux.img -m 256 -boot d -kernel-kqemu
2. /etc/modprobe.conf has the line
options kqemu major=0
3. added an entry to /etc/sysctl.conf to set the system timer to 1024 Hz:
dev.rtc.max-user-freq=1024
4. or tried the same thing as #3 by running '# echo 1024 > /proc/sys/dev/rtc/max-user-freq'
One thing that seems to be different after the system upgrade is how or whether the system timer is set. E.g. I now always get the following error when I run qemu as under #1:
Error: Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal
error, but for better emulation accuracy either use a 2.6 host Linux kernel or
type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root.
However the latter file doesn't exist anymore, i.e. after typing the above line:
# cat /proc/sys/dev/rtc/max-user-freq
cat: /proc/sys/dev/rtc/max-user-freq: No such file or directory
How do I fix this problem of kqemu not working properly under the new kernel?
Robert

retsaw wrote:Perhaps this is related to the tickless kernel feature that was introduced in the 2.6.21 kernel. Try adding "nohz=off" to your kernel command line and reboot.
I tried that, i.e. by adding the line
append="nohz=off"
to the Arch entry in my LILO. It didn't make any difference.

Kvm: qemu with option "-enable-kvm" or kvm-84 from AUR?

whats the difference between the two? Which one should be preferred?
thanks!

Yeah, my bad. The patches to qemu would come from upstream KVM, like they did before. Avi Kivity, not Tobias. My mistake there.
And yeah, I think some of those distinctions are us using different semantics. I'd call the qemu implementation that Avi maintains a fork -- but that is different to me than, as you worded it, kvm being a fork of qemu. When saying "kvm" and referring to a chunk of code, not what I'll call for this conversation's sake "the kvm project," has always referred to the kvm module -- the kernel code, again hence the name. Back when the userspace code was just a set of patches to qemu, this confusion was rarer. (Even after the kvm project started maintaining their own version of the code, they also maintained the qemu patch set to apply to the qemu project -- their version was just qemu, pre-patched. Avi discusses that philosophy of modifying the original code as little as possible in his most recent blog a few months ago.) The kvm userspace code is -- again, by Avi's own description -- qemu and libkvm. (http://www.linux-kvm.org/page/Code - "The kvm userspace code (libkvm and qemu) is available through a git tree.") kvm-the-project does maintain a prepatched qemu, but that doesn't make it kvm's code -- particularly when kvm's intent all along was to have their patches accepted by qemu, which they now have. So while you can say that kvm-the-project has within it a build of qemu -- and if you wanted, you could even call it a fork, though the maintainer declines to use the term -- qemu is not kvm.
I'd also add that though the gray area there exists, from a future-discussion perspective it does make things a lot clearer if we refer to kvm the module, the "pure" build of qemu, and kvm's qemu build (or qemu-kvm) as separate.
And by extension, no, kvm-userspace has not reached 10.0.0. There's a reason that the kvm userspace code just has build numbers. Its version number is 85. It would make a lot of sense to say that the kvm-maintained patches were modified and applied to qemu upstream to make qemu 10.0.0, but the post-10 stability patches for kvm were applied independently to qemu and qemu-kvm -- qemu-kvm basically getting just kvm-related stability patches, which are submitted upstream to qemu (and thus qemu-kvm moving up in build number), and qemu using the qemu-kvm patches as well as patches relating to other parts of the system.
Getting back to the meat of the question, it is important to note that the kvm we're getting from the arch package is NOT the kvm that you would get from building the download file. You called it clean, and you're absolutely right -- it's *too* clean. Download the KVM package from sourceforge, build, and do a make -n install; you get:
make -C kernel DESTDIR="" install
make -C libkvm DESTDIR="" install
make -C qemu DESTDIR="" install
Which makes sense if you read their docs -- the KVM build, as per KVM, come as a (independent of the kernel) set of modules and a QEMU build to go with those modules, just like it was before it was accepted by linux-kernel. (You could probably have noticed that kernel modules were being build when you run make, but there was so much stuff in there that I thought it easier to cut/paste the install phase for clarity.) The Arch PKGBUILD, however, just compiles qemu-kvm and its necessary libraries:
for dir in libkvm user qemu extboot; do
cd ${srcdir}/kvm-${pkgver}/${dir}
make || return 1
done
and then hand-installs those components without the kernel modules meant to go with it. Unless the package builder knows something the KVM developer doesn't, I wouldn't go around using that qemu build with whatever KVM module version from whatever different kernel version you may have willy-nilly.
If I had the hankering to run the KVM maintained userspace stuff, I'd do what they said and run their kernel stuff too. I think a proper KVM build should do that. But that's not my call, since I'm not the extra maintainer. As it stands, for me I'd rather use the in-kernel version, which I think will get the kernel-side patches that the KVM project's kernel code gets anyway since there is so much attention on the kernel, but also has the benefit of the qemu userspace code getting bug fixes from the qemu devs themselves. It sounded to me like that was the direction kvm itself was moving. But to each their own, of course. I'd just say better to stick all the way with one or all the way with the other method, and not just start making hybrids without a much deeper knowledge of the code than I think any of us have.
Last edited by slinkygn (2009-05-04 02:11:30)

QEMU on Arch64?

Am I going mad, I cannot find a Qemu package when I do a pacman -Qs qemu , however the wiki refers to a qemu package and x86_64 in the same article which implies there is one ( http://wiki.archlinux.org/index.php/Qemu ) [intention to use Qemu with the kvm modules in the .22 kernel]

Note: the following applies to the 32-bit architecture; I don't know how much of this applies to Arch64.
The new kernel 2.6.22 comes with the modules kvm, kvm-intel and kvm-amd. They are in /lib/modules/2.6.22-ARCH/kernel/drivers/kvm/ . And when you install qemu, you get both qemu and qemu-kvm.
All you have to do is
1. Enable virtualization technology in your BIOS.
2. # modprobe kvm-intel (or kvm-amd if you're using an AMD CPU; this loads both kvm-intel/amd and kvm)
3. $ qemu-kvm -cdrom /home/joe/Desktop/SabayonLinux-x86-3.4a.iso -hda qemulinux.img -m 256 -boot d
(that's just an example)
There are some permissions problems when you run qemu-kvm as an ordinary user. The fix for these is in slubman's post from yesterday:
http://bbs.archlinux.org/viewtopic.php?id=35539
I've just about given up on qemu with kernel 2.6.22, using either the kqemu or the kvm full virtualization. They seem to be very flaky with this kernel.
qemu ran beautifully with kqemu under kernel 2.6.18. I've used close to 20 different ISO images of Linux live CD's that ran well under these circumstances. With the upgrade to kernel 2.6.21 & 22 (and possibly the introduction of the tickless clock timer) qemu hangs with 75% of these images, regardless of whether you use kvm or kqemu.
When qemu-kvm works, it's great. It runs Linux/Unix guest OS's almost at native speed. E.g. this works with MCNLive-Toronto, MCNLive-Delft, BeaFanaTIX 2006.2, FreesBIE 2.0.1, DesktopBSD 1.6, RIPLinuX, and Puppy 2.17, but not with a dozen other Linux distros that worked with the older kernel.
I'd be curious to learn how qemu-kvm works for you. For now, I'm investing my time in learning how to use Virtualbox.
Robert

[community] major changes to qemu

Following discussion in this thread I have now addressed the qemu "situation". Here is a basic rundown from the other thread:
The Situation
OK - let me clarify the situation pkg wise:
qemu - in [community]: built without support of the kernel module kqemu
kqemu - in UNSUPPORTED: builds both qemu and kqemu but according to stonecrest this kernel module won't work
kqemu26 - removed from UNSUPPORTED: was supposed to install kernel module for qemu pkg but qemu pkg does have support for it.
The Solution:
kqemu cannot be distibuted as a binary. I will rebuild qemu in [community] using the kqemu PKGBUILD (should I use the patches?) but will not install the kernel module (last 4 lines). This will makedepends=('gcc<=3.4.3')
I will then remove kqemu from UNSUPPORTED and create a new pkg called kqemu that will be == with the old kqemu26 PKGBUILD.
kqemu will depend=('qemu') and will build against the running kernel - this will not be distributed as a binary.
What you need to know
If you currently have qemu, kqemu or kqemu26 installed I strongly suggest you remove them and begin from scratch as it was not possible to rely on conflicts and replaces commands in the PKGBUILDS. Simply install qemu from [community]
pacman -S qemu
Then download the kqemu tarball and use makepkg to create the kernel module for you running kernel. It does build against gcc4!
I have tested the new qemu pkg on my home system. I installed it, booted into kernel A and built the kqemu module - ran qemu and confirmed kqemu was enabled. I then removed kqemu, booted kernel B and built kqemu again. I then installed and tested in the same way and it worked perfectly. I did not need to use modprobe -f as I had previously.
So, there is no longer a PKGBUILD in the AUR that installs qemu and kqemu all in one. According to some this PKGBUILD did not work anyway (see thread linked above).
Remaining Issues
· I am not certain the PKGBUILDs are the greatest - I had to pretty much guess how they worked without spending even more time fixing it - if you have suggestions to tidy them up they are warmly welcomed.
· qemu needs to be moved from community/system to community/emulators, as I understand it this cannot be done by a regular TU remotely and must actually be moved in the cvsroot to maintain the file history.
· The qemu PKGBUILD does uses patches that apparently allow you to build it against gcc4 - can someone confirm this?
I hope this solution is to everyones satisfaction

Yup, thanks all, I checked myself too!
qemu updated to -4, built against gcc4
Give it a few mins to gensync tho, it's only going up now
Answers to 1 and 2 anyone?

How to use KQemu?

Uhh... What's all the stuff about disk images in the help file? Is it possible to just *use* this program like Dosemu or DOSbox, or do I have to do all sorts of bizarre stuff to do anything with it?

Here what I get from dmesg when I compile the modified PKGBUILD FROM aur:
kqemu: disagrees about version of symbol struct_module
Inbound IN=eth0 OUT= MAC=00:04:75:b6:5d:fb:00:85:a0:01:01:00:08:00 SRC=192.168.1.1 DST=192.168.1.2 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=8344 PROTO=UDP SPT=137 DPT=137 LEN=58
kqemu: module license 'unspecified' taints kernel.
kqemu: Unknown symbol __PAGE_KERNEL_EXEC
and this is my modified PKGBUILD fro 0.7.1
# Contributor: Tomas Groth (tgc) <[email protected]>
pkgname=kqemu
pkgver=0.7.1
pkgrel=2
pkgdesc="The QEMU Accelerator Module increases the speed of QEMU when a PC is emulated on a PC. Binary distribution is not allowed."
conflicts=("qemu")
install=kqemu.install
url="http://fabrice.bellard.free.fr/qemu/"
source=(http://fabrice.bellard.free.fr/qemu/qemu-0.7.1.tar.gz
http://fabrice.bellard.free.fr/qemu/kqemu-0.7.1.tar.gz)
depends=('sdl' 'xorg')
build() {
cd $startdir/src/qemu-0.7.1
# mv ../kqemu .
mv $startdir/src/kqemu .
sed -i s%sdl_config --static-libs%sdl_config --libs% configure
./configure --prefix=/usr
make || return 1
sed -i s%/usr%$startdir/pkg/usr% config-host.mak
# disable the kqemu install, we'll do that our own way...
echo " " > kqemu/install.sh
make prefix=$startdir/pkg/usr install
# install the kqemu kernel module
cd kqemu
if [ -f kqemu.ko ] ; then
module=kqemu.ko
else
module=kqemu.o
fi
# Find kernel install path
kernel_path="$startdir/pkg/lib/modules/`uname -r`"
mkdir -p "$kernel_path/misc"
cp "$module" "$kernel_path/misc"
md5sums=('b0c80d2c082049a5b8ccbc7f55fe165b' '8fc7967492b2157521198f6639218420')

Best way to run M$ windows apps on linux ?

hi everyone,
i plan on getting rid of my windows partitions. but that's big deal because i need to run a few (exotic) programs that are made for windows. i need to find a way to use them in linux, be it through a windows emulator or a computer emulator (or whatever).
please don't tell me to find linux equivalents to these programs i need to run, there's just nothing similar on linux.
on some of those programs i need audio to work.
so far i tried wine, qemu (with kqemu), and a combination of qemu and vmplayer (kind of "free" vmware).
my feelings are the following :
- wine improved A LOT during the past year (i really mean it), but my programs are a little buggy (at best). that does not make the usable for day to day use.
- qemu is sooooo slooooow it is barely usable. it took me 4 hours to get a working installation of windows xp (ok, i was multitasking, but still. for the first time ever my system swapped - could this be a memory leak ?)
- qemu + kqemu is toooo sloooooow as well (i suppose when they say near-native speed, it means 1/10 to 1/2 of native speed)... i've been very very disapointed.
- on qemu (and kqemu) i haven't tried the programs i need yet, the windows install process finished too late in the night...
- qemu + vmplayer : qemu is used to generate an image which is then used by vmplayer. i used this trick on gentoo once, and i can tell you this was the best solution i tried so far. usable speed, functional programs. but i didn't achieve to get the sound workind (might need a bit of tuning).
apart from those ones, do you know of usable solutions to get windows apps running on linux ? i need them to just works at reasonable speed, with audio, and, if possible, printing.
any tricks that could improve speed or compatibility are appreciated as well.
tia

vmware-server isnt 'for server emulation' but that can be one of it's uses.
vmware player doesnt allow you to create vm's. vmware server does. vmware server is able to do *almost* anything that vmware desktop can do. It's got the added benefit that if X crashes, or you close the frontend X app, the vm's still keep running on the daemon.
So it could be considered to be oriented towards usage for servers - I myself ran a openbsd server on it for a while. -- but it doesnt have to be used for that, and I use it for testing other distros, and I have Win XP installed to an image too.
vmware server does support sound, and im pretty sure you can make images that will work in vmplayer.
James

Mouse first perfect, then suddenly gets sluggish as if USB had lag.

Hardware:
Acer 5742G laptop, (aspire and travelmate 5742G have exact same mainboard), with i5 CPU and and Nvidia GT540M.
It has Optimus graphics.
Mouse is primarily Roccat Kone+ via USB, but the same happens with 7 other usb-mice, too.
Software:
Arch with latest kernel from official repo, laptop mode tools installed and Bumblebee with Intel+Nvidia and Intel+Noveau with their multilib counterparts.
Cinnamon Desktop with no kde tools installed. xf86-input-mouse installed.
Problem:
If I put in the mouse it works perfectly for a while, but suddenly the cursor is very sluggish, hard to move and laggy.
Mouse-Dpi is on 6000, sensitivity is highest.
After it happened every mouse that will be connected will be slow directly.
After a reboot the mice will be fast again for a while.
USB-Keyboards and Harddrives have the issue too, just tested.
Dmesg cutout:
I think its related
http://pastebin.com/kcpAQHdF
Last edited by PaellaGrindIron (2014-04-07 12:57:15)

andy123 wrote:
Hi, do you have the newest BIOS/UEFI/firmware installed? Are there any usb related settings in said firmware?
I (used to?) experience a problem similar to what you describe on my desktop machine. My theory is, that is occurs because I use some of my usb controllers with the usb drivers ({o,e}hci_{hcd,pci}) and the rest with vfio-pci for passthrough with qemu and kvm. However, I'm unsure when it happened the last time.
"Resetting" the usb stack solved it for me, at least temporary
#!/bin/sh
for mod in {o,e}hci_pci xhci_hcd usbhid # this might need adjustment, e.g. if you don't have usb3, use usb webcams, sound, etc.
do modprobe -rv $mod
done
for mod in usbhid {o,e}hci_{hcd,pci} xhci_hcd
do modprobe -v $mod
done
I'm sorry I'm a relative newbie, so this doesn't seem obvious to me but I'm supposed to run the script host or emulated side? running it host side returned fatal errors and I'm not quite sure how to run it emulated side. My naive attempt was typing it out in cmd entirely in one line.
My windows qemu no longer has any mouse. though I used to have one and I didn't change the terminal command to run it:
qemu-system-x86_64 -boot menu=on -bios /usr/share/qemu/bios.bin-kvm -vga qxl -m 4G -cpu host -smp 12,sockets=1,cores=6,threads=2 -soundhw hda -usb -device usb-kbd -device usb-mouse -name "test_vfio_pci" -M q35 -device ahci,id=ahci -drive file=/media/t/TBVolume/win8.qcow2,id=disk,format=qcow2 -device ide-hd,bus=ahci.0,drive=disk
If I remove the usb device for the mouse run it then add it back and run it again will this help?
EDIT : bizarely removing the emulated usb mouse *gives me* a mouse.
I don't know why.
Last edited by tatsu (2014-12-03 07:25:20)

Arch Linux first impressions

Hello all,
I have just recently decided to try arch linux. For a long while I have been running my own LinuxFromScratch system, but I have been looking for a little while for a nice KDE based system *with package management*.
So here I am now with an Arch KDE 3.5.6 system - what do I think?
1. KDE looks real nice! Fonts look very good.
2. nvidia drivers were simple to install and work as advertised, same ~6000fps under glxgears as under LFS
3. rc.conf, MODULES, DAEMONS, nice and simple!
4. pacman -S? Very nice. I got caught as a newbie when I didn't do a pacman -Sy before an update, and tried to pull down out-of-date files. Perhaps pacman -S could note that my synch was n weeks ago and warn?
5. Beginners Guide on the wiki. Very useful step by step to a KDE desktop.
6. All apps installed and work well, k3b, wesnoth, flashplugin, kmail, konq browsing, qemu + kqemu etc
The not so good
1. Twice now I have had a udev error on first boot into arch. Second boot it goes away. I put it down to my windows dual boot leaving some hardware in a dubious state. If I see it again I'll note the exact error message.
2. For some reason KDE 3.5.6 is not quite so snappy as on LFS. I can watch it paint as windows come up for the first time. Nothing major though.
3. modules & groups. It really sucks to get tripped up on missing modules (floppy) and groups (storage). Its my hardware let me use it by default I say!
4. ping myhostname returns unknown host. A little strange I think.
5. media mounting (usb key, floppy, cdrom) as my user seems a little flakey. Permissions problems preventing "safe removal" of the usb key etc.
TODO:
1. OpenOffice (although this seems to be 2.04 via pacman, perhaps I'll wait for 2.1 to arrive)
2. More learning about Arch....
A nice system thus far, this Arch Linux...
Dale

dale77 wrote:
codemac wrote:for #4 under the not so good, did you edit your /etc/hosts to reflect your host name?
Yes, that is what I did to fix it. I guess I would have expected the arch install to handle that detail.
Dale
It's a feature, not a bug. As a general rule you cannot count on the Arch installer to do any extra configuration tasks. It offers you the chance to edit the hosts file during setup.

Archiso problem

Hi
I'm trying to make my own specific Arch installation disk via archiso from [extra]. But I have stumbled upon a problem. When I try to boot the medium I get a Kernel Panic:
[img=http://img99.imageshack.us/img99/6912/archliveerrorik9.th.png]
I build the iso via this command:
$ mkarchiso -v all ./archlive ./archlive.iso
...<snip>
It seems to build correctly until at the end:
====> Making bootable image
Generating initcpio for image...
:: Begin build
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [boot-cd]
:: Parsing hook [archiso]
:: Parsing hook [ide]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [usb]
:: Parsing hook [fw]
:: Parsing hook [filesystems]
:: Generating module dependencies
WARNING: Couldn't open directory /tmp/mkinitcpio.HQAas6/lib/modules/2.6.28-ARCH: No such file or directory
FATAL: Could not open /tmp/mkinitcpio.HQAas6/lib/modules/2.6.28-ARCH/modules.dep.temp for writing: No such file or directory
ERROR: file '/tmp/mkinitcpio.HQAas6/lib/modules/2.6.28-ARCH/modules.dep' does not exist
ERROR: file '/tmp/mkinitcpio.HQAas6/lib/modules/2.6.28-ARCH/modules.alias' does not exist
ERROR: file '/tmp/mkinitcpio.HQAas6/lib/modules/2.6.28-ARCH/modules.symbols' does not exist
:: Generating image './archlive/img/boot/archlive.img'...SUCCESS
Creating ISO image...
Size of boot image is 4 sectors -> No emulation
7.98% done, estimate finish Thu Jan 22 14:30:08 2009
15.93% done, estimate finish Thu Jan 22 14:30:08 2009
23.91% done, estimate finish Thu Jan 22 14:30:08 2009
31.86% done, estimate finish Thu Jan 22 14:30:08 2009
39.83% done, estimate finish Thu Jan 22 14:30:08 2009
47.78% done, estimate finish Thu Jan 22 14:30:08 2009
55.76% done, estimate finish Thu Jan 22 14:30:08 2009
63.71% done, estimate finish Thu Jan 22 14:30:08 2009
71.68% done, estimate finish Thu Jan 22 14:30:08 2009
79.63% done, estimate finish Thu Jan 22 14:30:09 2009
87.61% done, estimate finish Thu Jan 22 14:30:09 2009
95.56% done, estimate finish Thu Jan 22 14:30:10 2009
Total translation table size: 2048
Total rockridge attributes bytes: 4253
Total directory bytes: 13024
Path table size(bytes): 60
Max brk space used 0
62792 extents written (122 MB)
Notice the WARNING and ERROR? I'm not sure how I should solve that.
Anyone?

I can confirm the same result is also present when booting the iso via qemu (+kqemu) and vmware server 1.0.7 (on winxp). That's a good capture... I didn't notice the earlier error you did. I am also searching for the answer.

[SOLVED] The gummiboot package modifies the source. How?

I was trying to get the gummiboot package to compile properly with the ABS when I ran into this bug.
I found it odd since I was able to compile gummiboot from source, I dug a bit deeper and found a tiny difference in the Makefile.am:
$ diff ~/abs/gummiboot/src/gummiboot/Makefile.am ~/gummiboot/Makefile.am
87a88
> -std=gnu90 \
108c109
< $(EFI_LDLAGS) \
> $(EFI_LDFLAGS) \
197c198
< $(QEMU) -machine accel=kvm -m 256 -bios $(QEMU_BIOS) -snapshot test-disk.img
> $(QEMU) -machine accel=kvm -m 1024 -bios $(QEMU_BIOS) -snapshot test-disk.img
Aha! So the gummiboot source needs to be compiled with the -std=gnu90 flag!
Well that seems to fix the compilation issues, but it left me wondering. How exactly does this file change? Both Makefiles are presumably from git://anongit.freedesktop.org/gummiboot, but the ABS version modifies it slightly? The PKGBUILD file seems harmless enough.
Can someone explain this to me?
Last edited by Slabity (2015-06-16 19:07:36)

Raynman wrote:
Slabity wrote:Both Makefiles are presumably from git://anongit.freedesktop.org/gummiboot
Don't presume, check the PKGBUILD. It checks out a version that was tagged before these changes were made.
See also http://cgit.freedesktop.org/gummiboot/
Ahh, damn. That was a lot simpler than I was expecting.

Qemu, kqemu or kvm?

Similar Messages

Maybe you are looking for