How to detect current disk on UEFI
-
- Posts: 2
- Joined: Sat Jan 06, 2024 8:01 pm
- Libera.chat IRC: BlueSilly
How to detect current disk on UEFI
I finally can detect all disks connected to the PC, and I want to try and read the Superblock of the Ext2 partition, so 3 questions. 1) How do I figure out which disk is the current disk, say the OS is booted off of a USB, obviously I don't want to be reading off of the main harddisk, so how do I figure out the disk that we're booting from. 2) How do I figure out which partition I want, I'm fairly sure the first partition on the disk will more often than not be the EFI System Partition, but after that how do I know which partition I want, my best guess is to just manually probe every Ext2 partition (if there are more than one) for the kernel. 3) I presume I can read the superblock with blockIo->ReadBlocks() but what do I do if the BlockSize is greater than 2048?
Re: How to detect current disk on UEFI
actions, about which you are asking belong to the kernel, not the loader, Boot Services aren't accessible at that time, your kernel must deal with finding what volume it got loaded from by itself and read from it via OS's mechanisms, basically you must have your storage device(s) HC driver(s) and all the storage stack implemented.
For the loader, its "current" disk, what I call "home volume" is reported via EFI_LOADED_IMAGE protocol's DeviceHandle. You can OpenProtocol() this protocol on your loader image handle, which is passed to your loader entry by fw.
For reading not supported FS in the loader, what you need to do if your OS is installed on such, you handle it via BIOP, and it doesn't matter what BlockSize is, you use that info for doing your FS related work. BlockSize is the real block size, not what ext2 calls block size. What is the problem if it's greater, than 2048?
For finding your OS Boot Volume, you need to enumerate all handles, supporting BIOP, filter out those, which aren't "logical" partitions, and then search for your ext magic on each logical partition in the list. But also, you could store your relative DevicePath, that would tell what partition your OS is installed on (HD(n, GPT/MBR, id, start, size)\YourSystemRoot, 4.1 and 4.4 Type.SubType pair, pretty cool to use it, you would be able to find your OS even if the disk got moved into another port or even interface). Put it in your OS Load (Boot) Option, in Optional Data for example, you could even put there the FS type (as part of your "load descriptor"), so you would be free of probing. This applies for the post installation scenario, of course. For preinstallation/live sessions, you'd be better off using FAT as Boot Volume and use fw provided file access. I do this way and I like it. But if you want a non-FAT FS on the preinstallation/live media, then you must implement FS probing in the loader, using BIOP (EFI_BLOCK_IO_PROTOCOL).
For the loader, its "current" disk, what I call "home volume" is reported via EFI_LOADED_IMAGE protocol's DeviceHandle. You can OpenProtocol() this protocol on your loader image handle, which is passed to your loader entry by fw.
For reading not supported FS in the loader, what you need to do if your OS is installed on such, you handle it via BIOP, and it doesn't matter what BlockSize is, you use that info for doing your FS related work. BlockSize is the real block size, not what ext2 calls block size. What is the problem if it's greater, than 2048?
For finding your OS Boot Volume, you need to enumerate all handles, supporting BIOP, filter out those, which aren't "logical" partitions, and then search for your ext magic on each logical partition in the list. But also, you could store your relative DevicePath, that would tell what partition your OS is installed on (HD(n, GPT/MBR, id, start, size)\YourSystemRoot, 4.1 and 4.4 Type.SubType pair, pretty cool to use it, you would be able to find your OS even if the disk got moved into another port or even interface). Put it in your OS Load (Boot) Option, in Optional Data for example, you could even put there the FS type (as part of your "load descriptor"), so you would be free of probing. This applies for the post installation scenario, of course. For preinstallation/live sessions, you'd be better off using FAT as Boot Volume and use fw provided file access. I do this way and I like it. But if you want a non-FAT FS on the preinstallation/live media, then you must implement FS probing in the loader, using BIOP (EFI_BLOCK_IO_PROTOCOL).
-
- Member
- Posts: 5501
- Joined: Mon Mar 25, 2013 7:01 pm
Re: How to detect current disk on UEFI
Your bootloader's image handle should have an EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL you can parse to find the boot disk.BlueSillyDragon wrote: ↑Fri Oct 04, 2024 11:38 amhow do I figure out the disk that we're booting from.
That's entirely up to you.
Assuming you're talking about inside your bootloader before you've exited boot services, you can use EFI_DISK_IO_PROTOCOL and then the block size doesn't matter. Otherwise, you'll just have to deal with reading bigger blocks. Most disks have 4096-byte blocks.BlueSillyDragon wrote: ↑Fri Oct 04, 2024 11:38 amI presume I can read the superblock with blockIo->ReadBlocks() but what do I do if the BlockSize is greater than 2048?
-
- Posts: 2
- Joined: Sat Jan 06, 2024 8:01 pm
- Libera.chat IRC: BlueSilly
Re: How to detect current disk on UEFI
OK, I see, thanks!