On Thu, Mar 22, 2012 at 02:02:26PM -0600, Orion Poplawski wrote:
On 03/22/2012 01:30 PM, Brendan Conoboy wrote:
On 03/22/2012 11:10 AM, Orion Poplawski wrote:
I started looking at:
http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu
VM starts okay in F16 with setsebool -P virt_use_execmem=on
But the image is a Fedora 12 system. Any updated images out there?
You should be able to use the F17 alpha 1 image. The pointer is it:
http://fedoraproject.org/wiki/Architectures/ARM
We'll have the document updated for this soon. I've set reply-to to the arm list since the responsible parties are all there.
Sorry, still very green with vm wrangling. How do I take the rootfs tarball and make a qemu image I can use with libvirt?
I've not actually tried it for this situation, but virt-make-fs can turn a tarball into a disk image.
http://libguestfs.org/virt-make-fs.1.html
Probably something like this:
virt-make-fs -s 1G -t ext3 -F raw --partition=mbr rootfs.tar disk.img
Rich.
I cannot get qemu-system-arm to boot any of our F17 kernels, but here's what I did anyway.
# Make a disk image:
$ wget 'http://fedora.roving-it.com/rootfs-f17-hfp-alpha1.tar.bz2' $ bunzip2 rootfs-f17-hfp-alpha1.tar.bz2 $ virt-make-fs -s 2G -t ext3 -F raw --partition=mbr rootfs-f17-hfp-alpha1.tar disk.img Formatting 'disk.img', fmt=raw size=2147483648 $ ll disk.img -rw-r--r--. 1 rjones rjones 2147483648 Mar 23 05:47 disk.img $ virt-filesystems -a disk.img --all --long -h Name Type VFS Label MBR Size Parent /dev/sda1 filesystem ext3 - - 2.0G - /dev/sda1 partition - - 83 2.0G /dev/sda /dev/sda device - - - 2.0G -
# Extract the kernels from the tarball:
$ tar tf rootfs-f17-hfp-alpha1.tar | less $ tar xf rootfs-f17-hfp-alpha1.tar ./boot/
# Try to boot it one of the kernels in the boot/ directory:
$ qemu-system-arm -m 256 -M versatilepb -kernel boot/vmlinuz-3.3.0-0.rc4.git3.1.fc17.armv7hl -initrd boot/initramfs-3.3.0-0.rc4.git3.1.fc17.armv7hl.img -hda disk.img -serial stdio -vga std Uncompressing Linux... done, booting the kernel.
It just hangs at this point using 100% CPU with no output. The other kernels don't even seem to get that far.
Rich.
El 23/03/12 01:19, Richard W.M. Jones escribió:
I cannot get qemu-system-arm to boot any of our F17 kernels, but here's what I did anyway.
# Make a disk image:
$ wget 'http://fedora.roving-it.com/rootfs-f17-hfp-alpha1.tar.bz2' $ bunzip2 rootfs-f17-hfp-alpha1.tar.bz2 $ virt-make-fs -s 2G -t ext3 -F raw --partition=mbr rootfs-f17-hfp-alpha1.tar disk.img Formatting 'disk.img', fmt=raw size=2147483648 $ ll disk.img -rw-r--r--. 1 rjones rjones 2147483648 Mar 23 05:47 disk.img $ virt-filesystems -a disk.img --all --long -h Name Type VFS Label MBR Size Parent /dev/sda1 filesystem ext3 - - 2.0G - /dev/sda1 partition - - 83 2.0G /dev/sda /dev/sda device - - - 2.0G -
# Extract the kernels from the tarball:
$ tar tf rootfs-f17-hfp-alpha1.tar | less $ tar xf rootfs-f17-hfp-alpha1.tar ./boot/
# Try to boot it one of the kernels in the boot/ directory:
$ qemu-system-arm -m 256 -M versatilepb -kernel boot/vmlinuz-3.3.0-0.rc4.git3.1.fc17.armv7hl -initrd boot/initramfs-3.3.0-0.rc4.git3.1.fc17.armv7hl.img -hda disk.img -serial stdio -vga std Uncompressing Linux... done, booting the kernel.
It just hangs at this point using 100% CPU with no output. The other kernels don't even seem to get that far.
Rich.
I have not tried fc17 yet, but I had the same problem with the fc15 rootfs at first. I eventually succeeded with this command line:
qemu-system-arm -nographic -M versatilepb -kernel boot/vmlinuz-2.6.42.2-1.fc15.armv5tel -initrd boot/initramfs-2.6.42.2-1.fc15.armv5tel.img -append "root=LABEL=rootfs console=ttyAMA0" -hda fedora-15-arm.vmdk -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=../qemu-ifup
The explanation:
The Fedora ARM kernel for fc15 (and possibly for fc17 too) does *not* make use of the emulated graphic device provided by qemu-system-arm. The device driver is not compiled as part of the kernel, but as a separate module, so there is no framebuffer device for the kernel to display anything. If you get root access to the machine through some other means, you can eventually modprobe the driver, and you will see some output. I think the parameter -vga std will do nothing to help, as this is probably x86-only.
To see the boot process, you need at least console=ttyAMA0 as a kernel commandline. If you do not use -nographic , then you can switch to the serial console output with Ctrl-Alt-[1,2,3]. I use -nographic to send the serial output to stdout and save on useless graphic windows. You will also need a login console in ttyAMA0. You can do this (at least on fc15) by mounting the final filesystem, and adding a symlink that represents the need to maintain a login console on ttyAMA0:
[palosanto@rpmbuild-arm getty.target.wants]$ ls -l /etc/systemd/system/getty.target.wants/serial-getty@ttyAMA0.service lrwxrwxrwx. 1 root root 41 mar 1 17:15 /etc/systemd/system/getty.target.wants/serial-getty@ttyAMA0.service -> /lib/systemd/system/serial-getty@.service
You also need the root=XXX parameter. If you label the root filesystem and use the standard initrd, then you can use the same label in the kernel parameter (root=LABEL=rootfs) . I used "rootfs" because that is the label in the default /etc/fstab in the fc15 filesystem.
If the kernel runs correctly, you should see the message "Uncompressing Linux... OK, booting the kernel" in the serial output of qemu-system-arm, followed by the boot process messages. If you see no "Uncompressing Linux", maybe armv7hl is the wrong kernel to use, and you should stick to armv5tel.
On Fri, Mar 23, 2012 at 10:33:24AM -0500, Alex Villacís Lasso wrote:
El 23/03/12 01:19, Richard W.M. Jones escribió:
I cannot get qemu-system-arm to boot any of our F17 kernels, but here's what I did anyway.
# Make a disk image:
$ wget 'http://fedora.roving-it.com/rootfs-f17-hfp-alpha1.tar.bz2' $ bunzip2 rootfs-f17-hfp-alpha1.tar.bz2 $ virt-make-fs -s 2G -t ext3 -F raw --partition=mbr rootfs-f17-hfp-alpha1.tar disk.img Formatting 'disk.img', fmt=raw size=2147483648 $ ll disk.img -rw-r--r--. 1 rjones rjones 2147483648 Mar 23 05:47 disk.img $ virt-filesystems -a disk.img --all --long -h Name Type VFS Label MBR Size Parent /dev/sda1 filesystem ext3 - - 2.0G - /dev/sda1 partition - - 83 2.0G /dev/sda /dev/sda device - - - 2.0G -
# Extract the kernels from the tarball:
$ tar tf rootfs-f17-hfp-alpha1.tar | less $ tar xf rootfs-f17-hfp-alpha1.tar ./boot/
# Try to boot it one of the kernels in the boot/ directory:
$ qemu-system-arm -m 256 -M versatilepb -kernel boot/vmlinuz-3.3.0-0.rc4.git3.1.fc17.armv7hl -initrd boot/initramfs-3.3.0-0.rc4.git3.1.fc17.armv7hl.img -hda disk.img -serial stdio -vga std Uncompressing Linux... done, booting the kernel.
It just hangs at this point using 100% CPU with no output. The other kernels don't even seem to get that far.
Rich.
I have not tried fc17 yet, but I had the same problem with the fc15 rootfs at first. I eventually succeeded with this command line:
qemu-system-arm -nographic -M versatilepb -kernel boot/vmlinuz-2.6.42.2-1.fc15.armv5tel -initrd boot/initramfs-2.6.42.2-1.fc15.armv5tel.img -append "root=LABEL=rootfs console=ttyAMA0" -hda fedora-15-arm.vmdk -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=../qemu-ifup
The explanation:
The Fedora ARM kernel for fc15 (and possibly for fc17 too) does *not* make use of the emulated graphic device provided by qemu-system-arm. The device driver is not compiled as part of the kernel, but as a separate module, so there is no framebuffer device for the kernel to display anything. If you get root access to the machine through some other means, you can eventually modprobe the driver, and you will see some output. I think the parameter -vga std will do nothing to help, as this is probably x86-only.
To see the boot process, you need at least console=ttyAMA0 as a kernel commandline. If you do not use -nographic , then you can switch to the serial console output with Ctrl-Alt-[1,2,3]. I use -nographic to send the serial output to stdout and save on useless graphic windows. You will also need a login console in ttyAMA0. You can do this (at least on fc15) by mounting the final filesystem, and adding a symlink that represents the need to maintain a login console on ttyAMA0:
[palosanto@rpmbuild-arm getty.target.wants]$ ls -l /etc/systemd/system/getty.target.wants/serial-getty@ttyAMA0.service lrwxrwxrwx. 1 root root 41 mar 1 17:15 /etc/systemd/system/getty.target.wants/serial-getty@ttyAMA0.service -> /lib/systemd/system/serial-getty@.service
You also need the root=XXX parameter. If you label the root filesystem and use the standard initrd, then you can use the same label in the kernel parameter (root=LABEL=rootfs) . I used "rootfs" because that is the label in the default /etc/fstab in the fc15 filesystem.
If the kernel runs correctly, you should see the message "Uncompressing Linux... OK, booting the kernel" in the serial output of qemu-system-arm, followed by the boot process messages. If you see no "Uncompressing Linux", maybe armv7hl is the wrong kernel to use, and you should stick to armv5tel.
I still can't get any Fedora 17 kernel (soft or hard FP) to boot on qemu-system-arm, on either F17/x86_64 or F17/arm host.
On x86-64 it just consumes 100% of CPU, no console, no video, never touches the disk image. On ARM host, qemu-system-arm crashes in TCG.
In fact, I have never once got qemu-system-arm to do anything useful, despite trying over many years.
Rich.
On 04/28/2012 08:21 AM, Richard W.M. Jones wrote:
I still can't get any Fedora 17 kernel (soft or hard FP) to boot on qemu-system-arm, on either F17/x86_64 or F17/arm host.
On x86-64 it just consumes 100% of CPU, no console, no video, never touches the disk image. On ARM host, qemu-system-arm crashes in TCG.
In fact, I have never once got qemu-system-arm to do anything useful, despite trying over many years.
Peter is currently cleaning up the kernel configurey which will ultimately result in a versatile express kernel. We'll be testing with it and use it with qemu for producing a new image, documentation, etc. Suggest waiting a few days while this gets worked out.
On 05/01/2012 05:14 PM, Brendan Conoboy wrote:
On 04/28/2012 08:21 AM, Richard W.M. Jones wrote:
I still can't get any Fedora 17 kernel (soft or hard FP) to boot on qemu-system-arm, on either F17/x86_64 or F17/arm host.
On x86-64 it just consumes 100% of CPU, no console, no video, never touches the disk image. On ARM host, qemu-system-arm crashes in TCG.
In fact, I have never once got qemu-system-arm to do anything useful, despite trying over many years.
Peter is currently cleaning up the kernel configurey which will ultimately result in a versatile express kernel. We'll be testing with it and use it with qemu for producing a new image, documentation, etc. Suggest waiting a few days while this gets worked out.
That's really good news. I'm looking forward to trying it.
Andrew.