Can't boot Tumbleweed 32bit

…from grub created by Debian 10

error: file '/boot/vmlinuz-5.6.11-1-pae' not found
error: you need to load the kernel first

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'openSUSE Tumbleweed (on /dev/sda6)' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-xxxxxxxxxxxxxx' {
    insmod part_msdos
    insmod btrfs
    set root='hd0,msdos6'
    if  x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6  xxxxxxxxxxxxxx
    else
      search --no-floppy --fs-uuid --set=root xxxxxxxxxxxxxx
    fi
    linux /boot/vmlinuz-5.6.11-1-pae root=UUID=xxxxxxxxxxxxxx ${extra_cmdline} splash=verbose mitigations=auto
    initrd /boot/initrd-5.6.11-1-pae
}

Is please grub code correct ?

No. /boot on SUSE is relative to default subvolume (i.e. default snapshot). Upstream grub always treats btrfs pathnames as absolute. SUSE grub has patches to resolve pathnames relative to default subvolume. So grub configuration that is correct for SUSE is wrong for any other grub that does not have these patches.

The options are

a) use different filesystem type for root on openSUSE
b) disable snapshots during openSUSE installation; it changes grub behavior to be more upstream compatible
c) have /boot on separate partition

Thank you. Is it please possible to make c) option by means of other distro than OpenSUSE ?

I’ve created new ext4 boot partition.
Grub from Debian 10 did not found this new /boot partition so I’ve added this code into grub and it’s solved:

menuentry 'openSUSE Tumbleweed ( /dev/sda6) ' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-**UUID-OF-BOOT-PARTITION**' {
n
    insmod part_msdos
    insmod **ext2**
    set root='hd0,**msdos7**'
    if  x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,**msdos7** --hint-efi=hd0,**msdos7** --hint-baremetal=ahci0,**msdos7**  **UUID-OF-BOOT-PARTITION**
    else
      search --no-floppy --fs-uuid --set=root **UUID-OF-BOOT-PARTITION**
    fi
    linux /boot/vmlinuz-5.6.11-1-pae root=UUID=XXXXXXXXXX ${extra_cmdline} splash=verbose mitigations=auto
    initrd /boot/initrd-5.6.11-1-pae
}

/dev/sda6: openSUSE root partition (UUID=XXXXXXXXXX)
/dev/sda7: new /boot partition

Changes to original code are in red color.

change to /etc/fstab was needed too:

UUID=UUID-OF-BOOT-PARTITION  /boot/grub2  ext4   defaults  0  0
zypper dup

upgrades kernel on sda6 /boot partition only although yast2 partitioner show /boot is correctly mounted on sda7

Is it please possible to make zypper to upgrade kernel on (new) sda7 /boot ?

I believe we need more information from:

blkid
cat /etc/fstab
mount | egrep -v "cgroup|rpc|tmpfs|^sys|on /dev|on /proc|on /sys|on /var" | sort '

This new partition cannot be /boot as otherwise kernel path on this partition would have been just /vmlinuz-5.6.11-1-pae.

This is wrong in general. grub expects grub2 to be subdirectory below /boot, not reside on completely separate partition.

Everything you described so far confirms that /boot is not mounted on sda7 (or whatever new /boot partition was supposed to be).

So Debian’s grub has booted kernel on openSUSE partition (which is btrfs) ?

# blkid
/dev/sda1: UUID="...;" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c..."
...
/dev/sda6: UUID="SDA6_UUID" UUID_SUB="8..." BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="c...-06"
/dev/sda7: UUID="SDA7_UUID" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c...-07"
# cat /etc/fstab
UUID=SDA6_UUID  /                    btrfs  defaults                      0  0
UUID=SDA6_UUID  /var                 btrfs  subvol=/@/var                 0  0
UUID=SDA6_UUID  /usr/local           btrfs  subvol=/@/usr/local           0  0
UUID=SDA6_UUID  /tmp                 btrfs  subvol=/@/tmp                 0  0
UUID=SDA6_UUID  /srv                 btrfs  subvol=/@/srv                 0  0
UUID=SDA6_UUID  /root                btrfs  subvol=/@/root                0  0
UUID=SDA6_UUID  /opt                 btrfs  subvol=/@/opt                 0  0
UUID=SDA6_UUID  /home                btrfs  subvol=/@/home                0  0
# UUID=SDA6_UUID  /boot/grub2/i386-pc  btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=SDA7_UUID  /boot/grub2  ext4   defaults  0  0
UUID=SDA6_UUID  /.snapshots          btrfs  subvol=/@/.snapshots          0  0
# mount | egrep -v "cgroup|rpc|tmpfs|^sys|on /dev|on /proc|on /sys|on /var" | sort 
/dev/sda6 on /home type btrfs (rw,relatime,space_cache,subvolid=264,subvol=/@/home)
/dev/sda6 on /opt type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@/opt)
/dev/sda6 on /root type btrfs (rw,relatime,space_cache,subvolid=262,subvol=/@/root)
/dev/sda6 on /.snapshots type btrfs (rw,relatime,space_cache,subvolid=266,subvol=/@/.snapshots)
/dev/sda6 on /srv type btrfs (rw,relatime,space_cache,subvolid=261,subvol=/@/srv)
/dev/sda6 on /tmp type btrfs (rw,relatime,space_cache,subvolid=260,subvol=/@/tmp)
/dev/sda6 on / type btrfs (rw,relatime,space_cache,subvolid=267,subvol=/@/.snapshots/1/snapshot)
/dev/sda6 on /usr/local type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/usr/local)
/dev/sda7 on /boot/grub2 type ext4 (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)

I was able to boot TW by copying boot files from sda6 to sda7 and modifying grub file but it does not work anymore for latest kernel after debian grub update and installation.

There is error “**vmlinuz… not found, you need to load the kernel first”.

This problem does not happen with old 5.6.11 kernel (but booting stops for known reason).

Was there please some changes in TW 32bit kernel which could cause this problem ?

Which kernel version is the one that worked last? When was it installed? I sense it was quite some time back, before the kernel was removed from /boot/, replaced by a symlink to the kernel in /usr/lib/modules/<version>/vmlinuz on systems lacking a separate filesystem just for mounting on /boot/. That happened back around the first of this year. Making a kernel copy since that change involves more effort.

5.12.9
2021 July 1

Thank you it’s as you’ve said. Copying files from /usr/lib/modules/<version>/ has solved the problem.