6:11 p.m.
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
1:19 a.m.
New subject: 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 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.
--
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
10:33 a.m.
New subject: 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 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\(a)ttyAMA0.service
lrwxrwxrwx. 1 root root 41 mar 1 17:15
/etc/systemd/system/getty.target.wants/serial-getty(a)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.
10:21 a.m.
New subject: 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 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\(a)ttyAMA0.service
lrwxrwxrwx. 1 root root 41 mar 1 17:15
/etc/systemd/system/getty.target.wants/serial-getty(a)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
11:14 a.m.
New subject: 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. / blc(a)redhat.com
11:15 a.m.
New subject: 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.
4371
days inactive
4411
days old
5 comments
4 participants
participants (4)
-
Alex Villacís Lasso -
Andrew Haley -
Brendan Conoboy -
Richard W.M. Jones