Solved invisible stuff on efi partition

  • Thread starter Thread starter Deleted member 43773
  • Start date Start date
D

Deleted member 43773

Guest
The Story (you may jump directly to Q):
I'm trying to install ubuntu on a memory stick and don't want to have any traces left on my system.
So on my experimenting hardware I made the following thing:
- install FreeBSD on a HD
- copy the files from its efi partition to memory stick A
- install ubuntu to memory stick B
- copied all files from HD's efi partition, which now contains also ubuntu/grub data, to the empty efi partition on stick B (I don't see any sense in why there is an empty efi partion created - 480 MB! ? for what?! Maybe someday there will be 63 OSs be installed with 3D-rendered bootloaders? ?)
- deleted all files on HD's efi
- copied the original files from Stick A to HD's efi

It works so far.
FreeBSD is automatically booted from HD, got rid of this grub-crap. And ubuntu starts from memory stick B.
So far, so good.

BUT if I say PC's BIOS: "F11 - Gimme a list of bootable devices!" theres still is an additional entry "ubuntu"
This also will start FreeBSD bootloader, but I want to get rid off any traces.

So I looked into my HD's efi partion by the usual:
mount -t msdosfs /dev/ada0p1 /mnt
and saw nothing different as if I had installed FreeBSD only.

So I made copy from the first part of the disk with
dd if=/dev/ada0 of=hdd.foobar bs=512 count=number_of_blocks_gpart_showed_for_efi

and with a hexeditor I found "ubuntu" within this file.

So, here my
Question:

Are there files on an efi partion only invisible to FreeBSD because mounted by "msdosfs"?
Can those files be made visible/copied/deletes by mounting the partition with another fs (fat32)?
Or does the efi partition also contains data "low level" not visible as files with any fs?
 
First the "480MB" thing: I think that comes from current Windows stuff. But if one looks at typical alignment, block sizes, and device sizes, it's probably not a big deal. And yes, it is bigger than was MS-DOS3.0 supported as a disk size.
Regardless of the underlying filesystem type, I think "ls -a" really does show "all".
I believe efibootmgr is available on FreeBSD systems if it booted via efi/uefi
 
mer said:
First the "480MB" thing: I think that comes from current Windows stuff.
Click to expand...
Actually, FAT32 has a minimum size that's quite large (don't remember the exact value right now). Normally, implementations will fall back to FAT16 or FAT12 for smaller filesystem sizes.

Unfortunately, the EFI specification mandates FAT32 for the ESP. Although most UEFI firmwares boot just fine from FAT12/FAT16, some won't. Yep, it's idiotic...
 
mer haha. Even my oldest machine has "UEFI", but this is so buggy, it can't boot FreeBSD, so I use CSM there indeed. I think a lot in UEFI makes sense though. This concept with 512 bytes(!) for both partition table and real-mode boot code in classic BIOS is ridiculous. But yes, there are weird things as well (like, NOT mandating compatibility with FAT12/FAT16 ESPs)...
 
  • Like
Reactions: mer
I think my two systems can do either, but I just defaulted BIOS/CSM mode. I do have a laptop running Win 10 that "Doesn't support Windows 11" so in the future I probably have a system to test.
 
Ah. Cool. Thanks Guys. Learned a lot again.

haha. Even my oldest machine has "UEFI", but this is so buggy, it can't boot FreeBSD,
Click to expand...
My machine I used until half a year ago was a AMD Phenom II X 980 Black Edition on an ASUS M4A79T Deluxe with 8GB RAM. (You have to look in historical documents to look that up ? [>13 years old!]) - and still booting and running FreeBSD 13 with X.
But frankly too slow finally.

It's BIOS didn't even know about UEFI. (So did I :confused:)
So, haha to you! ?

...nah, I deal with this efi cr#p (I don't see no actual improvement/sense in it) already for a while. But as you see, still not versed with it.

Thanks again guys.
I'm going to play bit with my machines, after I read the stuff you linked.
 
Profighost said:
I deal with this efi cr#p (I don't see no actual improvement/sense in it)
Click to expand...
Well, BIOS means "Basic Input/Output System" and it is just that: It includes lots of functions callable by software interrupts, like e.g. some Disk I/O that's utterly useless nowadays (from times before 32bit code, LBA, DMA, ... just good enough now to chainload a real bootloader from this tiny thing that has room in the 512 bytes MBR)...

UEFI drops all that stuff and instead introduces things that are useful, like ability to read from a real filesystem (instead some magic position on disk), an environment and API to write and use own EFI modules/drivers/binaries, a real console driver, etc pp.

As I said, there are things that aren't so great... but all in all, it makes a lot of sense.

Of course, if all you want is boot a single OS and the OS devs already solved all the weirdness of classic BIOS boot for you, you won't notice much as a user ;)
 
Zirias said:
Unfortunately, the EFI specification mandates FAT32 for the ESP. Although most UEFI firmwares boot just fine from FAT12/FAT16, some won't. Yep, it's idiotic...
Click to expand...
One of the reasons I'm avoiding UEFI for as long as I can. I had to deal with too many corrupt FAT filesystems in the bad old days.

Zirias said:
mer haha. Even my oldest machine has "UEFI", but this is so buggy, it can't boot FreeBSD, so I use CSM there indeed.
Click to expand...
I have the opposite problem now, sadly. A new motherboard with a CSM so buggy I'm forced to use UEFI.
 
Jose said:
I had to deal with too many corrupt FAT filesystems in the bad old days.
Click to expand...
Well, FAT is extremely simple and has close to no fault tolerance, so it's almost as bad as bootcode written raw on the MBR and some sectors of a boot partition ?

Seriously, I think for holding a boot loader (rarely written to), it's "good enough" ... at least not worse than what classic BIOS did (no filesystem at all). But this minimum size requirement because it has to be FAT32 is stupid.
 
Zirias said:
Well, FAT is extremely simple and has close to no fault tolerance, so it's almost as bad as bootcode written raw on the MBR and some sectors of a boot partition ?
Click to expand...
MBR is super easy to fix, and was even in the bad old days of DOS (fdisk /mbr FTW). Memory is hazy, but I believe there are two copies of the MBR and the easy fix is to overwrite the live one with the backup. A FAT filesystem can become corrupt in arbitrary ways, and good luck recovering it.

Zirias said:
Seriously, I think for holding a boot loader (rarely written to), it's "good enough" ...
Click to expand...
Fair enough, but stuff like this still gives me the heebie-jeebies:
forums.FreeBSD.org

13.1 breaks my encrypted disk setup

[Updated to include results of my newest tests] Prior to version 13.1, I had a working disk setup that I've been using to install FreeBSD. This has changed recently and I can no longer use my custom partitioning layout with encryption due to an error. I am in the process of troubleshooting it...
forums.FreeBSD.org forums.FreeBSD.org
 
  • Like
Reactions: mer
You must log in or register to reply here.
Back
Top