kiwi-ng fails with No provider of 'raspberrypi-eeprom' found.

[pasyn]

Tried compiling per instruction in README on Leap15.2 running on a Pi4.

kiwi-ng --profile=Leap15.2.RaspberryPi4 --type oem system build --description ./ --target-dir /home/kiwi-images/

Resulting with the following error
[ ERROR ]: 20:16:51 | KiwiInstallPhaseFailed: System package installation failed: No provider of 'raspberrypi-eeprom' found.

Adding the following repository to rockstor.kiwi allowed build to finish successfully...

https://download.opensuse.org/repositories/hardware:/boot/openSUSE_Factory_ARM/

[phillxnet]

@pasyn Thanks for the report. Much appreciated.
At first glance I thought we might be looking at an upstream repo change here, or an inadvertent removal of this package from the Leap15.2 ones specified. We added the "raspberrypi-eeprom" package in the following:
Pull request:
"Update RaspberryPi4 profile (#50)" #51
Issue:
"RaspberryPi4 profile packages are slighly behind upstream recipe" #50
And so our change was in step with upstream (openSUSE) kiwi-ng appliance configurations.

The trouble with adding a factory repo is that we invite the possibility of inadvertently pulling in unwanted bleading edge (read Tumbleweed) updates when we are attempting to stick as closely as possible to the upstream Leap's of our respective profiles.

As see from your associated pr:
"added repository for raspberrypi-eeprom" #64

That you have proposed the lower priority for this repo so that should guard against this, as per our shells addition.

@FroggyFlox I know you proved your additions at the time, as demonstrated in the referenced pull request of yours re the addition of this package to bring us more in line with upstream.

Could this be a Leap 15.2 Leap 15.3 profile difference requirement. In which case we need to address that head-on and adjust our package lists as per upstream. In the link @FroggyFlox used we have for Leap 15.3:

https://build.opensuse.org/package/view_file/openSUSE:Leap:15.3/kiwi-templates-JeOS/kiwi-templates-JeOS.changes?expand=1

Showing the addition of the package without additional repos.

Where as in the equivalent Leap 15.2 JeOS template changes:

https://build.opensuse.org/package/view_file/openSUSE:Leap:15.2/kiwi-templates-JeOS/kiwi-templates-JeOS.changes?expand=1

We see no equivalent addition of the "raspberrypi-eeprom" package.

see: https://build.opensuse.org/package/view_file/openSUSE:Leap:15.2/kiwi-templates-JeOS/JeOS.kiwi?expand=1

So from a little initial look, I think what we have here is a self imposed regression in our Pi4 Leap 15.2 profile where we inadvertently added a package for all Pi4 profiles that is not used in our upstream 'guide' of the JeOS appliance configs in the 15.2 variant but is used in the 15.2. If I have this correct then the proper fix would be to fix our addition of the raspberrypi-eeprom package to only pertain to the Leap 15.3 profile. Rather than introduce an otherwise un-required Tumbleweed repo.

@FroggyFlox Could you check my workings on this one. Did we end up only confirming the Leap 15.3 profile by chance.

@pasyn Thanks again for reporting this. Could you confirm if your build and consequent install of a Pi4 Leap 15.2 profile works OK if you first delete the following line from the kiwi-ng config:

        <package name="raspberrypi-eeprom" arch="aarch64"/>

If so then I suspect the preferred fix is to have split Pi4 package profile sections. One for Leap 15.2 based profiles and one for Leap 15.3 based profiles. I.e. we currently have:

    <packages type="image" profiles="Leap15.2.RaspberryPi4,Leap15.3.RaspberryPi4">

So the Leap 15.2 and 15.3 based package selection, specific to this profile, are combined.

@FroggyFlox again your input on this, when you get time, would be much appreciated as I suspect you have been looking at this area more closely than myself of late. Thanks.

I'll try and have a closer look at this myself shortly.

[FroggyFlox]

@phillxnet , I can't recall and I obviously should have been a lot more clear in my PR and Issue discussion about that, but I might have indeed focused on Leap 15.3 as that was our target.
I'll try to verify building on both Leap 15.2 and 15.3 as soon as I can.

[FroggyFlox]

@phillxnet, I just checked my buildbot logs and I apparently saw that exact same thing 2 months ago: no problem with the 15.3 profile, but the 15.2 profile fails as no provider for raspberrypi-eeprom can be found.
It thus seems to be something that was always there but that I somehow forgot about or disregarded at the time as it was Leap 15.2... my sincere apologies for that one; I can't believe I messed that one up like that.

[pasyn]

@phillxnet you were right about the need to split the profiles for 15.2 and 15.3. raspberrypi-eeprom is not in the upstream kiwi template for JeOS 15.2.
https://build.opensuse.org/package/view_file/openSUSE:Leap:15.2/kiwi-templates-JeOS/JeOS.kiwi?expand=1

Upon researching the raspberrypi-eeprom package, It looks to only be used for updating the bootloader and as such is only required if automated bootloader updates have been implemented in the OS.
https://github.com/raspberrypi/rpi-eeprom

I have separated the profiles and built images for both 15.2 and 15.3 with no errors. Both images boot successfully on the Pi4 and allow me to log into the web UI.

[phillxnet]

@FroggyFlox Re:

I can't believe I messed that one up like that.

No worries and my apologies for not checking this myself. 15.2 is/was our main target but we have had a lot on with adding the new Leap 15.3 to our backend buildbot so it looks like we both got distracted with that. But thanks to @pasyn (and your buildbot logs) we are now in-the-know. Plus once we have our installer builder on a regular schedule such things should drop out of the woodwork. I'm just surprised it wasn't reported earlier actually. All in good time it looks like.

@pasyn Re:

Upon researching the raspberrypi-eeprom package, It looks to only be used for updating the bootloader and as such is only required if automated bootloader updates have been implemented in the OS.
https://github.com/raspberrypi/rpi-eeprom

Thanks, I'd thought it was something like that. Good to know.

I have separated the profiles and built images for both 15.2 and 15.3 with no errors. Both images boot successfully on the Pi4 and allow me to log into the web UI.

Excellent. Thanks for your efforts on this one. Much appreciated. I'll look to the pull request shortly.

[phillxnet]

@FroggyFlox It has rather belatedly dawned on me that our recent adoption of GitHub Actions may have a place to play in this repo also. I.e. we build each profile in turn just to see if it errors out. Hopefully this isn't an abuse of the service as that's quite the compute requirement. But is, in-itself, a completely legitimate use. What you you think? Likely we will encounter limitations in being able to build the ARM64 profiles though. I just not that up on Actions just yet. Just a thought.

[FroggyFlox]

@FroggyFlox It has rather belatedly dawned on me that our recent adoption of GitHub Actions may have a place to play in this repo also. I.e. we build each profile in turn just to see if it errors out. Hopefully this isn't an abuse of the service as that's quite the compute requirement. But is, in-itself, a completely legitimate use. What you you think? Likely we will encounter limitations in being able to build the ARM64 profiles though. I just not that up on Actions just yet. Just a thought.

I had the exact same reaction.
The way I see it would be related to our previous discussion on building this on OBS (this is what kiwi excels at after all). With all the improvements made by the OBS team for SCM integration, one could "easily" setup a github action to trigger the build on OBS and return the results back to the Github PR.

[phillxnet]

@FroggyFlox
Re

With all the improvements made by the OBS team for SCM integration, one could "easily" setup a github action to trigger the build on OBS and return the results back to the Github PR.

Agreed, that's a much better idea. Especially given the resulting images would then be available on OBS (I'm assuming) which would be rather handy. And with kiwi-ng being 'native' to OBS we are on a more supported platform. But the "easily" bit here is rather more in context with your abilities in this area than mine I'm afraid. :).