You have more knowledge in just one neuron than most people have in their entire brain. Thank for this wonderfully instructive video. I learned so much.
One little caveat, the GPT partition table is actually stored on the sectors directly after the first instead of sector 0. This allows for UEFI systems to be backwards compatible with MBR. Other than that, excellent video! I’ve been looking everywhere for an explanation as good as this.
UEFI actually makes writing your own OS much easier because it provides a lot of services, doesn't have any size limitations, and it can switch CPU in 32 or 64 bit mode before invoking your code, so you won't have to mess with that yourself.
The explanation of the MBR boot process seems to be wrong - there's a core.img at a well defined location on the disk, this is accessed by the code in the MBR. The MBR is too small (512-sizeof(partitiontable)-2 (magic number)) to understand a linux filesystem and thus can't access /boot/grub.
you are right. Why did grub-install even accept this? Must have been ignored. I was wondering why that was there in the first place, since UEFI install should only put the bootloader into /mnt/boot/efi/
Isnt the GPT partition table the second sector and not the first? @07:45 At least I'm sure that its the case in Windows, where the first sector doesn't really matter, and the second sector is the GPT table that sarts with "EFI PART" Magic string.
You have more knowledge in just one neuron than most people have in their entire brain. Thank for this wonderfully instructive video. I learned so much.
One little caveat, the GPT partition table is actually stored on the sectors directly after the first instead of sector 0. This allows for UEFI systems to be backwards compatible with MBR. Other than that, excellent video! I’ve been looking everywhere for an explanation as good as this.
UEFI actually makes writing your own OS much easier because it provides a lot of services, doesn't have any size limitations, and it can switch CPU in 32 or 64 bit mode before invoking your code, so you won't have to mess with that yourself.
The explanation of the MBR boot process seems to be wrong - there's a core.img at a well defined location on the disk, this is accessed by the code in the MBR. The MBR is too small (512-sizeof(partitiontable)-2 (magic number)) to understand a linux filesystem and thus can't access /boot/grub.
Thank you so much
I love the introduction!
you made a typo 'sev' instead of 'dev', check when you blind-typing...
amount of knowledge this guy have is 🔥🔥. Recommended
no, he doesnt seem that good, when you watch a couple of his vids...
no, he doesnt seem that good, when you watch a couple of his vids...
@@cokeforever could you please name the video.
I am able to understand the concepts
@27:07: '/sev/sda' as part of grub-install. Shouldn't that be '/dev/sda'?
you are right. Why did grub-install even accept this? Must have been ignored. I was wondering why that was there in the first place, since UEFI install should only put the bootloader into /mnt/boot/efi/
what a mindfuck! Glad I found this comment I was scratching my head haha @@writeyourownoperatingsystem
Hi,
Thanks a lot, that was insightful.
Isnt the GPT partition table the second sector and not the first? @07:45
At least I'm sure that its the case in Windows, where the first sector doesn't really matter, and the second sector is the GPT table that sarts with "EFI PART" Magic string.
Yes, this is so UEFI systems can be backwards compatible with MBR.
Cool t-shirt
It all starts with a "Hello, World!"
Awesome, about time I got booted right!