Mageia forum

Hello Forum,

I'm a Mageia NewBe so excuse my ignorance.

I'm trying to create a aarch64 image to boot single board computers and testes my go-to tool appliance-creator for this and after some fiddling it runs.

How ever i have no clue which specific mageia needs packages to be installed on the image to get an minimal root_fs which may boot;
because (here come my ignorance) there does not seem to be (dnf) repo-groups i'm a kind of used to.

Peeking @ mock configuration's i can identify the base url's of the repo's and two (meta) packages : basesystem-minimal rpm-mageia-setup

Are there more meta packages to install a minimal setup including a sshserver?


Note: I can take care of uboot and/or special kernels if applicable, that not a problem...
Cool would be to boot them with grub2-efi as uboot can take care that;
it provides an clean split between al the SCB's early boot stuf and loading the kernel

Any direction is appreciated,

Grtz mark

Hi there,
basesystem-minimal + openssh-server should be sufficient.

doktor5000 wrote:basesystem-minimal + openssh-server should be sufficient.

Thank you for the swift answer !

Unfortunately was a bit to optimistic here:

markvnl wrote:I'm trying to create a aarch64 image to boot single board computers and testes my go-to tool appliance-creator for this and after some fiddling it runs.

Although it is possible to create a (x86_64) centos-8 qcow2 on my mageia test VM, can not create a Magia image.
Aplliance-tools fails with: Unable to create appliance : Failed to find group 'core' : no such group: @core

Could not find any references within the appliance-tools it self (but may have overlooked it!)
After a www search this "error message" seems to be misleading and more related to a mismatch in repository metadata and DNF.
At least a quite old bug report indicates this: https://bugzilla.redhat.com/show_bug.cgi?id=1464736

I'll gues the appliance-tools are a bit to much integrated with anaconda, the 'rhel' family installer.

My experiment goes on hold now;

I'll keep my x86_64 vm alive for a while and do some work on/with it,
really like feeling of Magiea!

for reference:

Code: Select all

Adding disk img as /var/tmp/imgcreate-uymgnd7a/tmp-bmvku76t/Mageria-Cauldron-img.raw
WARNING! syslinux-extlinux package not found.
Extending sparse file /var/tmp/imgcreate-uymgnd7a/tmp-bmvku76t/Mageria-Cauldron-img.raw to 2684354560
Losetup add /dev/loop0 mapping to /var/tmp/imgcreate-uymgnd7a/tmp-bmvku76t/Mageria-Cauldron-img.raw
Formatting disks
Initializing partition table for /dev/loop0 with msdos layout
Assigning partitions to disks
Assigned / to img1 at 1 at size 2560
Creating partitions
Add primary part at 1 of size 2560
Dev loop0p1: /dev/loop01 -> /dev/mapper/loop0p1
Creating symlink from /dev/loop01 to /dev/mapper/loop0p1
Adding partx mapping for /dev/loop0
['/']
Formating ext4 filesystem on /dev/loop01
Formating args: ['mkfs.ext4', '-F', '-L', '_/', '-m', '1', '-b', '4096', '/dev/loop01']
mke2fs
1.45.6
(20-Mar-2020)
Discarding
device
blocks:                                                                                                                                                                                               done
Creating896
filesystem
with
624896
4k
blocks
and
156480
inodes
Filesystem
UUID:
784c6b07-3fae-4a59-a70f-48f53c5efaab
Superblock
backups
stored
on
blocks:
32768,
98304,
163840,
229376,
294912
Allocating
group
tables:                                                                                                                                                                                                       done
Writing
inode
tables:                                                                                                                                                                                                       done
Creating
journal
(16384
blocks):
done
Writing
superblocks
and
filesystem
accounting
information:                                                                                                                                                                                                  done
Tuning filesystem on /dev/loop01
tune2fs
1.45.6
(20-Mar-2020)
Setting
maximal
mount
count
to
-1
Setting
interval
between
checks
to
0
seconds
Mounting /dev/loop01 at /var/tmp/imgcreate-uymgnd7a/install_root/
Writing mkinitrd config /var/tmp/imgcreate-uymgnd7a/install_root/etc/sysconfig/mkinitrd
Skipping (/sys/fs/selinux,/sys/fs/selinux) because source doesn't exist.
User-Agent: constructed: 'libdnf (Mageia 8; generic; Linux.x86_64)'
Unknown configuration option: failovermethod = priority in /var/tmp/imgcreate-uymgnd7a/dnf.conf-4tu5t_v7
repo: downloading from remote: install
install                                                                            3.6 MB/s |  52 MB     00:14
install: using metadata from Wed 27 May 2020 05:58:25 PM CEST.
Last metadata expiration check: 0:00:29 ago on Wed 27 May 2020 08:39:52 PM CEST.
User-Agent: constructed: 'libdnf (Mageia 8; generic; Linux.x86_64)'
Unable to create appliance : Failed to find group 'core' : no such group: @core
Unmounting directory /var/tmp/imgcreate-uymgnd7a/install_root/
Removing compat symlinks
Unmapping /dev/loop0
Losetup remove /dev/loop0

markvnl wrote:Aplliance-tools fails with: Unable to create appliance : Failed to find group 'core' : no such group: @core

I think the problem is that appliance-tools tries to use yum/dnf groups, but we don't have those groups, although this might also be a bug.
From what I can tell, currently we don't provide comps.xml (which contains the group information) by default in our repository metadata.
So you might need to create a local mirror, and create the comps.xml yourself. Have a look at https://fedoraproject.org/wiki/How_to_u ... _structure

Or you could try to adapt appliance-tools and change the kickstart files it seems to use and simply replace @core with basesystem-minimal, but I'm not sure if it's really that simple.

Maybe our dnf maintainer has a suggestion for this, I've asked him to take a look - coincidence that he also seems to be maintainer for appliance-tools

Since Mageia does not have composition groups, you'll need to use %packages --nocore instead of %packages for the section.

Here's an example kickstart that will build a trivial image:

Code: Select all

lang en_US.UTF-8
keyboard us
timezone US/Eastern
auth --useshadow --passalgo=sha512
selinux --disabled
firewall --disabled
part / --size 1536

repo --name=cauldron-x86_64 --mirrorlist=https://www.mageia.org/mirrorlist/?release=cauldron&arch=x86_64&section=core&repo=release

%packages --nocore --excludeWeakdeps
basesystem-minimal
kernel-server-latest
locales-en
dnf
dnf-plugins-core
%end


The documentation on kickstarts is available here: https://pykickstart.readthedocs.io/en/latest/index.html

ngompa wrote:.. you'll need to use %packages --nocore instead of %packages for the section.

Can confirm this is the solution to my hickup;

Thank you!

Please don't forget to mark the thread as solved, by editing the subject of the first post and prefixing it with [SOLVED], thanks in advance.

Just a heads-up and appreciation for the directions.

Build an experimental RPI4 kernel based on a RedSleeve/CentOS SPEC on copr (1),
So far so Good: network does not come up and more to debug - nevertheless is boots (2)

Code: Select all

[root@localhost ~]# uname -a
Linux localhost 5.4.28-1.v8.mga8 #1 SMP PREEMPT Thu May 28 13:43:00 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
[root@localhost ~]# cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.1
[root@localhost ~]# cat /etc/mageia-release
Mageia release 8 (Cauldron) for aarch64

1) build of experimental kernel
https://copr.fedorainfracloud.org/coprs ... d/1415498/
https://download.copr.fedorainfracloud. ... spberrypi/
NOTE 1 It's a bit hacky: the binary blobs for the early boot-stages are included in the source package
NOTE 2 It's not a main-line kernel: it is build from Raspberry PI Foundation sources
NOTE 3 I'm not familiar with the Mageia packaging guidelines (yet)

2) log of first-boot
https://gist.github.com/markVnl/0dc61a9 ... 1a79a34064

Sorry to bump this up again;

In the end settled for these packages to start with:

Code: Select all

%packages --nocore --excludeWeakdeps
basesystem
locales-en
raspberrypi-kernel4
raspberrypi-firmware
kernel-firmware-nonfree
zram
dhcp-client
wpa_supplicant
chrony
openssh-server
sudo
dnf
dnf-plugins-core
bash-completion
wget
nano
%end

nano: yes i'm a sissy..

If someone is eager to help me testing running Mageia Cauldron on a Raspberry PI 4 (or 3, 3+);
here (@ the release tab) you'll find prematurely image to test:
https://github.com/markVnl/Mageia_SBC

markvnl wrote:If someone is eager to help me testing running Mageia Cauldron on a Raspberry PI 4 (or 3, 3+);
here (@ the release tab) you'll find prematurely image to test:
https://github.com/markVnl/Mageia_SBC

You could add that to some wiki page for some more coverage, e.g. https://wiki.mageia.org/en/MageiaOnARM

markvnl wrote:If someone is eager to help me testing running Mageia Cauldron on a Raspberry PI 4 (or 3, 3+);
here (@ the release tab) you'll find prematurely image to test:
https://github.com/markVnl/Mageia_SBC

Hi Mark. I just order a pair of SDs as I have no spare ones left. I have been waiting for Mageia on RPI4 as it's been a while testing mga7 on RPI3B+. It worked great but as RPI4 is a different beast I didn't even tried but I do remember Daniel (git) reported that it didn't work at that time because of the new kernel needed.

I do have a RP3B+ but I didn't run it after I bought RPI 4 4G and run it in "production" (apache, mysql, file backup server for RPI itself, PC and SailfishX + X mainly for browsing my PHP stuff and some general browsing on EOL support TV).

So I intend to test more than CLI as I really miss Mageia on RPI.

Since someone forced dnf on Daniel's git, I wasn't able to use it and I remain on a previous version which still works with urpm. I don't have the time to re-check if it is working now. Here the other branch : https://git.labolyon.fr/Jybz/mageia4arm

Filip, when I will have time (in 2 months ?) I will see again, I believe, now, we can use aarch64 on Rpi3b+ without boot modifications. (decompressing the kernel)

For the Rpi4, I don't have one, so I can't really help, but I would like to help as much as I can.

I invite interrested people on #Mageia-arm

Sorry for the late reply (kind of overseen this...)

filip wrote:

markvnl wrote:I do have a RP3B+ but I didn't run it after I bought RPI 4 4G and run it in "production" (apache, mysql, file backup server for RPI itself, PC and SailfishX + X mainly for browsing my PHP stuff and some general browsing on EOL support TV).

So I intend to test more than CLI as I really miss Mageia on RPI.

Through the year's kind of learned the hard way getting good results for graphic's is hard due to the (often non-free Proprietary) driver(s) needed for hardware accelerated video output on arm SOC's.

But if you do not aim for the Moon, you never learn to fly

jibz wrote: I believe, now, we can use aarch64 on Rpi3b+ without boot modifications. (decompressing the kernel)
I invite interrested people on #Mageia-arm

The default mageia aarch64 kernel boots a RPI3b+ outoff the box.

IMHO The main question going forwards is choosing the default "final" bootlaoder actually booting the kernel after the early (hardware specific) bootstages. My preference is grub2 because the user experience of a arm system matches x86_64. This can be done with uboot > grub2-efi > kernel
On aarch64 this works like a charm since and kernel 5.<something> there is a patch for armv7 for the loading address of the kernel which honers reserved memory of the remains of the early boot stages. This was particular problematic for RPI's where the (Boardcom) bootcode.bin keeps monitoring some hardware (most notably under-voltage)


A still undocumented image (even more prematurely) for uboot which boots the default kernel on a RPI3+ as described above at the same release tab:
https://github.com/markVnl/Mageia_SBC/releases

Uboot which looks for grubaa64.efi in EFI/mageia was build on copr:
https://copr.fedorainfracloud.org/coprs ... /packages/
with this specific patch:
https://github.com/markVnl/rpms-uboot-t ... name.patch

Most worrying at the moment for me is I cannot figure out howto hook in the kernel-install procedure to copy the devicetree's as commented here:
https://github.com/markVnl/Mageia_SBC/b ... ga.ks#L104

As of the #Mageia-arm due to my Dyslexia mail-list do not realy work for me ;
can not see though al the >>> and mis the conversation.

However willing to put some effort in this;

Grtz Mark

jibz wrote: https://git.labolyon.fr/Jybz/mageia4arm

I looking in to this right now and getting familiar with it.

As said my goto tool is appliance-tools but i can change.

ngompa wrote:The documentation on kickstarts is available here: https://pykickstart.readthedocs.io/en/latest/index.html

Learned a-lot from this, thank you!
I wonder if it would be possible to back-port the "Leave more space (4MB) for uboot before the first partition" patch to Magiea Cauldron too?
Sorry to be cheeky with this. It probably does not belong in the basic support category, more likely in "Testing : Alpha, Beta, RC and Cauldron"

Hello,

Sorry, I often forget this international forum, I'm much more online on the french forum MLO.
#mageia-arm is not a mailing list, but an instant chat on IRC freenode, dyslexia is okay for it, no problem. It doesn't let traces.

It is really interesting to use grub2, so interesting, that I'm trying to use it, but the grub2 provided by mageia's BS is not (yet) suitable.
I continue to develop mageia4arm, and hope soon to deploy on Mageia's infrastructure to generate first bunch of images. Maybe as soon as I'm done with uboot->grub->mga.

btw, mageia4arm repo moved to gitweb.mageia.org/software/mageia4arm .

Finally some progress.