Re: [fedora-arm] Updated Fedora ARM qemu images?
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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Updated Fedora ARM qemu images?
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 TypeVFS 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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Updated Fedora ARM qemu images?
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 TypeVFS 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. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Updated Fedora ARM qemu images?
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 TypeVFS 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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Updated Fedora ARM qemu images?
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. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Updated Fedora ARM qemu images?
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. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm