Installing log history on Motherboard

I have got computer with motherboard “Gigabyte” H310M M.2 2.0

When I want to install linux from usb stick (“Transcend Datatraveler”) motherboard shows me many previous instalation images, and asks me to choose one. Problem is that I don’t know which is last and, also, which is “root image” (since there are images named something like “…” “…part1”, “…part2”… I can not remind now). Is there any way to turn this saving previous images of and to see just image placed on USB now?

Thank you for answering my qusetions.

The openSUSE Leap 15.4 download site <; indicates that, the latest bootable offline installation image for Intel or AMD 64-bit desktops, laptops, and servers (x86_64) is:

  • openSUSE-Leap-15.4-DVD-x86_64-Build243.2-Media.iso

Load OS from USB drive, not from internal disk.

When you download images with a downloader, such as curl or wget, instead of a web browser, it will usually preserve all the characteristics of the image downloaded. This includes either the date the image was originally created, or the date the image reached the mirror host, whichever appears in the file listing that appears when you load the host location in a web browser. Some web extension may be available for your browser that will match this behavior. When you maintain original source dates on your downloads, it’s usually pretty easy to tell which is newest.

Your use of “motherboards” makes it unclear to me where and what installation images you are referring to.

Indeed, I puzzled over that myself :slight_smile:


Perhaps you could post a screen shot so we are better able to see your problem.

Also, how did you create the USB image?

I installing from usb stick image online (download online installation file, and then with SUSE Studio Image-writer.

First, I really did it, because there was not other solution to boot system. But tat can not be finally solution, wouldn’t it? But suddenly things went well. Now I use 15.4, but: in future, if I wanted to install it again, what would I do when system asked me to choose? Also, this is not the first OpenSuSE linux that this happened to.

This started to happen when I buy this computer. That is why I mention motherboard.

When you install an .iso image to a USB stick, all information on the stick from its start, for the length of the .iso size, is replaced with the .iso content. Any remaining space past the .iso size becomes inaccessible. There’s no way to have on the stick’s electronically accessible media surface anything to indicate what was on it prior to the most recent .iso installation onto it, as if the current .iso content is all that was ever on the USB stick. Earlier installed .isos need to be recorded or saved in some manner other than using a USB stick on which installed. A large size USB stick could be used to save a number of .iso files by copying them to a big stick’s much larger filesystem, in same fashion as saving those .isos to a HDD or SDD.


The iso bios of Leap, TW, etc, are hybrid isos, that is, they can be booted in legacy rom mode or in uefi mode.
The motherboard has an option in the bio, which is called compatibility mode, (CSM) if the same usb pendrive is active, it appears as two different devices (being the same pendrive).
In the bios you can choose to disable CSM or choose Legacy rom (MBR) or a UEFI (Gui GPT) , or use the UEFI boot menu, which is a function key F that you press on post power on the pc, all devices appear there (depends on CSM).
With HDs, it would be the same if you keep the old fat partitions. almost better if you have nothing, use a partition program, or the one from yast.
The fat partitions in UEFI with their boot managers have a link to /bott/efi And there the possible directories and boot devices are housed Example one for openSUSE , another for Microsoft, etc… (in my case I prefer to have them separated and in the case of fat (which can be in 12, 16 and 32), there is no problem, openSUSE uses fat16 and win fat32, so they can be independent on different partitions.

It’s easy to see the devices (boot candidates, from linux) using the efibootmgr command:

HP-OMEN:~ # efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
Boot Order: 0001,0000,0002,9999
Boot0000* Windows Boot Manager
Boot0001* opensuse
Boot0002* Solid State Disk
Boot9999* USB Drive (UEFI)

In this case, the order is 1st 1 openSUSE and the second is win 3th number zero.
I recommend UEFI, you have more than 200 or so primary partitions, gpt partitions with redundancy in the tables, and a long etc…
Secure boot if you don’t use it, you can disable it from installation or from yast boot and boot order the same, you can set it from yast boot.
This is a very broad topic, in my case I use a translator from Spanish to English, if I make a mistake, I apologize, also here you have many well-informed people who can help you with this.
Thank you and a very cordial greeting.

openSUSE uses FAT32 by default to be compatible with Windows.


That you know that partition has nothing to do with compatibility, if at first I used the same win code for the partitions (code ---- no format), I thought it was the 0700 that matched win with linux, but not for uefi partitions with boot content that then links to /boot/efi , for years, I’ve always seen fat16 and win fat 32 .
Although you can change it in options (uefi needs 12-16-32, anyone is fine).
Do the test yourself, see if yours is by default : with lsblk -fm :

 HP-OMEN:~ # lsblk -fm
sda 931.5G root disk brw-rw----
│ **vfat FAT16** 4271-B3B5 499.4M 0% /boot/efi 500M root disk brw-rw----
│ btrfs 5f9d5d1d-0378-44dd-bc6d-e83a9ff692d3 28.5G 43% / 55G root disk brw-rw----
│ btrfs 5d5289fc-d514-4e43-81bf-328b1c9f0c94 60.1G 93% /home 841.4G root disk brw-rw----
     swap 1 26ca2efd-a84f-45af-a2d7-169b51be2953 [SWAP] 31.2G root disk brw-rw----
sdb 931.5G root disk brw-rw----
     btrfs A-SN750
                        a2ab7d23-c063-4a72-bfaf-9db7c77bca8f 931.5G 0% /run/media 931.5G root disk brw-rw----
sdd 465.8G root disk brw-rw----
     btrfs ZERO 48f7a128-e55f-4b3a-a51e-4a7b2a9caf13 25.9G 94% /run/media 465.8G root disk brw-rw----
sde 465.8G root disk brw-rw----
     btrfs M1 50105077-9b47-406e-a06c-5b9b20a7df9d 420G 10% /run/media 465.8G root disk brw-rw----
sdf iso966 Jolie openSUSE-Leap-15.4-DVD-x86_64243
│ 2022-05-28-00-52-28-55 465.8G root disk brw-rw----
│** vfat FAT16** openSUSE-Leap-15.4-DVD-x86_64243
│ 8287-3151 3.4M root disk brw-rw----
     iso966 Jolie openSUSE-Leap-15.4-DVD-x86_64243
                        2022-05-28-00-52-21-74 3.8G root disk brw-rw----
│ 931.5G root disk brw-rw----
│** vfat FAT32** 72D9-B88A 260M root disk brw-rw----
│ 16M root disk brw-rw----
│ ntfs WINDOWS
│ AC88A47288A43CA8 465.7G root disk brw-rw----
│ntfs Windows RE tools
│ 00A65BD8A65BCD32 980M root disk brw-rw----
     ntfs data-WIN-LINUX
                        4CBDD65F0A0B0A86 253.6G 45% /run/media 464.6G root disk brw-rw----

There you have an example win10 fat32 and openSUSE fat 16 .

Uefi if what maintains compatibility with legacy rom, that is, the zero page of the disk, has 4 of 8-bit registers and 2 of 16-bit registers that give the information of the partitions, what is left over from that is the area for the mbr ( 512-64) 448bit ; but the difference is that uefi doesn’t just read logs, it also reads filesystems, so you need a /boot/efi , be it win or linux or mac . The uefi regulations are in pdf and you can download it from their org. but it is too big to read in a short time. Generally, the PC power-on messages coincide in EFI and UEFI, but then each one goes its own way. (I’m sure you understand what I’m saying). Thank you for your comment and sorry if the translator fails in any sentence.

Best regards .

Edit:At present the code of the partitions has changed, now it uses the linux (but the fat16 is maintained).


The case I was commenting on, keeping the startups separate:

**HP-OMEN:~ #** tree /boot/efi/EFI 
└── **opensuse** 
    └── grubx64.efi


The case I was commenting on, keeping the startups separate:

If I hadn’t, there would be another directory called microsoft with its corresponding boot .

I had read UEFI specs from They declares FAT32 for ESP for fixed drives. Microsoft follows these recommendations. I had created this bug report about issue, and openSUSE developers had changed default installer settings accordingly.