How to create custom installer for Vision Five 2 Riscv SBC with Fedora Silverblue

Am I correct to believe virt-builder/kickstart files are the equivalent to create custom installer images?

virt-builder was mentioned in here which is where I discovered it:

I saw the riscv koji builder using kickstart files:
Is that right virt-builder uses kickstart .ks files as part of each virt-builder image template listed?

Ideally it would be awesome to see the Vision Five 2 listed with its own virt-builder image template. I’m investigating how to go about that.

There’s a fedora 33(NOT SILVERBLUE) image for Vision Five 1, but there isn’t anything available yet for Vision Five 2.
Is it possible to create a virt-build image template of Fedora Silverblue 37 based the above-mentioned 33 and then overlay the later packages somehow with kickstart .ks files?

Any pointers/hints to go about this would be much appreciated. Thank you in advance.

1 Like

Another observation and question. I noticed all the other kickstart files for the different fedora spins are available here:

I didn’t find the silverblue kickstart in there and was wondering where I could find it or its equivalent. Does anybody here know where I can find a silverblue kickstart file?

thank you in advance.

1 Like

I have managed to get Fedora Linux on the VisionFive2. I kick started (manually no kick start file) the process by downloading the fc37 riscv rootfs and expanding that to an SD card then fumbling through StarFive’s documentation to get it to boot up to a kernel I built on my desktop. I did not yet build a kernel config spec file, but that should not be too hard to do. If you want a spec file I could make one. I know little about silver blue to know how to implement that. I also did not attempt to get graphics working.

1 Like

I learned today from reading a bit more about kickstart, that you can find the exact kickstart script used to install your own fedora silverblue os. It’s found in /root/anaconda-ks.cfg

sudo cat /root/anaconda-ks.cfg
# Generated by Anaconda 35.22.2
# Generated by pykickstart v3.34
# Use graphical install

%post --erroronfail
cp /etc/skel/.bash* /root

# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
# System language
lang en_US.UTF-8

# Firewall configuration
firewall --use-system-defaults

# OSTree setup
ostreesetup --osname="fedora" --remote="fedora" --url="file:///ostree/repo" --ref="fedora/35/x86_64/silverblue" --nogpg

# Run the Setup Agent on first boot
firstboot --enable

# Generated using Blivet version 3.4.2
ignoredisk --only-use=sda
# Partition clearing information
clearpart --none --initlabel

# System timezone
timezone America/Toronto --utc

#Root password
rootpw --lock

At the moment, I’m focused as to how anaconda/kickstart go about partitioning the destination device for fedora silverblue.
Firstly, I discovered anaconda/kickstart actually use blivet to make this happen. The kickstart command that hides all the details is autopart which I have to discover exactly the command it uses to partition the destination device for all the necessary partitions, btrfs volumes and subvolumes.

We need this in order to overlay it with the fedora package files and then with the VF2 specific kernel/modules, gpu driver and boot firmware.

This debian sid image is pretty good. network ports work/gpu driver there and framebuffer is supported. The desktop/x and xrandr/modeset settings aren’t capable on anything greater than 1080p. lightdm/xfce cycle the display black and login screen again and again at the moment, but ssh is fine. Rust/emacs/python/aptitude/curses/apt-get are all up and behaving well against the sid experimental ports repo not the snapshots repo.

You are correct if you want to properly build a RISC-V system you should use a kick start. Does Fedora Silver Blue use separate repositories? I am working on recreating my fedora image and this time write documentation too.

This link is a link to another probably similar or same kick start to the one you have posted.

This part about anaconda boot loader options:

mentioned inst-extlinux:

I think I saw that being used in debian/archlinux for the vf2 images. I’m guessing the fedora silverblue 37 vf2 image will require it as well. I don’t know what I’m doing though LOL

Why did you add those last two lines? Or this is an example not specific to vf2 usage.

bootloader --location=none --disabled

Ok I just saw the original file with the extra couple following lines:

bootloader --location=none --disabled
clearpart --all --initlabel --disklabel=gpt
part / --fstype="ext4" --size=3968

You’re simplifying the file system in this case, but it doesn’t follow the usual partitioning pattern

 $ lsblk
THE USUAL SILVERBLUE AUTOPART'ed layout which I would like to see on the VF2
sda      8:0    0 476.9G  0 disk 
├─sda1   8:1    0   600M  0 part /boot/efi ====kinda like vf2 spl
├─sda2   8:2    0     1G  0 part /boot =====exactly like vf2 /boot
└─sda3   8:3    0 475.4G  0 part /var/home ====very very different from vf2 debian which has only /
zram0  252:0    0     8G  0 disk [SWAP]

Destination sdcard as setup by debian:
sdb      8:16   1  29.5G  0 disk 
├─sdb1   8:17   1    16M  0 part THIS IS SPL?
├─sdb2   8:18   1   512M  0 part THIS IS /boot
└─sdb3   8:19   1    29G  0 part  THIS IS /

I’m feeling like an idiot to ask, but how do you manually run that fedora-riscv64-developer-rawhide.ks?
I saw no destination device specified within the kickstart file so it must be specified at invocation alongside this .ks script.

Getting closer:

I think I saw you using lorax from within koji builder:
How to create a Fedora install ISO for testing - Fedora Project Wiki)_Using_lorax

I think you ran lorax with the kickstart file as a parameter though.

chrooting is needed later on and somebody already dealt with that. Thank you demonich.

The boot process on the VisionFive 2 is first opensbi (open supervisor binary interface) then U-Boot. U-Boot looks at the extlinux file to know what kernel to boot and what arguments, device tree and initial ramdisk are going to be booted. The extlinux boot has given me issues for some reason.

I am trying to send a link and it needs aproval to send a link to fedora’s RISC-V building bootable image guide. In there is a section about building an image from the kickstart.

I discovered another image making tool mkosi.

It must be noise at this point, but I figured I should mention it as something on the radar to help make images.

I believe this is close, but replace there kickstartfile.ks with yours.
From the fedora project:

IMAGE_RELEASE=`date +%Y%m%d-%H%M%S`
appliance-creator -c kickstartfile.ks \
                  --cache ${CACHE_DIR} \
                  --format raw \
                  --name ${IMAGE_NAME} \
                  --version ${IMAGE_VERSION} \
                  --release ${IMAGE_RELEASE} \
                  -o ${OUTPUT_DIR}

Thank you Darren, that’s crystal clear. you call appliance-creator to create the image.

I’m going install these fedora packages to run appliance-creator and have some points of reference to look at:

sudo rpm-ostree install spin-kickstarts fedora-kickstarts appliance-tools livecd-tools

Here is how to build an image from the kickstart.

I looked at that page you just mentioned Darren. Thank you. It mentioned the VF1 kickstart:

I would prefer with the exception of the spl partition, the partition layout should resemble the same layout as the x86_64 autopart’ed layout. What are the kickstart commands to make btrfs volume and btrfs subvolumes?

Here’s the jh7100_kickstart stuff I would like to change for the VF2 jh7110 kickstart:

clearpart --all --initlabel --disklabel=gpt
part swap --asprimary --label=swap --size=32
part /boot/efi --fstype=vfat --size=128 --label=EFI
part /boot --size=512 --fstype ext4 --asprimary
part / --fstype="ext4" --size=12288 #####should be btrfs

As shown below note sda3 has a plethora of mountpoints all btrfs subvolumes which is what I hope to see in the image for sda3. I don’t hope to see ext4.

sda      8:0    0 476.9G  0 disk 
├─sda1   8:1    0   600M  0 part /boot/efi
├─sda2   8:2    0     1G  0 part /boot
└─sda3   8:3    0 475.4G  0 part /var/home
zram0  252:0    0     8G  0 disk [SWAP]

/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
/dev/sda2 on /boot type ext4 (rw,relatime,seclabel)
/dev/sda3 on /var/home type btrfs (rw,relatime,seclabel,compress=zstd:1,space_cache,subvolid=256,subvol=/home)
/dev/sda3 on /var type btrfs (rw,relatime,seclabel,compress=zstd:1,space_cache,subvolid=258,subvol=/root)
/dev/sda3 on /sysroot/ostree/deploy/fedora/var type btrfs (rw,relatime,seclabel,compress=zstd:1,space_cache,subvolid=258,subvol=/root)
/dev/sda3 on /usr type btrfs (ro,relatime,seclabel,compress=zstd:1,space_cache,subvolid=258,subvol=/root)
/dev/sda3 on /etc type btrfs (rw,relatime,seclabel,compress=zstd:1,space_cache,subvolid=258,subvol=/root)
/dev/sda3 on / type btrfs (rw,relatime,seclabel,compress=zstd:1,space_cache,subvolid=258,subvol=/root)
/dev/sda3 on /sysroot type btrfs (ro,relatime,seclabel,compress=zstd:1,space_cache,subvolid=258,subvol=/root)

This is an example I found on github from user: rhinstaller repo: kickstart-tests file: If you change it up to use brtfs you will have to verify that btrfs support is enabled in the Linux kernel when you build that. I also have not set up a btrfs system myself, so this might be outdated.

As you might know, you have to have 2 partitions on the SD card for preboot and one for boot and then your rootfs. An EFI partition might be possible, but I have not looked into that. At the very least an EFI system is not required to boot.

part --fstype=ext4 --size=500 /boot
part --fstype=swap --size=500 swap
part btrfs.10 --fstype="btrfs" --size=2200
part btrfs.12 --fstype="btrfs" --size=2200

btrfs none --data=raid0 --metadata=raid1 --label=fedora-btrfs btrfs.10 btrfs.12

btrfs / --subvol --name=root fedora-btrfs
btrfs /home --subvol --name=home fedora-btrfs

After installing the package spin-kickstarts, I found the following file holding something almost what I want:
Keep in mind I don’t know if the following is the exact same thing that autopart does. I’m still going to investigate what autopart does for the precise answer.

The python kickstart sources hold the autopart capability. For fedora 37 which I’m running at the moment:

For fedora 37, the autopart command is fulfilled by commands.autopart.F29_AutoPart

"autopart": commands.autopart.F29_AutoPart,

Nope, following the above autopart code is difficult. It travels/trickles down to earlier version function calls of autopart, but I don’t see where it creates those subvolumes /var/home, /var, /sysroot/ostree/deploy/fedora/var, /usr, /etc , /, /sysroot.

Possible alternative to autopart from fedora37:

# Configure for gpt with bios+uefi
clearpart --all --initlabel --disklabel=gpt

part prepboot  --size=4    --fstype=prepboot
part biosboot  --size=1    --fstype=biosboot

part /boot/efi --size=100  --fstype=efi
part /boot     --size=500  --fstype=ext4 --label=boot
part btrfs.007 --size=2000 --fstype=btrfs --grow
btrfs none --label=fedora btrfs.007
btrfs /home --subvol --name=home LABEL=fedora
btrfs /     --subvol --name=root LABEL=fedora

So the prepboot and biosboot can be removed.
There was a swap mentioned earlier, but we don’t use a storage device for that. We’ll use ram for that i.e. zram0.
The zram0 thingy in the kickstart file is yet another question LOL.

My first attempt at creating the image failed, but at least create-appliance accepts the kickstart file I gave it LOL

Attached is the create appliance script, the kickstart file and the error output:

I’m seeing stuff from fc31, fc33, fc37 in the error output. I guess rawhide is frozen to fc37 for riscv at the moment.