mounting USB from emergency shell

Latest TW kernel upgrade apparently built a bad initrd, so I landed in a rescue shell trying to recover /run/initramfs/rdsosreport.txt. But, something’s missing in trying to mount a perfectly mountable and common VFAT on sdX1 stick found by blkid, which from mounting on a normally running system I know has plenty freespace. Whether with no options, -t auto or -t vfat, mount attempts always return:

mount: /mnt: wrong fs type, bad option, bad superblock, etc......

I don’t see anything helpful in busybox help, and my googlefu for forums.opensuse.org must be broken, as I’m not finding anything resembling a howto or post marked solved for this scenario. Anyone here have some experience how to mount a VFAT stick from a rescue shell, or have an URL to share for a howto? I found using an EXT2 formatted stick works, so maybe I need to make one? Is there a module loadable from the shell that will allow vfat recognition? Does /etc/dracut.conf need an addition to include more than the normal default and enable VFAT from rescue shell?

The first thing to check when mount fails is dmesg output, not busybox help.

It is possible your rescue system has no software to support the VFAT file system type.

The error is normal when one tries to mount a file system that is not recognised (which you already tried to avoid by explicit adding -t vfat), or corrupted, or no file ssytem at all. When believing your explanation that it is mounted without problems on other Linux systems, I come to my suggestion above.

I’m can’t tell what it reports that might be or have been useful WRT the VFAT stick not mounting, or why the filesystems on NVME were not found. Are “SUBNQN field” and/or “Identify Descriptors failed” indicative of fatal errors?
https://paste.opensuse.org/34327932

  237.118347] FAT-fs (sda1): codepage cp437 not found

FAT driver requires NLS support for codepage that defaults to 437. There is no way to skip it. All NLS support is built as modules and initrd does not have them.

Default initrd includes fat/vvfat on EFI but not on legacy BIOS. If you added vfat manually you need to also add nls_cp437 (and likely nls_iso8859-1) kernel modules. If fat/vfat was added automatically you should open bug report against dracut which must add NLS modules matching CONFIG_FAT_DEFAULT_CODEPAGE (and probably CONFIG_FAT_DEFAULT_IOCHARSET) if fat/vfat are added.

I am not sure what is used as a rescue systyem, but when I would create a rescue system (a system that should run minimal things on a broad spectrum of hardware to be able to “rescue” a broken Linux system), then I would not bother myself by adding all sorts of esoterics like support for MS Windows features.

So what I ask myself (and there is no need to answer that, I am only an old grumbler) is why does one need a non-Linux file system during Linux system recovery?

Because this is what your off the shelf USB stick usually offers. Oh, and - surprise - that is the only file system supported on ESP …

Yes, and when I buy a desktop/laptop, there is Windows on it. But I of course will replcae that with openSUSE. And when I use Linux on my desktop/laptops, I will put a Linux file system (or more then one) on the mass-storage devices I use with it.

The only case that asks for a non-Linux file system is for direct exchange of data between Linux and non-Linux (with a multi-bootWindows on the same system or on removable mass-storage exporting/importing between the two system types. Never for native usage.

Sorry, that is beyond my knowledge. What is ESP and what has it to do with the choice of file system type in this case.

You haven’t experienced a UEFI computer natively yet?

The EFI ([b]Extensible Firmware Interface) system partition or ESP is a partition on a data storage device (usually a hard disk drive or solid-state drive) that is used by computers adhering to the Unified Extensible Firmware Interface (UEFI).
Without an ESP, no UEFI OS installation can be bootstrapped.

Oh yes, I now understand (UEFI/EFI is the term understood by me). I assume you mention that for completeness (of reasons to use non-Linux file system types on Linux) . Not as being a reason for the OP to use a non-Linux file system to copy something from in an emergency.

Did you mean to write fat/vfat was not added automatically? It seems to me on UEFI installations that necessary NLS ought to be automatically added.

I meant exactly what I said. If dracut decides to add filesystem driver it must make sure this filesystem driver is usable. Of course, fix will probably also cover the case of adding vfat manually, but that is just nice bonus.

It seems to me on UEFI installations that necessary NLS ought to be automatically added.

Computers do what they are programmed to do, not what seems right to you. You are not newbie to not know that you need bug report to fix problem.

This is not at all obvious.

The BIOS needs to read the EFI partition. The kernel does not need to access it.

My UEFI systems will boot just fine, even if I comment out the “fstab” entry for “/boot/efi”.

This thread is about a rescue environment. Nrickert expects it to be fully functional without access to the startup filesystem? Dracut has been around a long time. Maybe that’s what the dracut devs think too, why bug report dismissed WAD would be no surprise.

Everything needed for boot that is relevant to the EFI partition has already happened before the dracut rescue environment is active.

If something is that badly broken on the EFI partition, then you cannot get as far as starting a dracut shell.

You can’t imagine a need or desire to copy or rename a file or directory on the ESP? I can, and keep backups there in place.

It’s not unusual that I find it difficult to determine just what communication is being attempted in your terse non-native English writing style.

If dracut decides to add filesystem driver it must make sure this filesystem driver is usable. Of course, fix will probably also cover the case of adding vfat manually, but that is just nice bonus.
“Fix” implies brokenness. Are you agreeing with me that lack of vfat support in emergency shell constitutes brokenness?

Computers do what they are programmed to do, not what seems right to you. You are not newbie to not know that you need bug report to fix problem.
This issue isn’t about how to get a problem fixed. It’s about defining a problem in the first place, whether a reasonable candidate for a “fix” might exist. I may not be a newbie, but it is beyond my capacity to keep track of all the different trackers, and in which of them a report constitutes a waste of time, such as nvme support. 5.7.14 on Fedora 32, which might have been fixed after TW’s broken 5.7.11 was built, is working.

For what is available starts with understanding the BIOS/EFI installed and used.
I haven’t used such a system, but I’ve seen videos of BIOS/EFI environments that boot to a shell for various configuration possibilities… The exact name of some of those don’t come to mind immediately.
[Edit] Seems to me <maybe> one of these situations has to do with systems that support Fake RAID.

If the User determines he has such a system, then that needs to be identified.

Else,
The question probably is whether the system can boot to a GRUB2 prompt.
Unlike the BIOS/EFI prompt which will have its own peculiar methods,
You should also be able to mount a USB device (provided that device was recognized by the BIOS/UEFI) and IIRC there is a native way to do this although it’s likely also possible to mount a loop device.

TSU

Sure. But it isn’t the kind of thing you would be doing from a dracut emergency shell.

Maybe you can’t imagine it, but I can, and I certainly expect with any high profile or otherwise competent distro to be able to grab the first available USB device I can locate, which may be a brand new one, to copy rdsosreport.txt to, without having to first find a way to reformat it, and loose whatever it may already contain. Likewise, it does little good to have rdsosreport.txt existent if it can’t be shared with whoever needs to be able to interpret it.