UEFI Boot with ext2 /ext4

[jjflash]

First at all (like ever): please excuse my bad english, I'm an old man who had learned english nearly 50 years ago in school.

I don't know if this is the right place to post my problem, so I try it here.

I'm using Portues as my general and favorite system, primarily for developing software for microcontrollers and for standart application like office works, drawing circuit diagrams, surfing the internet, looking video-streams and so on.

So I've made some different USB-Sticks for general use and on two computers I've installed Porteus on harddisk using ext2 and ext4 file system. I have some restrictions, namely compiling different software packages (unsolved dependencies), but I can live with this limitation.

Let me say: Porteus is great, but I don't like to store changes in an filecontainer (that's the reason why I'm using ext2 / ext4).

My problem:

Now I have a computer with UEFI only and there is no compatible csm mode. I can install Porteus to an FAT32 System (by renaming bootx64.efi to boot.efi by puting this file to the root of an USB-stick, using a filecontainer).

But by using ext4 I'm not able to boot from a mass storage, neither from USB-stick nor from harddrive!

Is there a changes to boot Porteus from ext2 / ext4 file system?

Nice greetings,
JJFlash

[jjr]

Apologies if I failed to understand your situation. You can try to correct me.

With BIOS/CSM, Porteus can boot directly from practically any filesystem. That includes ext2 / ext4, as you're accustomed to.
UEFI firmware does not allow this.

UEFI (by its specification) boots only from an "EFI System Partition" (ESP), which is defined as a FAT32/FAT16 partition appropriately marked as ESP. It is marked by assigning it either the GPT GUID for an ESP or the MBR ID for an ESP. (Which type of marking depends on the partition table type: GPT or MBR.) In GParted, you can simply set the "esp" flag.

When you boot from a USB stick formatted as FAT32, UEFI firmware is "guessing" that you probably meant to mark it as ESP and didn't. In other words, Porteus install instructions are breaking the UEFI specification, hoping that the UEFI firmware is forgiving. This generally seems to work.

When the ESP is properly marked, all major operating systems (Windows / Linux / macOS) hide the partition and/or restrict you from mounting it. Also, most OS's use the ESP just to hold a tiny bootx64.efi chain loader, so you rarely need to access it.

As a consequence of all this, most users aren't aware of the ESP's existence or importance.
But with Porteus, it has to be minded.

In particular, Porteus was designed to have all its system files on the same partition. So for UEFI, that means putting all the Porteus system files on an ESP on your hard drive.

Bottom line

For UEFI, you must make sure your drive has a FAT system partition for Porteus to boot from. Copy the "EFI", "porteus", and "boot" folders from the Porteus ISO to it. Then you can allocate the rest of the drive for ext2 / ext4 workspace. This may be annoying if you like to have all your files on one filesystem.

Notes:

• There is a Porteus cheatcode ("from=") to load system modules from a different location, but I haven't tested it.
• I personally don't recommend using GParted for partitioning, because it's known to force hybrid GPT/MBR tables without warning, which can be dangerous. See warning article by the author of gdisk. On Linux I just use fdisk (which supports GPT).

[rych]

Is there a changes to boot Porteus from ext2 / ext4 file system?

For UEFI you'd have to have at least 2 partitions on your USB (or HDD): a small (~50Mb) FAT32 with all the boot and EFI stuff, and the ext4 holding your /porteus folder (with the /changes subfolder). Hopefully, that's going to be enough to boot: the /porteus folder will be automagically found and used. (If not, you could label the ext4 partition as Porteus and use the FROM:LABEL cheatcode).

I've never heard of the ESP marking and have always used GParted -- no problem just keeping it stupidly simple.

[Ed_P]

please excuse my bad english, I'm an old man who had learned english nearly 50 years ago in school.

You obviously got an A+ grade.

I can install Porteus to an FAT32 System (by renaming bootx64.efi to boot.efi by puting this file to the root of an USB-stick, using a filecontainer).

Is your system a 32 bit system? EFI is rare with 32 bit systems.

As jjr has noted EFI files/folders must be on a FAT32 partition, which means the Porteus EFI folder must be on a FAT32 partition. The partition can be small and must be classified as bootable. The /porteus folder can be copied to an eft4 partition if you don't want to maintain a changes file and to do that you need to change the /boot/syslinux/porteus.cfg file's APPEND lines to reference the eft4 partition, this done with the cheatcode from=.

With USB drives which can be mounted on different systems the mounted drive's name can vary. On my older Dell my USB drive mounts as sdb1 on my newer Dell it mount as sda1. So to ensure flexibility when referring to the drive I recommend using it's UUID code. Thus for your from= cheatcodes I suggest from=UUID:string-of-characters/porteus. (line 439 /boot/docs/cheatcodes.txt)

For creating your bootable USB drive I share with you these notes of mine.

Code: Select all

## Run GParted to partition & format the USB drive with a msdos Partition table.  ##
##  Use GParted's View > Device Information to check Partition Table type.        ##
##  Use GParted's Device > Create Partition Table if Partition Table shows as GPT.##
## Or under Windows use:                                                          ##
## > diskpart          * Run Command Prompt with Admin Rights.                    ##
## > list disk                                                                    ##
## >....                                                                          ##
## > select disk 1     * Note: disk nbr is the nbr of the USB disk                ##
## > clean                                                                        ##
## > create partition primary                                                     ##
## > exit [/code[

[jjr]

I've never heard of the ESP marking

It's a core part of the UEFI spec. UEFI is not guaranteed to recognize a random FAT32 partition as an ESP, so I always mention this when troubleshooting UEFI.

OS designers certainly don't ignore this.

System Partitions are discovered when required by UEFI firmware by examining the partition GUID and verifying that the contents of the partition conform to the FAT file system as defined in File System Format. Further, UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID.

https://uefi.org/specs/UEFI/2.10/13_Pro ... partitions

ESP GUID is in Table 5.7:
https://uefi.org/specs/UEFI/2.10/05_GUI ... type-guids

How this works with MBR:

If an MBR partition has an OSType field of 0xEF (i.e., UEFI System Partition), then the firmware must add the UEFI System Partition GUID to the handle for the MBR partition.

In other words, MBR ID 0xEF "translates" to the ESP GUID.

and have always used GParted -- no problem just keeping it stupidly simple.

Since you dismiss the link, I will just say that one of the problems with hybrid tables is when you run some program that operates on only ONE of the two tables, they become out of sync, and your drive becomes corrupted when the non-synced table is used.

Doing things "stupidly simple" is the way to trigger Murphy's Law down the road, IME.

I would say - no problem doing things safely, when possible.

[jjr]

Fixed the UEFI spec links.

[jjr]

and have always used GParted -- no problem just keeping it stupidly simple.

[..]
Since you dismiss the link, I will just say that one of the problems with hybrid tables is when you run some program that operates on only ONE of the two tables, they become out of sync, and your drive becomes corrupted when the non-synced table is used.
[...]

Another issue I forgot - Windows ignores the GPT when it finds an MBR.
This makes it unable to access hybrid volumes over 2 TiB (created with GParted).

See, doing things the "stupidly simple" but unsafe way can cause issues..

[rych]

when you run some program that operates on only ONE of the two tables

For example? (The only corruption I've ever faced in my Porteus is from the new ntfs3 kernel driver NTFS3 Kernel Module. Could it be due to the poor MBR/GPT/hybrid partition table choice?!) Thanks for sharing the concerns about EFI and GParted, I didn't know. But should the beginners like myself really know all that if the simple recipe works: make 2 partitions, FAT32 and ext4 with GParted and it works for years without any apparent issues (or maybe there are issues?)?! It's about pedagogy and a learning curve too: first try the simple method. In the off-chance there is problem, dig out some specifications or exotic warnings. Most of us just want to quickly boot and get on with our lives.

FAT32 partition. The partition can be small and must be classified as bootable.

In practice, no real need for it to be marked "bootable" for UEFI.

APPEND lines to reference the eft4 partition, this done with the cheatcode from=.

Apparently, the /porteus folder will be found even without the "from:" cheatcode.

I suggest from=UUID:string-of-characters/porteus

Alternatively, if you indeed want to be specific about the partition holding your/porteus folder, use a human-readable LABEL

As for MBR/GPT/(or hybrid as I've just learned from this thread!) partition table, it may indeed matter, there are different testimonies: some including myself claimed MBR only. But recently I installed Porteus on my system HHD shared by Windows and the table there was GPT and my computer still boots Porteus/X.

As for GParted vs. another partitioning tool. Again, try the simplest GUI tool you already have, if it doesn't work, try a CLI tools suggested by the experts: jjr and Ed_P above. Good luck!

[rych]

Another issue I forgot - Windows ignores the GPT when it finds an MBR.
This makes it unable to access hybrid volumes over 2 TiB (created with GParted).

This is quickly becoming so complex... I guess I've been lucky not to run into such problems for many years, but will keep that in mind. Why can't they fix GParted then, do you know? It's the most commonly used partitioning tool and is included with Porteus/X ? Many many years ago I had to combine it with some CLI tools but for a long time it felt like a mature tool? Are you sure it's still broken, and makes a "hybrid table" underneath?!

[rych]

doing things the "stupidly simple" but unsafe way can cause issues

Like everything in life I guess, we wisely make compromises and take risks operating within time-constraints. Otherwise, everything in life has layers of complexity. In the case of booting, a simple recipe thankfully just works. Until it doesn't But that'd be rare.

[jjr]

This is quickly becoming so complex...

I'm sorry for distracting from the solution for OP.

I saw that OP was an embedded programmer, and I felt he might expect/want to the hear "why" behind the FAT partition, but then I have to be thorough about it :p

Why can't they fix GParted then, do you know? It's the most commonly used partitioning tool and is included with Porteus/X ? Many many years ago I had to combine it with some CLI tools but for a long time it felt like a mature tool? Are you sure it's still broken, and makes a "hybrid table" underneath?!

fyi, GParted is just a frontend for CLI parted/libparted.

Someone reported this problem in 2019 and it's still doing it today for me (2024):
https://superuser.com/questions/1423275 ... tfs-partit

It sounds like the hybrid conversion might be triggered by creating an NTFS partition. If that's true, it wouldn't affect OP... (I still trust classic fdisk more.)

Why can't they fix

I've realized that FOSS is heavily understaffed / not enough brain-man-hours to go around. GNOME in my Ubuntu 22 hides the file rename popup for a desktop item *behind* any folders you have open (A mature desktop, 20 years old? lol)

But I'm thankful that Linux (and Porteus) exists. Like you said, everyone is doing their best in time-constraints.

[jjr]

Someone reported this problem in 2019 [...]

edited to clarify that wasn't me

[rych]

jjr, you've intrigued me to check what partition tables I'm actually on. These days I run Porteus from the (Windows) HDD:

Code: Select all

root@porteus:~# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.8
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): ^C

I'm surprised it has any MBR at all in addition to the (main?) GPT, but at least it's not a "hybrid MBR". Although it does carry an NTFS partition.

I keep this installation synced with a Porteus USB stick:

Code: Select all

root@porteus:~# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.8
Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************
Command (? for help): ^C

OK, this one is MBR and no GPT. Also has an NTFS partition.

I hope I can safely ignore these gory details though as long as both HDD and USB, GPT or MBR, boot my Porteus/X just fine on this HDD and on all other computers I plug in the USB these days.

I'd like the OP or anyone to actually prove me wrong: in 2024 you just partition your USB to FAT32+ext4 using whatever GParted and partition table, put /porteus folder on the latter, and boom, it just works -- that's the world I want me and my children to live in

[jjr]

I'm surprised it has any MBR at all in addition to the (main?) GPT, but at least it's not a "hybrid MBR". Although it does carry an NTFS partition.

Yes, all GPT should have a dummy PMBR.

But the following standard, stupid-simple steps in GParted result in a hybrid GPT/MBR, improperly read on Windows (and will be corrupted if you edit it with diskpart).

You can confirm this with Linux fdisk.

1. Open GParted (v1.3.1 = Porteus 5.0, Ubuntu 22)
2. Connect drive (mine /dev/sdc)
3. Create Partition Table > GPT
4. Partition > New > FAT32 > 128 MiB
5. Partition > New > NTFS (fill rest of space)
6. Execute

Run:

Code: Select all

$ sudo fdisk /dev/sdc

I get the following output, with the hybrid warning printed in red text:

Code: Select all

Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

A hybrid GPT was detected. You have to sync the hybrid MBR manually (expert command 'M').

I don't know what your version of GParted is. It's possible they've corrected the behavior very recently, but I doubt it.

boom, it just works -- that's the world I want me and my children to live in

It's certainly not "boom it just works" for everyone. (Depending on usage.)

Linux software age =/= maturity, too often.

People can and do hit Linux's does not work conditions, and I think it's important to be aware of them.

[rych]

the following standard, stupid-simple steps in GParted result in a hybrid GPT/MBR, improperly read on Windows (and will be corrupted if you edit it with diskpart).
You can confirm this with Linux fdisk.
1. Open GParted (v1.3.1 = Porteus 5.0, Ubuntu 22)
2. Connect drive (mine /dev/sdc)
3. Create Partition Table > GPT

Granted, my GPT was made by Windows installation. Indeed, when I use GParted for initial table creation, I tend to choose MBR ("msdos"), because GPT made by GParted used to give me problems booting Porteus USB, and not only me:

In my tests partition tables different from msdos didn't work. I might be wrong though.

However, there are also reports of successful GPT booting, besides my own Windows-originating above, people also used RUFUS for that:

RUFUS will also burn perfectly well for a UEFI-ONLY machine like many of mine are. All you have to do is tell it the partition type is "GPT" in the dropdown, and not the default MBR.

So, perhaps, GParted (still!) produces a problematic GPT unless it's fixed by now. Let's wait for the OP's or another newcomer's report