I was trying to create an arch linux from scratch on gentoo.
At first it looked like it was working fine but then I realized that the packages were not created even though it appeared like everything was working nicely.
I then saw that parabola has a vm with their version.
I then mounted it on a directory called rootfs
I created an tar.xz file to get the whole rootfs
I then created an arch-riscv64 directory where I untar the rootfs
Next step was to chroot
I use fchroot which I ported from Funtoo to Gentoo
I went back to Gentoo from Funtoo after they removed the support for 32 bits.
32 bit support is required for my yocto work with Texas Instruments devices
This is a good starting point despite the fact that everything is 4 years old.
I proceeded to update each packages. I then found out that most packages
give me this error message
“LLVM ERROR: inconsistency in registered CommandLine options”
This error message comes on packages not even using llvm but gcc
After a couple days of trying to figure out what is wrong I got a solution
The solution was to remove llvm-libs, to make sure I would have no problem I removed mesa and llvm as well.
I have a question for the experts on mesa, is it possible to compile mesa with only gcc?
Or, is there a way to still have llvm but not have it take over linking gcc programs?
I find out that too many packages will not compile at all with llvm present. I haven’t checked the compile on the beaglev yet, maybe it is just an issue in chroot.
My archlinux will be name suzie. named after my beloved maine coon cat that I lost when she was 19 years old.
There was a funny thing with the name when I first created my website.
If you would make searches for SuSE Linux my site came up first on google.
SuSE is pronounced Suzie in German.
Netone told that I can create a git repository on my website, perhaps I can create also a repo for my linux.
Anyhow I will give an update when I have the system updated.
Michel
1 Like
Not sure if it helps, but sometimes it is possible to prepare the root filesystem in an emulator, and then to copy the whole block device to the SD/USB storage that the board uses to boot. One complication may be that the emulated VM and the board bootloaders are different. I am not experienced enough in this area, but it would be interesting to know how BeagleV boots. Does it have u-boot or something different?
The way I work it for my yocto build and have been doing the same thing for my odroid and beagleboards is to create a directory on my Ryzen computer as root. I then run fchroot which was created for Funtoo. I had to modify one line in it so it would install on gentoo.
I haven’t tried it on archlinux but that shoudl work if the procedure to run chroot is similar. It is written in python. What it does it go thru the normal sequence to get into chroot that is described for gentoo so you don’t have to type bunch of lines.
I then compress the whole directory in a tar.xz file.
After that I use a script that uses losetup to create an image. Tha script creates an image, it create partitions and format them.
After that it decompress the file into the new image.
Part of the script installs the kernel that was created with the cross compiler as well as the device tree and script required to boot.
Right now it uses two ext4 partitions. I think that I should be able to use just one partition as I do with my other beagle boards. With Odroid there is a need to copy a signature and it rquires a fat partition.
You do need to have the kernel support compiling different structures and compile qemu correctly
There is a video on youtube that explains how to use fchroot on Funtoo, you might find that usefull.
On Gentoo and Funtoo I have to enter this into package.use
app-emulation/qemu static-user qemu_user_targets_aarch64 qemu_user_targets_riscv64
In archlinux you would have to modify the PKGBUILD to have the option fot riscv64 if that isn’t done already
On Gentoo it doesn’t support the arm64 or riscv64 by default
The next step is to copy to a micro SD card. I use dd for that. The script that creates the image creates one that is slightly larger than the content of the rootfs.
After I copy the image to the micro SD I use gparted to expand the partition to fill the whole disk. I may use 16G, 32G, 64G or 128G on my boards.
I have been able to compile bunch of programs so far on my archlinux rootfs in chroot.
I do have an issue when compiling gcc as it seems to be in an infinite loop. I started it yesterday evening and it is not done yet.
When I got up this morning I saw a message saying that a checksum didn’t match and it was restarting part 2 and part 3
If it is not done tonight I will create a bin package using a gentoo build. The current arch uses gcc 7.3.3 which is old enough that many application refuses to compile since 11.1.0 is required.
I was finally able to compile and install gcc 11.1.0. I could not get a lot of stuff compiled with the old gcc 7.3.3. It took over 4 days. After a couple of days I thought that it was finally done, no, it barfed during checking. I then changed the PKGBUILD to remove the checking and restarted.
After a day it barfed again, I then realized that I should have deleted the src directory. I restarted it and a day and half later it was done. It looks like it restarted the last phases a few times. I did see one failure where it said it was deleting something and restarting.
The fun part came when installing gcc. It refused to install so I uninstalled the old one. I still couldn’t install it because for some mysterious reason the maintainers of the package decided to provide the same librairies in misc packages. I am still trying to figure out how it was installed to start with. Now I need to recompile a dozen or so packages that were said to require gcc-libs. I don’t understand the logic of splitting the gcc package and have the same librairies in each.
You’ll find it worth your time to set up a cross development and do your builds on a system with more adult storage and CPU bandwidth. Building native on BeagleV can be done (as you’ve demonstrated) but it’s a lot slower than a desktop-class system.
Without details on the libraries, nobody can offer much help or advice. Things like “strcmp” are implemented in several libraries across the system. Sometimes they’re optimized for speed, sometimes for size, some may take advantage of special CPU capabilities, etc. We just can’t say much without guessing.
I do the compiling with fchroot on a ryzen with 16 CPU, 32G of ram. My gentoo is on a 6TB hard disk. fchroot uses the kernel and qemu to do the emulation. I use the environment as for gentoo to compile my arch linux. I didn’t have to recompile gcc on my gentoo build since it has a recent one. Arch Linux was at 7.3.3 and the PKGBUILD file was doing tons of checks. I read somewhere online that the check often fails in a vm. I did notice at least 4 checks that were stalled for several hours. After I removed the options to do the checks the bootstraps went smootly. It is nowhere near as bas as rust, whoever came up with this slow crap needs to get his butt kicked.
So is there something we can play with in renode or something?
Most of the OS images you can find (or make) work fine with renode. Don’t know about Arch specifically. https://twitter.com/robertlipe/status/1401822687517892610
If you’re rolling your own OS, tweak a .resc file to reference your freshly-built OS image as part of your build process.
Works well.
Sounds good, @MichelC if you could roll it, id be happy to play with it in renode or if need be do the needful to get it up and running in renode.
I haven’t done much on it this past week due to some health issue, I have spent a big part of last Friday at ER.
I put it aside for now since the maintainers of gentoo seem to have the svg issue fixed. They have upgraded the support for riscv64 from profile 17 to profile 20.
That means that I should be able to get the mate desktop working . I am doing a world update right now and will then attempt to compile the mate desktop
I will get back to arch linux to finish it up when that is done. On archlinux I want all the base files updated before trying to compile a desktop.
On arch linux I was in the process of updating all the base files and when I tried to recompile binutils with the new compiler it core dumped. I have to check to see what causes it, maybe I need to recompile glibc
for what it’s worth, I’m in the process of preparing a 2021 version of the parabola riscv64 VM image. most of the packages are already built, only a few stragglers are still stubbornly refusing to work.
There are also related efforts of bringing archlinux up to speed on riscv64, there is a matrix room dedicated to this effort (that I keep forgetting the name of) and a bridged IRC room on libera.chat called #archlinuxriscv
I got my gentoo done for now so I will get back to arch linux after I publish my rootfs
I gave up for now on getting lazarus to work. I used a binary of fpc from fedora to create the gentoo version.
I wasn’t able to get the latest svn commit to compile, the maintainers broke the riscv64 support.
My pascal works and I am able to compile some pascal program.
I have the mate desktop to work with the exact same drawing issues that are on Fedora. Aside from that it looks nice.
I have not compiled a browser but will eventually do that as well. It is not a priority for me.
If I have issues getting mate to work on arch linux I will use some code I have on gentoo.
Which program can’t you compile?
One warning gcc will not compile unless you disable the check. Either that or it will take a week or two to compile.
I found that compiling on the target doesn’t work too well since it shuts down aftr a while. Maybe it gets too hot working continuously.
The best way is to use chroot
In our experience, compiling packages in a cross-arch chroot using qemu user-mode emulation has limits. It leads to hard to explain failures in test suites that do not occur on real hardware, and it can get confused by some more arcane syscalls. If you need virtualization, I’d recommend building in an actual VM instead.
I’ve frozen all versions on a state in early july this time, so I’m still on gcc-10, but that one worked well. In fact, the toolchain is pretty solid. I used to also have problems with the board locking up, but there’s been a patch to the bootloader a while ago that solved the issue for me.
I’m currently having a bit of trouble getting llvm to work, there is some issue with llc segfaulting a lot for certain jobs. I’m currently trying to figure that out. Also, ghc is building but it’s taking a while to complete. (read: days)
to summarize: all parabola packages of the 2021 version of the repos are being built on real hardware, to make sure they are release-worthy and don’t hide some subtle issues introduced by the user-mode emulation chroot builds. This comes with a bit of a time penalty in getting stuff done, of course but otherwhise it’s been working well for me. I believe the actual runtime of a gcc build once the toolchain was solid was around 50 hours.
The issues I have had with chroot turned out to be caused by the fact that qemu doesn’t support sandbox and seccomp. I disabled both for the chroot and things work nicely.
On the image I won’t need to disable those. I don’t know if you can disable those easily in archlinux. With gentoo is is a question of adding a few USE variables.
The problem I had with archlinux was a move from your gcc 7.3.3 to 11.1.0
So far binutils didn’t compile. I think that I need some other programs to be updated first.
As for the locking up on boot I have only seen it on fedora, never on gentoo. This may be a bug with systemd. The crashes I had are not related to the bootloader which doesn’t run at that point. The fan is running continuously but it may not be enough to get the beaglev not to overheat when compiling non stop.
On odroid or beagleboard X15 boards I always compile natively because the boards can run fast enough.