Maybe we should finish figuring out the disk label stuff we already know about before we do this?

• https://bugzilla.redhat.com/show_bug.cgi?id=2328768
• https://bugzilla.redhat.com/show_bug.cgi?id=2328590

Maybe we should finish figuring out the disk label stuff we already know about before we do this?

• https://bugzilla.redhat.com/show_bug.cgi?id=2328768

The only thing here is figuring out what size ESP we want. I'm okay with increasing all the way up to 500MB, but we should actually need it to be increased first.

• https://bugzilla.redhat.com/show_bug.cgi?id=2328590

Marcus' fix for bios mode detection is in the kiwi update that I pushed yesterday: https://github.com/OSInside/kiwi/pull/2688

The only thing here is figuring out what size ESP we want. I'm okay with increasing all the way up to 500MB, but we should actually need it to be increased first.

Well, we still didn't get any feedback from Peter or Paul if the differences between the imgfac and Kiwi MBRs might cause any issues. I don't have a Pi to test on. I guess I can try on my Jetson.

Marcus' fix for bios mode detection is in the kiwi update that I pushed yesterday: https://github.com/OSInside/kiwi/pull/2688

I don't think that actually has much to do with the "we get MBR not GPT on live ISOs" issue, which is what the bug is about?

The only thing here is figuring out what size ESP we want. I'm okay with increasing all the way up to 500MB, but we should actually need it to be increased first.

Well, we still didn't get any feedback from Peter or Paul if the differences between the imgfac and Kiwi MBRs might cause any issues. I don't have a Pi to test on. I guess I can try on my Jetson.

Marcus' fix for bios mode detection is in the kiwi update that I pushed yesterday: https://github.com/OSInside/kiwi/pull/2688

I don't think that actually has much to do with the "we get MBR not GPT on live ISOs" issue, which is what the bug is about?

Oh, that's fair. With the detection fixed, it should be possible to have the option set properly though.

Well, we still didn't get any feedback from Peter or Paul if the differences between the imgfac and Kiwi MBRs might cause any issues. I don't have a Pi to test on. I guess I can try on my Jetson.

Jetson won't show the problem, look at the existing configs and reproduce those, it's documented in there.

I posted the exact details of the MBR we get to the bug and asked for your feedback on whether any of the differences are significant. It would be great if you could look at that. I don't know what you mean by "the existing configs" or what is "documented" there. The "configs" in pungi-fedora for imagefactory images do not specify anything particular about the disk label, as you can see in this very PR. In both the imgfac and kiwi cases, exactly how the disk label comes out is an implementation detail of the tool, and is not particularly configurable.

I posted the exact details of the MBR we get to the bug and asked for your feedback on whether any of the differences are significant. It would be great if

Sorry, I have missed it, I was traveling the first two days of the week and have been sick, my inbox has increased by over 400 threads in 3 days so I am sorry if I have been tardy in my response :-/

you could look at that. I don't know what you mean by "the existing configs" or what is "documented" there. The "configs" in pungi-fedora for imagefactory images do not specify anything particular about the disk label

That's because the configs in pungi specify the size of the virtual disk that becomes the .raw file. The partitioning is specified in the kickstart that is specified in this config and that is contained in fedora-kickstarts repo along with everything else that is required in the install :smirk: That kickstart also contains the details in the post script to setup the RPi firmware and other packages that are needed, from memory the details are in fedora-disk-base.ks

But as I have stated elsewhere there has been no Fedora change for this and no engagement with the Arm SIG. Traditionally the Arm SIG has owned all the arm images and worked with the other SIGs when they have requested arm support which is ultimately why you always assign us the blockers, I suppose things change but there has been no engagement over this with any members of the Arm SIG either. We have been in fact working on implementing a replacement for the image factory images, we had hoped to get the work done for F-41 but we ran out of time, we were literally preparing to file the appropriate change in early December when this came and side swiped us. I'm sorry but if you don't want to follow process that is fine (well not IMO), I mean I suppose Neal just assumed all his FESCo buddies would just wave it all through and he could do as he likes, but don't complain at me when I don't roll out the red carpet to answer all the questions that are documented in the configs, this whole incident has been very demotivating so expect the process to be dealt with by bugs when I find both the time to test and them because I'm doing this work on my own personal time and this week I have not had any of that to spare!

But as I have stated elsewhere there has been no Fedora change for this and no engagement with the Arm SIG. Traditionally the Arm SIG has owned all the arm images and worked with the other SIGs when they have requested arm support which is ultimately why you always assign us the blockers, I suppose things change but there has been no engagement over this with any members of the Arm SIG either.

This is very much news to me. In fact, I've been repeatedly told over the last two years that the desktop teams are responsible for their images on all architectures. This was even reaffirmed last year when I started looking into Fedora KDE's AArch64 status. This has even gone so far as that KDE SIG and Workstation WG have been assigned blocker bugs that only happen on ARM platforms that we have had to resolve. Sure, components that are below us (such as firmware packages) wind up going to the ARM SIG, but the rest has gone to us.

Does it really matter who's responsible? We'll just have to work together and figure it out, same as always.

So fedora-disk-base.ks has:

clearpart --all --initlabel --disklabel=msdos

All that really says is 'wipe the disk and create a fresh mbr/msdos disk label', the details are left up to anaconda, I guess. I don't know off the top of my head how anaconda implements this. But, we know what result we get, in practice, from anaconda and from kiwi, now. The question is whether any of the differences are significant. I'd guess they shouldn't be, but I don't have a Pi, so if Pi is the main platform possibly affected, I've no way to test.

and:

%post

# Find the architecture we are on
arch=$(uname -m)
# Setup Raspberry Pi firmware
if [[ $arch == "aarch64" ]]; then
cp -P /usr/share/uboot/rpi_arm64/u-boot.bin /boot/efi/rpi-u-boot.bin
fi

%post also does various other little cleanups which I guess @ngompa should take a look at if he didn't already, and make sure Kiwi images have all of those handled.

This is captured in the config.sh file: https://pagure.io/fedora-kiwi-descriptions/blob/rawhide/f/config.sh#_126-133

if [[ "$kiwi_profiles" == *"Disk"* ]]; then
    # Find the architecture we are on
    installarch=$(uname -m)
    # Setup Raspberry Pi firmware
    if [[ $installarch == "aarch64" ]]; then
        cp -a /usr/share/uboot/rpi_arm64/u-boot.bin /boot/efi/rpi-u-boot.bin
    fi
fi

The question is whether any of the differences are significant. I'd guess they shouldn't be, but I don't have a Pi, so if Pi is the main platform possibly affected, I've no way to test.

Pi, any of the Allwinner platforms at least.

New Rockchips platforms also need the offset of the first partition at 12Mb, we are doing that and other bits in ImageBuilder.

Basically it's quite complex and that is why it takes time.

None of the above states why this hasn't been done as an official change.

This is very much news to me. In fact, I've been repeatedly told over the last two years that the desktop teams are responsible for their images on all architectures.

I have always stated the desktops are required to test their images on the hardware that they care about as they are the ones that are capable of knowing what the desktops do, it's basically impossible for the arm SIG to test all desktops in all the possible ways that the dozens of desktops do and to know whether it's the same or different outcome than other architectures.

This has even gone so far as that KDE SIG and Workstation WG have been assigned blocker bugs that only happen on ARM platforms that we have had to resolve.

If there's a crash in a specific package that goes to the package maintainer, the ARM SIG gets assigned all sorts of things such as mesa and toolchain and god knows what else.

New Rockchips platforms also need the offset of the first partition at 12Mb, we are doing that and other bits in ImageBuilder.

@pbrobinson is it possible you misremembered and this is in arm-image-installer, not in the images themselves? I went looking through ImageFactory and oz code (most current images are built with IF and oz, not osbuild/image builder) and could find no trace of anything to do with this either in the source or commit history, but there are various things about specific offsets in the code and commit history of arm-image-installer.

If that stuff is in a-i-i then this isn't an issue, right? As long as kiwi produces base images sufficiently similar to IF, a-i-i should be able to do the hardware-specific customizations correctly for kiwi-produced images too?

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/c07e2437cefa455c851cb8c42b326100

• pungi-config-validate : SUCCESS in 2m 09s
• validate-variants : SUCCESS in 2m 02s

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/6fb310601c2340509057a19500b26ce4

• pungi-config-validate : SUCCESS in 2m 21s
• validate-variants : SUCCESS in 2m 06s

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/2ae85ee06d54432c8568a5cf32455947

• pungi-config-validate : SUCCESS in 2m 17s
• validate-variants : SUCCESS in 1m 58s

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/282c5e3e8e0e45e8b00aa1fd2459da67

• pungi-config-validate : SUCCESS in 2m 28s
• validate-variants : SUCCESS in 2m 04s

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/3b016fa015c148d1a6bcba39298ea946

• pungi-config-validate : SUCCESS in 2m 08s
• validate-variants : SUCCESS in 2m 02s

@pbrobinson, do you think this looks like a good patch to go in now? @ngompa mentioned in releng today "the reports from test@ seem to indicate it's fine on the rpi devices"

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/2b91f06b6bb54ac7af0eddf475887a9f

• pungi-config-validate : SUCCESS in 2m 03s
• validate-variants : SUCCESS in 1m 49s

FWIW, this is the response in question: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/A4LI3H434O7PSTJ4USZMFYDMAUU4EMIN/

I don't think we have any objections to this from QA side at this point. Let's at least try it and see what explodes. Peter's been given a solid chance to raise any remaining objections, and we have got some positive ARM test results.

Yeah, lets try it. We can revert if needed.

We need this cherry-picked for F42 too.

Done