irst boot after fresh install fails: missing iso8859-1 to mount vfat efi partiition

English Install/Boot/Login
1

Hi, I just installed lead 15.2 . But booting fails due to missing iso8859-1 charset. Worked around this by commenting
out efi partition from /etc/fstab. Another way to get around is to extend default mount option with nofail.

But how to get this charset to mount a vfat partition?

jarada:~ # mount /boot/efi
mount: /boot/efi: wrong fs type, bad option, bad superblock on /dev/sdc2, missing codepage or helper program, or other error.

from dmesg:
621.370937] BTRFS info (device nvme0n1p6): qgroup scan completed (inconsistency flag cleared)
868.975457] FAT-fs (sdc2): IO charset iso8859-1 not found

Gruß
Stefan

2

I suppose you could remove the “iocharset=iso8859-1” mount option from /etc/fstab (and maybe replace it with “utf8=false”, although I don’t necessarily see why you’d want that really).

You probably should better post your not-working fstab entry here though if you want help.

3

Hi, my fstab entry looks like:

UUID=9014-A36B /boot/efi vfat defaults,nofail 0 2
#UUID=9014-A36B /boot/efi vfat defaults 0 2

The commented one is from installation.

4

Hm, ok, so it fails to mount with the “defaults” default options…

I cannot check right now, but I would be a bit surprised if that wouldn’t be supported anymore.
At least the results I get from a quick google search would indicate a “problem” with the kernel.

What kernel packages do you have installed?

zypper se -si kernel

Maybe it would work if you replaced “defaults” with “utf8=true”?

5

zypper looks quite ok but /proc/version definitely NOT:
jarada:~ # zypper se -si kernel
Loading repository data…
Reading installed packages…

S | Name | Type | Version | Arch | Repository
—±----------------------±--------±-------------------±-------±-------------------------------
i+ | kernel-default | package | 5.3.18-lp152.26.2 | x86_64 | Hauptaktualisierungs-Repository
i | kernel-firmware | package | 20200107-lp152.1.1 | noarch | Haupt-Repository
i | purge-kernels-service | package | 0-lp152.4.1 | noarch | Haupt-Repository

jarada:~ # cat /proc/version
Linux version 5.4.0-40-generic (buildd@lcy01-amd64-011) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020

Yes I’m experimenting with new distros and Kubuntu is one of them. I’ll do some checks with grub.cfg. Have two of them one in /boot/grub2 and one in /boot/grub.

6

Yeah, that kernel definitely won’t be able to load the installed openSUSE Leap 15.2 kernel modules.

7

Hi I regenerated grub.cfg with grub2-mkconfig >grub.cfg.

Guess how the first entry looks like:

### BEGIN /etc/grub.d/10_linux ###
menuentry 'openSUSE Leap 15.2'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-fee4128e-f6b7-4777-b7b8-9a4c674a6365' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd2,msdos9'
        if  x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos9 --hint-efi=hd2,msdos9 --hint-baremetal=ahci2,msdos9  a5ea4a23-f8b5-4c9f-b7e3-3a48c88f1292
        else
          search --no-floppy --fs-uuid --set=root a5ea4a23-f8b5-4c9f-b7e3-3a48c88f1292
        fi
        echo    'Loading Linux 5.4.0-40-generic ...'
        linuxefi /vmlinuz-5.4.0-40-generic root=UUID=fee4128e-f6b7-4777-b7b8-9a4c674a6365  ${extra_cmdline} splash=silent resume=/dev/disk/by-uuid/e01b9258-2fb1-4967-b512-416bff2e0781 mitigations=auto quiet
        echo    'Loading initial ramdisk ...'
        initrdefi       /initrd.img-5.4.0-40-generic
}

The “correct one” ™ which boots the kernel reported by zypper is some entries below.
And YES this one is able to mount the vfat partition without problems.

Thanks.

Is it possible to a attach the grub.cfg file (if someone is interested in)?

8

It seems to me that you use a separate /boot partition, that is shared between the two distributions.
You probably shouldn’t do that.

grub2-mkconfig will use the highest kernel version it finds as the default, and that happens to be the Ubuntu kernel.

With /boot on the root partition (or two separate /boot partitions, one for each distribution, if you insist on having a separate partition), everything should work fine.

You could explicitly set a different entry to boot (e.g. in YaST->Boot Loader), but you’d have to manually change it after each kernel update to boot the newer kernel.

Is it possible to a attach the grub.cfg file (if someone is interested in)?

No.
But you could upload it to susepaste.org e.g.

9

The default boot entry generated upon installation is:

menuentry 'Leap-15.2'  --class leap_15_2 --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-69774d55-8da2-4599-9c27-766b1012771d' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod btrfs
        set root='hd1,gpt9'
        if  x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt9 --hint-efi=hd1,gpt9 --hint-baremetal=ahci1,gpt9  69774d55-8da2-4599-9c27-766b1012771d
        else
          search --no-floppy --fs-uuid --set=root 69774d55-8da2-4599-9c27-766b1012771d
        fi
        echo    'Loading Linux 5.3.18-lp152.26-default ...'
        linuxefi /boot/vmlinuz-5.3.18-lp152.26-default root=UUID=69774d55-8da2-4599-9c27-766b1012771d  ${extra_cmdline} splash=silent quiet mitigations=auto
        echo    'Loading initial ramdisk ...'
        initrdefi       /boot/initrd-5.3.18-lp152.26-default
}

Did you tinker?