We don't currently have an install tree for Fedora on aarch64.
However I was able to build one using the following command:
sudo \
PATH=./src/sbin/:$PATH \
PYTHONPATH=./src/ \
./src/sbin/lorax \
-p Fedora -v 21 -r 21 --variant=Fedora \
--mirrorlist='http://mirrors.fedoraproject.org/metalink?repo=fedora-21&arch=aarch64' \
-s 'https://archive.fedoraproject.org/pub/fedora-secondary/development/rawhide/aarch64/os/' \
/tmp/tree
Notes:
(1) The version of lorax in Fedora is buggy -- I forget the exact
error now -- so I used lorax from git, hence all the PATH/PYTHONPATH
settings.
(2) This builds the tree into /tmp/tree which you then need to copy to
a web server.
This boots further under virt-install -l http://server/path/to/tree
but then I hit an anaconda^W blivet bug. It seems to assume that
aarch64 is always EFI, which is not the case in our VMs:
https://bugzilla.redhat.com/show_bug.cgi?id=1128341
----------------------------------------------------------------------
Let's instead try Plan B ...
I create a Fedora chroot using yum. Copy the attached yum.conf into
/tmp/chroot/etc/yum.conf and do:
sudo \
yum \
-c /tmp/chroot/etc/yum.conf \
--installroot=/tmp/chroot \
--disablerepo=\* --enablerepo=rawhide \
groupinstall "Minimal Install"
sudo \
yum \
-c /tmp/chroot/etc/yum.conf \
--installroot=/tmp/chroot \
--disablerepo=\* --enablerepo=rawhide \
install kernel dracut
For me that installs 44 packages. I had some download failures, but
you can just restart the commands and they will keep going where they
left off.
Now turn that into a disk image using libguestfs. I'm using a host
logical volume to store the guest but you could just as easily use a
local raw/qcow2 file:
guestfish -a /dev/vg_ssd/f21 <<EOF
run
# Make the partition table:
part-init /dev/sda gpt
part-add /dev/sda p 2048 2097151
part-add /dev/sda p 2097152 4194303
part-add /dev/sda p 4194304 -2048
# Make the filesystems:
mke2fs /dev/sda3 fstype:ext4 label:root
mke2fs /dev/sda1 fstype:ext4 label:boot
mkswap /dev/sda2
# Mount them up:
mount /dev/sda3 /
mkdir /boot
mount /dev/sda1 /boot
# Copy the chroot filesystem in:
copy-in /tmp/chroot/. /
# Create an /etc/fstab
write /etc/fstab "LABEL=root / ext4 defaults 1 1\nLABEL=boot /boot ext4 defaults 1 2\n"
EOF
That won't actually be bootable. Because grub2 on aarch64 assumes the
machine always has EFI, and I haven't yet got EFI working in my VM, in
the meantime I'm going to boot using an external kernel and initrd (I
know this works because it's how libguestfs runs VMs).
You can use `virt-builder' to pull out the kernel & initrd from the
disk image:
$ virt-builder --get-kernel /dev/vg_ssd/f21
download: /boot/vmlinuz-3.16.0-1.fc22.aarch64 -> ./vmlinuz-3.16.0-1.fc22.aarch64
download: /boot/initramfs-3.16.0-1.fc22.aarch64.img -> ./initramfs-3.16.0-1.fc22.aarch64.img
Copy the kernel and initrd to a more permanent place.
Create the guest using the attached XML (you'll need to edit it a bit):
virsh define /tmp/f21.xml
virsh start f21
virsh console f21
To set the root password, use virt-customize (*note* only when the
machine is shut down!):
virt-customize -d f21 --root-password password:123456
Virt-customize is also useful to do things like fix the SELinux
labelling, install more packages and so on. I had to offline edit a
few configuration files before I could log in.
----------------------------------------------------------------------
Next steps:
- Find out how to get EFI working in VMs so we can use the
regular path to installation.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
# This is the default, if you make this bigger yum won't see if the metadata
# is newer on the remote and so you'll "gain" the bandwidth of not having to
# download the new metadata and "pay" for it by yum not having correct
# information.
# It is esp. important, to have correct metadata, for distributions like
# Fedora which don't keep old packages around. If you don't like this checking
# interupting your command line usage, it's much better to have something
# manually check the metadata once an hour (yum-updatesd will do this).
# metadata_expire=90m
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
[rawhide]
name=Fedora Rawhide
baseurl=http://download.fedoraproject.org/pub/fedora-secondary/development/rawhide/aarch64/os
enabled=1
gpgcheck=0
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
