Hi,
If anyone wants to build their own Debian images I’ve put my work in progress in https://github.com/thomasdstewart/starfive-visionfive2. It works for me and allows me to run official Debian Sid except for opensbi, u-boot, and linux.
Tom
Hi,
If anyone wants to build their own Debian images I’ve put my work in progress in https://github.com/thomasdstewart/starfive-visionfive2. It works for me and allows me to run official Debian Sid except for opensbi, u-boot, and linux.
Tom
@thomasdstewart I appreciate your rationale to use vmdb2. I read your readme and your yaml file. it’s the same tool used to build raspberry pi images. Your yaml summarizes everything for creating the vf2 debian sid image.
You probably are aware of the other sid image available out there by hexdump0815.
Of particular interest is his uEnt.txt is different from yours:
/boot/uEnv.txt
One other thing I noticed is your yaml doesn’t contain an extlinux.conf file
Nice. Thank you.
Would you share some statistics about how long it takes on what machine?
(I’m watching your most excellent dot files project on github.)
Hi @omac777 thanks for looking! Yes I ran into the hextdump0815 project, I didn’t try it yet tho, it does look quite good.
Just regarding the uEnt.txt, I was sort of going for minimal extra settings to get it working, eg most of those settings are now not needed with latest firmware. As for extlinux.conf, I’ve left that out by design as it’s generated by u-boot-update just like how update-grub works, which is a bit cleaner.
@JohnPoole stats wise I would expect it to be very similar to the official images. It’s the same kernel, but with current Sid userspace rather than a snapshot from a few months ago. If you had a specific things in mind I don’t mind running them.
Great job, thanks for sharing.
@thomasdstewart Thank you for the offer. I’m coming from the GenPi64-Build.dist project where we build images of Gentoo Linux for the Raspberry Pi family. I built on my own a “Lite” as opposed to a “Desktop” image last March, it took 8 days and 8 nights on a Gentoo VM on an AMD Bulldozer (2013) using qemu. I was just hoping for a comparable.
I’m testing the docker solution here, first thing I think needs to be changed is the debian version, it seems like vmdb2 is version 0.22 in bullseye and stops at the second instruction in the yaml. vmdb2 in bookworm is 0.26 and it works until it hits the kpartx lines, which fails.
The error message I get when running kpartx on itself is:
# kpartx -asv
/dev/mapper/control: open failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.185 (2022-05-18) and kernel driver (unknown version).
device mapper prerequisites not met
Is there a alternative to kpartx here ?