clone leap 15.3 repo

First off: I’m sorry if this is the wrong sub-forum - but I couldn’t think of any better. If some mod thinks this fits better in another sub-forum - please feel free to move. Thanks in advance.

So, according to roadmap, the gold master for 15.3 was built within the last few hours and the public release is planed for upcomming wednesday. As I would like to get my hands on it from the very first moment I have a, for me rather unusual, question: How to “clone” the current leap 15.3 repo without registering as official mirror to be able to use rsync?

Sure, I could write some small webcrawler getting a file list from the web frontend and either download that within my crawler or just use wget or curl. But I’d like to prefer not to if there’s another way to get a full copy of the current public repo.

Any advice is appreciated.

As far as I know, the gold master has been delayed for a few days. There was a message about that on the factory mailing list.

It’s silly to wait for the “official” release. Get your pleasure from, install, and you can have the same thing via normal online updating as soon as the release turns official.

Cut down version: I had to download the net-boot image to get grub loading via PXE.

grub.efi from the current net-boot image was created at 12.05.21 and is 1.194kb
grub.efi from the repo was last modified at the same date, but is 1.406kb and fails to correctly verify during secure boot signature check

So I’d like to have a look into the data (maybe even source and/or build process?) to figure out why the image contains a different binary than what’s available on the repo - and why the file in the repo has some signature issues.

background story: I moved away from optical boot media years ago and, at least for some time, used usb boot media. But as I deal with some old hardware from time to time I come across some systems not able to boot from removable media - some even only have 1.x ports. Hence I set up my network for PXE boot which grew over the years to a quite some powerful system. Since about 13.x I just download some boot files directly from the repo - and never had issues since - neither in legacy bios / csm mode nor in uefi mode (even with enabled windows secure boot option). I’m not sure if it’s just the current “still yet not final golden master”-status causing it - or some other issues currently maybe not known or still in fixing. But as 15.2 already lacks some needed updates (as one major example: 15.2 only comes with glibc 2.26) I’d like to upgrade to a stable next minor asap.

All I’ve ever needed to begin a net installation is for Grub to load these two files:

    Nearly every installation I do is done just this way. If the PC has no OS at all, I first do a “maintenance” boot merely to pre-partition and install Grub. I’ve never found it necessary to setup PXE.

On my desktop (running 15.3):

ls -l /boot/efi/EFI/opensuse/grub.efi
-rwxr-xr-x 1 root root 1222656 May  6 06:50 /boot/efi/EFI/opensuse/grub.efi

That should be what’s in the repo.

If you use the “shim.efi” from Leap 15.2 and “grub.efi” from Leap 15.3, those probably don’t mix and might fail secure-boot.

Simply use one of the openSUSE mirrors to get the job done. (And you’ll want to adjust these to 15.3 when it’s “Gold” of course)

You can find a list of rsync:// servers from here; and you can use something like this to mirror all the content, excluding some stuff you may or may not want. These are what I use since I live in Finland;

The entire 15.2 distribution, including oss and non-oss:

rsync -a --progress rsync:// /srv/www/htdocs/distribution/leap/15.2/repo/

I also mirror the update repo and Packman so I can just use my local nginx webserver with exactly the same paths and just change the hostname using Saltstack on multiple machines:

rsync -a --progress --exclude="oss_debug*" --exclude="src/*" rsync:// /srv/www/htdocs/update/leap/15.2/


rsync -a --progress --exclude="src/*" --exclude="aarch64/*" --exclude="aarch64_ilp32/*" --exclude="armv7hl/*" --exclude="*debuginfo*" --exclude="*debugsource*" rsync:// /srv/www/htdocs/packman/suse/openSUSE_Leap_15.2/

Naturally you’ll want to use mirrors close to you and alter the rsync paths a bit. You can grab them from the mirrors page rsync:// links.

That is image from grub2-x86_64-efi-2.04-20.4.noarch

grub.efi from the repo was last modified at the same date, but is 1.406kb and fails to correctly verify during secure boot signature check

Unless you explain what you mean it is hard to comment. Post link to this file. The current grub2 package is grub2-x86_64-efi-2.04-20.4.noarch which matches content of installation images (which is not surprising as installation images are created using actual distribution packages).

So I’d like to have a look into the data (maybe even source and/or build process?)

openSUSE installation image is built using kiwi configuration in 000product “package”, specifically and; the installer part is created by installation-images package and basically copied over into installation image.

Then how you would boot some diskless old hardware not able to boot of usb? And with diskless I not just mean “no HDD” - but no drives at all - so also no optical drive one could throw in a boot cd. I actually do come across such old hardware every once in a while (many of them are just 32bit) without any drives and unable to boot from usb - so there’s no way to perform a “maintenance boot” to get the train wreck rolling again. Also: Sure, if you already have a boot loader that the bios is able to start you may only need a kernel and init-ramdisk - but what about a dead system without any boot loader (no matter which one)? THAT’s the reason why I started to set up PXE - and with modern systems using GBit links it’s also quite fast and spares me the need for hunting down a portable optical drive to boot some decade old boot cd or have to play around with easy-to-break thumbdrives. Just plugging in power, network, display output and keyboard/mouse input - and hit the power switch.

Nope, just using /efi/boot/bootx64.efi - which in turn loads /efi/boot/grub.efi - which then loads all the other grub-related stuff. No use of shim.efi. Downloading these files from the 15.2 repo works out of the box. Downloading the same files from 15.3 repo ends up in the uefi throwing a signature error. Fun fact: I even get another error (“image not useable”) when disabling windows secure boot. So, it seems not just the signature is off - but the entire binary has some issues.

I’ll have a look into that. Thank you for sharing.

I’m not speaking of any packaged file - just open the browser - go to - navigate to the leap 15.3 repo - and grab and grub.efi. Then using any dhcp+tftp to have any uefi system I own boot the bootx64.efi file - which seem to work fine as it gets executed to load the grub.efi - and then I run into a signature error.
But, when I download the current net-install iso and use the files contained within it - bootx64.efi seems to be the same file - same timestamp, same size … but grub.efi differs as posted. This leads me to the possible option, that for what ever reason is somehow a different file than the one within the pre-packaged iso files - and maybe within the current rpm packages - but I didn’t check the latter ones. And it’s different in such a way that it causes signature error with enabled windows secure boot option - and some strange “unusable image” log when secure boot is disabled. So, for what ever reason the file I’m able to obtain by just downloading it with my browser “doesn’t work” (quotation intented as “doesn’T work” is no meaningful error explanation - but I provided the exact issue prior to that).
I’m unable to get further down into WHY it fails - as I don’T have enough knowledge about how uefi pxe boot work down at the bit level - but it seems that my rather modern systems just have some issues with that file.

The “bootx64.efi” on the installer is actually “shim.efi”, just renamed to “bootx64.efi” because that’s the file that the UEFI firmware automatically loads.

$ file grub.efi
grub.efi: PE32+ executable (EFI application) **Aarch64** (stripped to external PDB), for MS Windows

This is ARM, not Intel.

Those files are never used directly for booting. As you have seen yourself, images have correct bootloaders matching image architectures. But you can have just one grub.efi …

If you are really concerned, open bug report. While there is nothing to fix directly, situation is confusing so probably some different layout needs to be implemented.

I cannot recall ever running across a PC capable of PXE boot that is incapable of booting OM, nor a PC I would even want to boot from the LAN. For me it’s much easier to locate an appropriate existing installation disc than a corresponding USB stick. I only relatively recently started trying first to boot USB rather than OM.

Compared to OM, USB media is a PITA:

  • no room to write on them what it is that’s on them*]no uniformity of size and shape to facilitate media management*]lots more expensive than a RW disc*]OM never interferes with device naming as USB boot can
    For the really ornery ones I clone an installation to its disk, or install to its disk, by installing that disk in some other PC, or add a 2nd disk or optical drive to the PC temporarily to enable installation.

Thus, I’ve yet to need PXE.

It is already tracked by

Thank you for sharing - wasn’t aware of that.

OUH SNAP - ok, THAT explains why any of my x86_64 hardware fails to do anything with it - cause it’s for ARM … well, that explains the “unusable image” error with secure boot disabled - but I still don’t get the signature error. Are the ARM files signed by a different key than x86_64? But both should link up to the same ROOT key - or are there even different ROOT keys for different arch?

Again - without ANY drive - so even using any optical media is NO option at all. The systems are completely stripped - no drives whatsoever. And yes, although I myself not encountered any such system yet, but I know from a friend, who actually encountered following TWICE: a rather modern x86_64 system already with usb3 not able for what ever reason to boot from removable media as from usb thumbdrives. Fun fact: It was no faulty thumbdrive or damaged port but actual firmware/bios/uefi/“however you want to call it” bugs. One system had an issue with detecting any removable media at all - only direct attached drives via s-ata, and the other system although it was able to detetct the external drives was somehow unable to boot from it. Both was fixed by flash current patches - so it seems those were first-batch systems with pre-final bioses.
So even for those post-2010 systems for us there were no other “practical” option to boot them without plugging in a direct attached drives via s-ata than PXE.
And although my friend sure has some spare HDDs we both don’t have any internal optical drives anymore for years. We both just ditched that ancient tech years ago. And I currently don’t have any HDD left to spare for such systems - but even if I would need to load ANY bootloader onto it in the first place. Any other HDDs are cold-spare for my storage arrays and not availble to other systems.