updating a system hardwareside mbr -> gpt
Hi, i have a new computer with ssd (nvme0n1) 1tb and 3tb hdd (hda) old system have had hda 1tb hdb 2tb both hdd's are bootable (hda tumbleweed graphic kde, hdb old tumbleweed only shell, for backup + problem sovling +..) both systems amd main processor amd graphics format of both disks is ext4 both computers are switched to old style bios (uefi switched off) systems use "hardware name" (free translation from german) in fstab (hda1... nvme0n1p1 ...) copied everything to the new system (using dd) now of course the new hda1 is 2tb and have a 1tb unused. because i did not like to have a second partition on it, i have to change to gpt. hdd boot ok ssd boot after changing initramfs, fstab grub commandline and maybe some other small things. now to my question (for ssd (to be more modern) and hdd (because of the 3tb)): 1) what would be the best way to change mbr to gpt -> maybe using gdisk? https://superuser.com/questions/1250895/converting-between-gpt-and-mbr-hard-... https://www.rodsbooks.com/gdisk/mbr2gpt.html -> i do not understand clearly, will it then still be bootable / and 100% correct gpt or is this only a "it will work (with or even unusable for me without booting)" solution? 2) i found in /etc/default/grub_installdevice one line: generic_mbr i guess that this info has to be changed, what must be insert here instead of "generic_mbr" regards, simoN -- www.becherer.de
On 13.06.2022 10:09, Simon Becherer wrote:
Hi,
i have a new computer with ssd (nvme0n1) 1tb and 3tb hdd (hda) old system have had hda 1tb hdb 2tb both hdd's are bootable (hda tumbleweed graphic kde, hdb old tumbleweed only shell, for backup + problem sovling +..) both systems amd main processor amd graphics format of both disks is ext4 both computers are switched to old style bios (uefi switched off) systems use "hardware name" (free translation from german) in fstab (hda1... nvme0n1p1 ...)
copied everything to the new system (using dd)
now of course the new hda1 is 2tb and have a 1tb unused. because i did not like to have a second partition on it, i have to change to gpt.
hdd boot ok ssd boot after changing initramfs, fstab grub commandline and maybe some other small things.
now to my question (for ssd (to be more modern) and hdd (because of the 3tb)):
1) what would be the best way to change mbr to gpt -> maybe using gdisk?
Yes, this will work.
https://superuser.com/questions/1250895/converting-between-gpt-and-mbr-hard-... https://www.rodsbooks.com/gdisk/mbr2gpt.html -> i do not understand clearly, will it then still be bootable / and 100% correct gpt or is this only a "it will work (with or even unusable for me without booting)" solution?
Are you sure your BIOS is capable of booting off NVMe in legacy BIOS mode? This would be rather unusual. GPT/MBR just change partition table, legacy BIOS boots by loading the very first sector and jumping into it. Some BIOS implementations are known to verify that there is bootable MBR partition, in this case you would need to mark protective MBR partition as bootable.
2) i found in /etc/default/grub_installdevice one line: generic_mbr i guess that this info has to be changed, what must be insert here instead of "generic_mbr"
This still works with GPT, in this case YaST writes Syslinux GPTMBR. You will also need to mark suitable GPT partition as bootable. If you want to install grub in GPT MBR, you will need BIOS boot partition. It better be located in the beginning to avoid any possible issues with BIOS access disk size limits.
Hi andrei, Am 13.06.22 um 09:33 schrieb Andrei Borzenkov:
On 13.06.2022 10:09, Simon Becherer wrote:
1) what would be the best way to change mbr to gpt -> maybe using gdisk?
Yes, this will work.
Are you sure your BIOS is capable of booting off NVMe in legacy BIOS mode? This would be rather unusual. well i changed in ueffibios: "csm" to on and control of boot drives: "only legacy"
and it did a boot also from the nvme
GPT/MBR just change partition table, legacy BIOS boots by loading the very first sector and jumping into it. Some BIOS implementations are known to verify that there is bootable MBR partition, in this case you would need to mark protective MBR partition as bootable.
the mbr partition-table was made with opensuse, and i have a directory /boot/grub2 so i did not know how it works in detail. there are only two/three partition ext4 on the drives, "/" and "/home", and on one drive a "linux swap" first partition starts at sector 2048
2) i found in /etc/default/grub_installdevice one line: generic_mbr i guess that this info has to be changed, what must be insert here instead of "generic_mbr"
This still works with GPT, in this case YaST writes Syslinux GPTMBR. You will also need to mark suitable GPT partition as bootable.
i do not understand my mbr ext 4 partition is bootable, so if i change to gpt i will loose this ?
If you want to install grub in GPT MBR, you will need BIOS boot partition. It better be located in the beginning to avoid any possible issues with BIOS access disk size limits.
here i do also not understand. actually i was thinking somewhere in mbr or gpt (the firts 2048 sectors) is the grub part which only says: "read /boot...." but maybe i am wrong, if i think for this, somewhere must be written that it must be read in ext4 style. maybe grub is able to read a lot of different haddrive filesystems. am confused. simoN -- www.becherer.de
On 13.06.2022 11:19, Simon Becherer wrote:
2) i found in /etc/default/grub_installdevice one line: generic_mbr i guess that this info has to be changed, what must be insert here instead of "generic_mbr"
This still works with GPT, in this case YaST writes Syslinux GPTMBR. You will also need to mark suitable GPT partition as bootable.
i do not understand my mbr ext 4 partition is bootable, so if i change to gpt i will loose this ?
If you change to GPT you will not have MBR partitions.
If you want to install grub in GPT MBR, you will need BIOS boot partition. It better be located in the beginning to avoid any possible issues with BIOS access disk size limits.
here i do also not understand. actually i was thinking somewhere in mbr or gpt (the firts 2048 sectors) is the grub part which only says: "read /boot...."
Correct for MBR, wrong for GPT.
but maybe i am wrong, if i think for this, somewhere must be written that it must be read in ext4 style. maybe grub is able to read a lot of different haddrive filesystems. am confused.
simoN
Am 13.06.22 um 11:26 schrieb Andrei Borzenkov:
On 13.06.2022 11:19, Simon Becherer wrote:
2) i found in /etc/default/grub_installdevice one line: generic_mbr i guess that this info has to be changed, what must be insert here instead of "generic_mbr"
This still works with GPT, in this case YaST writes Syslinux GPTMBR. You will also need to mark suitable GPT partition as bootable.
i do not understand my mbr ext 4 partition is bootable, so if i change to gpt i will loose this ?
If you change to GPT you will not have MBR partitions.
ok, sure, then i will have (hopefully) the same partitions, but gpt.
If you want to install grub in GPT MBR, you will need BIOS boot partition. It better be located in the beginning to avoid any possible issues with BIOS access disk size limits.
here i do also not understand. actually i was thinking somewhere in mbr or gpt (the firts 2048 sectors) is the grub part which only says: "read /boot...."
Correct for MBR, wrong for GPT.
sorry still very unclear in my mind. so its not possible to boot from gpt-ext4 partition without having an additional uefi boot partition? simoN -- www.becherer.de
On 13.06.2022 12:43, Simon Becherer wrote:
If you want to install grub in GPT MBR, you will need BIOS boot partition. It better be located in the beginning to avoid any possible issues with BIOS access disk size limits.
here i do also not understand. actually i was thinking somewhere in mbr or gpt (the firts 2048 sectors) is the grub part which only says: "read /boot...."
Correct for MBR, wrong for GPT.
sorry still very unclear in my mind. so its not possible to boot from gpt-ext4 partition without having an additional uefi boot partition?
It is possible. And I said nothing about UEFI boot partition which is called ESP (EFI System Partition). BIOS boot partition is used to reserve space for bootloader when using legacy BIOS boot.
Am 13.06.22 um 14:09 schrieb Andrei Borzenkov:
On 13.06.2022 12:43, Simon Becherer wrote:
If you want to install grub in GPT MBR, you will need BIOS boot partition. It better be located in the beginning to avoid any possible issues with BIOS access disk size limits.
here i do also not understand. actually i was thinking somewhere in mbr or gpt (the firts 2048 sectors) is the grub part which only says: "read /boot...."
Correct for MBR, wrong for GPT.
sorry still very unclear in my mind. so its not possible to boot from gpt-ext4 partition without having an additional uefi boot partition?
It is possible.
And I said nothing about UEFI boot partition which is called ESP (EFI System Partition). BIOS boot partition is used to reserve space for bootloader when using legacy BIOS boot.
Correct for MBR, wrong for GPT. could you please explain this for me?
It is possible.
i understand: in mbr there is a grub part somewhere in the first 2048 sectors who say -> load /boot/.... in gpt in the first 2048 sectors this is not the case. so if i convert a mbr to gpt then it will fail to boot ? but you say later: this reverted (inside my brain) your statement. simoN -- www.becherer.de
Le 13/06/2022 à 15:54, Simon Becherer a écrit :
so if i convert a mbr to gpt then it will fail to boot ? but you say later:
openSUSE can boot uefi or bios with the very same install, provided you have the good GRUB, that is GRUB for BIOS and GRUB_EFI for uefi. Whatever partitioning system you use (GPT or msdos don't matter). Don't ask me what GRUB do, it's magic for me :-)) jdd -- http://dodin.org http://valeriedodin.com
Am 13.06.22 um 17:38 schrieb jdd@dodin.org:
Le 13/06/2022 à 15:54, Simon Becherer a écrit :
so if i convert a mbr to gpt then it will fail to boot ? but you say later:
openSUSE can boot uefi or bios with the very same install, provided you have the good GRUB, that is GRUB for BIOS and GRUB_EFI for uefi. Whatever partitioning system you use (GPT or msdos don't matter). Don't ask me what GRUB do, it's magic for me :-))
jdd
;-)) ok then i will try to convert with "gdisk" and hope for the magic-boot-moment. the question is open, could somebody take a look inside: /etc/default/grub_installdevice what is written there when ist a gpt and not a mbr inside my is: generic_mbr or the info would be nice inside which grub2-.... man file i will find infos about it. there is fore sure a nice comandline to find it fast. grub2-bios-setup grub2-fstest grub2-macbless grub2-mkimage grub2-mkrelpath grub2-ofpathname grub2-script-check grub2-editenv grub2-glue-efi grub2-menulst2cfg grub2-mklayout grub2-mkrescue grub2-probe grub2-set-default grub2-emu grub2-install grub2-mkconfig grub2-mknetdir grub2-mkstandalone grub2-reboot grub2-sparc64-setup grub2-file grub2-kbdcomp grub2-mkfont grub2-mkpasswd-pbkdf2 grub2-mount grub2-render-label grub2-syslinux2cfg simoN -- www.becherer.de
On 13.06.2022 16:54, Simon Becherer wrote:
Am 13.06.22 um 14:09 schrieb Andrei Borzenkov:
On 13.06.2022 12:43, Simon Becherer wrote:
If you want to install grub in GPT MBR, you will need BIOS boot partition. It better be located in the beginning to avoid any possible issues with BIOS access disk size limits.
here i do also not understand. actually i was thinking somewhere in mbr or gpt (the firts 2048 sectors) is the grub part which only says: "read /boot...."
Correct for MBR, wrong for GPT.
sorry still very unclear in my mind. so its not possible to boot from gpt-ext4 partition without having an additional uefi boot partition?
It is possible.
And I said nothing about UEFI boot partition which is called ESP (EFI System Partition). BIOS boot partition is used to reserve space for bootloader when using legacy BIOS boot.
Correct for MBR, wrong for GPT. could you please explain this for me?
i understand: in mbr there is a grub part somewhere in the first 2048 sectors who say -> load /boot/.... in gpt in the first 2048 sectors this is not the case.
There never was any formal specification for MBR, de-facto standard set by Microsoft fdisk was always to have some unused space before the first partition. This was traditionally used to store bootloader. GPT does have formal specification which does not define any unused space. To make sure there is space to install bootloader, grub2 is using partition with specific type (BIOS boot) to store bootloader. This is relevant only if you install grub2 in MBR (iow on the whole disk). If you install grub2 in PBR (i.e. in partition) bootloader goes somewhere inside of this partition and neither post MBR gap nor reserved partition is needed.
so if i convert a mbr to gpt then it will fail to boot ?
If you convert MBR into GPT in place, your system will likely fail to boot because grub2 first stage code will not include GPT support and will not find /boot/grub2. You need to reinstall grub2 to build the correct first stage code and if you want to install it in MBR you need BIOS grub partition in this case.
but you say later:
It is possible. this reverted (inside my brain) your statement.
simoN
Am 13.06.22 um 18:22 schrieb Andrei Borzenkov:
There never was any formal specification for MBR, de-facto standard set by Microsoft fdisk was always to have some unused space before the first partition. This was traditionally used to store bootloader.
GPT does have formal specification which does not define any unused space. To make sure there is space to install bootloader, grub2 is using partition with specific type (BIOS boot) to store bootloader.
This is relevant only if you install grub2 in MBR (iow on the whole disk). If you install grub2 in PBR (i.e. in partition) bootloader goes somewhere inside of this partition and neither post MBR gap nor reserved partition is needed.
so if i convert a mbr to gpt then it will fail to boot ?
If you convert MBR into GPT in place, your system will likely fail to boot because grub2 first stage code will not include GPT support and will not find /boot/grub2. You need to reinstall grub2 to build the correct first stage code and if you want to install it in MBR you need BIOS grub partition in this case.
Ah, this brings some light ! did you know the code to reinstall grub2 so that it load from /boot/grub2 simoN -- www.becherer.de
On 13.06.2022 19:41, Simon Becherer wrote:
Am 13.06.22 um 18:22 schrieb Andrei Borzenkov:
There never was any formal specification for MBR, de-facto standard set by Microsoft fdisk was always to have some unused space before the first partition. This was traditionally used to store bootloader.
GPT does have formal specification which does not define any unused space. To make sure there is space to install bootloader, grub2 is using partition with specific type (BIOS boot) to store bootloader.
This is relevant only if you install grub2 in MBR (iow on the whole disk). If you install grub2 in PBR (i.e. in partition) bootloader goes somewhere inside of this partition and neither post MBR gap nor reserved partition is needed.
so if i convert a mbr to gpt then it will fail to boot ?
If you convert MBR into GPT in place, your system will likely fail to boot because grub2 first stage code will not include GPT support and will not find /boot/grub2. You need to reinstall grub2 to build the correct first stage code and if you want to install it in MBR you need BIOS grub partition in this case.
Ah, this brings some light !
did you know the code to reinstall grub2 so that it load from /boot/grub2
Use YaST to configure bootloader and select whatever device you want to install bootloader on.
Am 13.06.22 um 18:45 schrieb Andrei Borzenkov:
On 13.06.2022 19:41, Simon Becherer wrote:
Am 13.06.22 um 18:22 schrieb Andrei Borzenkov:
There never was any formal specification for MBR, de-facto standard set by Microsoft fdisk was always to have some unused space before the first partition. This was traditionally used to store bootloader.
GPT does have formal specification which does not define any unused space. To make sure there is space to install bootloader, grub2 is using partition with specific type (BIOS boot) to store bootloader.
This is relevant only if you install grub2 in MBR (iow on the whole disk). If you install grub2 in PBR (i.e. in partition) bootloader goes somewhere inside of this partition and neither post MBR gap nor reserved partition is needed.
so if i convert a mbr to gpt then it will fail to boot ?
If you convert MBR into GPT in place, your system will likely fail to boot because grub2 first stage code will not include GPT support and will not find /boot/grub2. You need to reinstall grub2 to build the correct first stage code and if you want to install it in MBR you need BIOS grub partition in this case.
Ah, this brings some light !
did you know the code to reinstall grub2 so that it load from /boot/grub2
Use YaST to configure bootloader and select whatever device you want to install bootloader on.
:-)) that's easy thanks, simoN -- www.becherer.de
On 2022-06-13 19:01, Simon Becherer wrote:
Am 13.06.22 um 18:45 schrieb Andrei Borzenkov:
...
did you know the code to reinstall grub2 so that it load from /boot/grub2
Use YaST to configure bootloader and select whatever device you want to install bootloader on.
:-)) that's easy
thanks,
Trick: To make sure yast writes everything, change the timeout one second up or down. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 13.06.22 15:54, Simon Becherer wrote:
i understand: in mbr there is a grub part somewhere in the first 2048 sectors who say -> load/boot/.... in gpt in the first 2048 sectors this is not the case.
Not exactly When booting in legacy/CSM mode the BIOS loads the first 446 bytes from first sector of boot disk (= MBR, GPT provides a fake MBR) , checks if there is A5A5 magic number in the last bytes of MBR and then starts this as boot code. When grub is installed in MBR this code loads and starts the second stage of grub. Which is located on another position on the disk. With MBR partition scheme that code can be hidden in unused sectors of the disk. With GPT there are no unused sectors. So you will have to provide a BIOS boot partition for that code When booting in UEFI mode the UEFI starts an EFI program , which name/path is stored in UEFIs NVRAM from the ESP as bootloader. When grub is installed , this should be either shim.efi ( with secure boot) or the efi incarnation of grub. Then there is the restriction that BIOS ( and CSM ) usually doesn't support NVME protocol but only SATA protocol. So you can't boot a NVME disk with CSM unless the rare case that the nvme disk provides an BIOS extension PROM with NVME driver. And there is the Windows only restriction that the Windows bootloader only supports either legacy boot with MBR partition scheme or UEFI boot with GPT scheme
Hi markus, Am 13.06.22 um 19:06 schrieb Markus Koßmann:
On 13.06.22 15:54, Simon Becherer wrote:
i understand: in mbr there is a grub part somewhere in the first 2048 sectors who say -> load/boot/.... in gpt in the first 2048 sectors this is not the case.
Not exactly
When booting in legacy/CSM mode the BIOS loads the first 446 bytes from first sector of boot disk (= MBR, GPT provides a fake MBR) , checks if there is A5A5 magic number in the last bytes of MBR and then starts this as boot code. When grub is installed in MBR this code loads and starts the second stage of grub. Which is located on another position on the disk. With MBR partition scheme that code can be hidden in unused sectors of the disk. With GPT there are no unused sectors. So you will have to provide a BIOS boot partition for that code
"will have" -> must i? or is "/boot/grub2" also ok?
When booting in UEFI mode the UEFI starts an EFI program , which name/path is stored in UEFIs NVRAM from the ESP as bootloader. When grub is installed , this should be either shim.efi ( with secure boot) or the efi incarnation of grub.
Then there is the restriction that BIOS ( and CSM ) usually doesn't support NVME protocol but only SATA protocol.
So you can't boot a NVME disk with CSM unless the rare case that the nvme disk provides an BIOS extension PROM with NVME driver.
mh, not so rare, my (older) asrock "m4a87td" motherboards boot fine with csm and mbr at nvme and the new board is a msi (number not here, if interrested i could provide) did also boot with csm from nvme mbr
And there is the Windows only restriction that the Windows bootloader only supports either legacy boot with MBR partition scheme or UEFI boot with GPT scheme
ok, will never boot windows on my computers ;-) simoN -- www.becherer.de
On 2022-06-13 20:06, Simon Becherer wrote:
Hi markus,
Am 13.06.22 um 19:06 schrieb Markus Koßmann:
On 13.06.22 15:54, Simon Becherer wrote:
i understand: in mbr there is a grub part somewhere in the first 2048 sectors who say -> load/boot/.... in gpt in the first 2048 sectors this is not the case.
Not exactly
When booting in legacy/CSM mode the BIOS loads the first 446 bytes from first sector of boot disk (= MBR, GPT provides a fake MBR) , checks if there is A5A5 magic number in the last bytes of MBR and then starts this as boot code. When grub is installed in MBR this code loads and starts the second stage of grub. Which is located on another position on the disk. With MBR partition scheme that code can be hidden in unused sectors of the disk. With GPT there are no unused sectors. So you will have to provide a BIOS boot partition for that code
"will have" -> must i? or is "/boot/grub2" also ok?
_Must_ It is a special dedicated raw partition, with dedicated type in GPT tables. At least GRUB MBR code can read it, using BIOS "interrupts". -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 13.06.2022 20:06, Markus Koßmann wrote:
On 13.06.22 15:54, Simon Becherer wrote:
i understand: in mbr there is a grub part somewhere in the first 2048 sectors who say -> load/boot/.... in gpt in the first 2048 sectors this is not the case.
Not exactly
When booting in legacy/CSM mode the BIOS loads the first 446 bytes from first sector of boot disk (= MBR, GPT provides a fake MBR) , checks if there is A5A5 magic number in the last bytes of MBR and then starts this
MBR is 512 bytes. If BIOS loads just 446 bytes, how can it check last bytes 510-511? BIOS loads the first disk sector which is 512 bytes and jumps to the first byte of it. What size code has is not known to BIOS.
as boot code. When grub is installed in MBR this code loads and starts the second stage of grub. Which is located on another position on the disk.
Not quite. Code in MBR (which corresponds to stage1 of GRUB legacy) loads core.img (which corresponds to stage1.5 of GRUB legacy) - both core.img and stage1.5 know how to access the main grub code. In case of GRUB legacy it was stage2, in case of grub2 it is grub2 modules. core.img may theoretically be located anywhere on disk, MBR/PBR code is using absolute disk location to load it. core.img includes drivers to access disk, partition table and filesystem where /boot/grub2 is located. core.img loads and starts normal.mod grub2 module which is responsible for parsing and executing grub.cfg. normal.mod will load other grub2 modules as needed.
With MBR partition scheme that code can be hidden in unused sectors of the disk. With GPT there are no unused sectors. So you will have to provide a BIOS boot partition for that code
"That code" in this case refers to core.img aka stage1.5. stage1 is mentioned 446 bytes in either MBR or PBR.
When booting in UEFI mode the UEFI starts an EFI program , which name/path is stored in UEFIs NVRAM from the ESP as bootloader. When grub is installed , this should be either shim.efi ( with secure boot) or the efi incarnation of grub.
Then there is the restriction that BIOS ( and CSM ) usually doesn't support NVME protocol but only SATA protocol.
So you can't boot a NVME disk with CSM unless the rare case that the nvme disk provides an BIOS extension PROM with NVME driver.
And there is the Windows only restriction that the Windows bootloader only supports either legacy boot with MBR partition scheme or UEFI boot with GPT scheme
Am 13.06.22 um 20:49 schrieb Andrei Borzenkov:
On 13.06.2022 20:06, Markus Koßmann wrote:
On 13.06.22 15:54, Simon Becherer wrote:
i understand: in mbr there is a grub part somewhere in the first 2048 sectors who say -> load/boot/.... in gpt in the first 2048 sectors this is not the case.
Not exactly
When booting in legacy/CSM mode the BIOS loads the first 446 bytes from first sector of boot disk (= MBR, GPT provides a fake MBR) , checks if there is A5A5 magic number in the last bytes of MBR and then starts this
MBR is 512 bytes. If BIOS loads just 446 bytes, how can it check last bytes 510-511?
BIOS loads the first disk sector which is 512 bytes and jumps to the first byte of it. What size code has is not known to BIOS.
as boot code. When grub is installed in MBR this code loads and starts the second stage of grub. Which is located on another position on the disk.
Not quite. Code in MBR (which corresponds to stage1 of GRUB legacy) loads core.img (which corresponds to stage1.5 of GRUB legacy) - both core.img and stage1.5 know how to access the main grub code. In case of GRUB legacy it was stage2, in case of grub2 it is grub2 modules.
core.img may theoretically be located anywhere on disk, MBR/PBR code is using absolute disk location to load it. core.img includes drivers to access disk, partition table and filesystem where /boot/grub2 is located. core.img loads and starts normal.mod grub2 module which is responsible for parsing and executing grub.cfg. normal.mod will load other grub2 modules as needed.
With MBR partition scheme that code can be hidden in unused sectors of the disk. With GPT there are no unused sectors. So you will have to provide a BIOS boot partition for that code
"That code" in this case refers to core.img aka stage1.5. stage1 is mentioned 446 bytes in either MBR or PBR.
ok, i may have understand if gpt i must have a pbr ?partition? where "core.img" is inside. i checked at the moment "gparted" (only reduce and then make new partiton (without writing)) to check the filsystem dialog. but i did not find a filesystem called "pbr" (even if pbr will not be a real filesystem partition) so if i make space by reducing my existing partitions, how do i tell the system where to put the pbr partition? simoN
When booting in UEFI mode the UEFI starts an EFI program , which name/path is stored in UEFIs NVRAM from the ESP as bootloader. When grub is installed , this should be either shim.efi ( with secure boot) or the efi incarnation of grub.
Then there is the restriction that BIOS ( and CSM ) usually doesn't support NVME protocol but only SATA protocol.
So you can't boot a NVME disk with CSM unless the rare case that the nvme disk provides an BIOS extension PROM with NVME driver.
And there is the Windows only restriction that the Windows bootloader only supports either legacy boot with MBR partition scheme or UEFI boot with GPT scheme
-- www.becherer.de
On 2022-06-13 21:48, Simon Becherer wrote:
Am 13.06.22 um 20:49 schrieb Andrei Borzenkov:
On 13.06.2022 20:06, Markus Koßmann wrote:
On 13.06.22 15:54, Simon Becherer wrote:
...
With MBR partition scheme that code can be hidden in unused sectors of the disk. With GPT there are no unused sectors. So you will have to provide a BIOS boot partition for that code
"That code" in this case refers to core.img aka stage1.5. stage1 is mentioned 446 bytes in either MBR or PBR.
ok, i may have understand if gpt i must have a pbr ?partition? where "core.img" is inside. i checked at the moment "gparted" (only reduce and then make new partiton (without writing)) to check the filsystem dialog. but i did not find a filesystem called "pbr" (even if pbr will not be a real filesystem partition)
so if i make space by reducing my existing partitions, how do i tell the system where to put the pbr partition?
AFAIK YaST will do it, but the proper partition has to exist. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 13.06.2022 22:48, Simon Becherer wrote:
ok, i may have understand if gpt i must have a pbr ?partition? where "core.img" is inside.
PBR == Partition Boot Record
i checked at the moment "gparted" (only reduce and then make new partiton (without writing)) to check the filsystem dialog. but i did not find a filesystem called "pbr" (even if pbr will not be a real filesystem partition)
As you are apparently banned by Google: https://en.wikipedia.org/wiki/BIOS_boot_partition
so if i make space by reducing my existing partitions, how do i tell the system where to put the pbr partition?
simoN
When booting in UEFI mode the UEFI starts an EFI program , which name/path is stored in UEFIs NVRAM from the ESP as bootloader. When grub is installed , this should be either shim.efi ( with secure boot) or the efi incarnation of grub.
Then there is the restriction that BIOS ( and CSM ) usually doesn't support NVME protocol but only SATA protocol.
So you can't boot a NVME disk with CSM unless the rare case that the nvme disk provides an BIOS extension PROM with NVME driver.
And there is the Windows only restriction that the Windows bootloader only supports either legacy boot with MBR partition scheme or UEFI boot with GPT scheme
Am 14.06.22 um 06:11 schrieb Andrei Borzenkov:
On 13.06.2022 22:48, Simon Becherer wrote:
ok, i may have understand if gpt i must have a pbr ?partition? where "core.img" is inside.
PBR == Partition Boot Record
i checked at the moment "gparted" (only reduce and then make new partiton (without writing)) to check the filsystem dialog. but i did not find a filesystem called "pbr" (even if pbr will not be a real filesystem partition)
As you are apparently banned by Google:
hi andrei, no, i am not banned by google. ;-)) but i do not like it, but i use it. google is evil. take a look how much pages have links to google, nearly every page today (www.becherer.de not) i was already at this wikipedia page and there is written: "The following utilities are known to support BIOS boot partitions: ... .... gparted" and here my question was starting: how to make such "BIOS_boot_partition" ? because i was not able to find how to do with gparted. (carlos has written grub will do, but how to tell them the size, the position....) ... i am a little bit old style, i like to know what tools do an also why, of course nowdays its impossible to understand all things. and the additional question: layout at the moment is: first partition starts at: sector 2048 sector size is 512 would this big enough to use gpt and for the "BIOS_boot_partition" ? as i have read somewhere in addition i have to make 33sectors at end of disk free for second copy of gpt so "i guess" first copy of gpt will be also 33 sectors, are 2015 left for the "bios_boot_partition" maybe i get to old to understand all this "new" (its a point of view what is "new") stuff. bios+mbr was in my view as user much more easy. - not that i have understand all there, but with dos fdisk (and later with gparted) it was easy to create, check etc.... but to do not stand still this is my first approach to install gpt at really fast computer who will maybe used a long looooong time. simoN -- www.becherer.de
On 2022-06-14 08:56, Simon Becherer wrote:
Am 14.06.22 um 06:11 schrieb Andrei Borzenkov:
hi andrei, no, i am not banned by google. ;-)) but i do not like it, but i use it. google is evil. take a look how much pages have links to google, nearly every page today (www.becherer.de not)
i was already at this wikipedia page and there is written:
"The following utilities are known to support BIOS boot partitions: ... .... gparted"
and here my question was starting: how to make such "BIOS_boot_partition" ? because i was not able to find how to do with gparted. (carlos has written grub will do, but how to tell them the size, the position....) ... i am a little bit old style, i like to know what tools do an also why, of course nowdays its impossible to understand all things.
and the additional question: layout at the moment is: first partition starts at: sector 2048 sector size is 512 would this big enough to use gpt and for the "BIOS_boot_partition" ? as i have read somewhere in addition i have to make 33sectors at end of disk free for second copy of gpt so "i guess" first copy of gpt will be also 33 sectors, are 2015 left for the "bios_boot_partition"
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors Disk model: Samsung SSD 850 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: DD259BAE-154F-49DC-83F9-EA43B4A27EEE Device Start End Sectors Size Type /dev/sda1 2048 50333695 50331648 24G Linux swap /dev/sda2 50333696 50364415 30720 15M BIOS boot <====== /dev/sda3 50364416 81819647 31455232 15G Linux filesystem /dev/sda4 81819648 291534847 209715200 100G Linux filesystem /dev/sda5 291534848 343963647 52428800 25G Linux filesystem Elesar:~ # https://paste.opensuse.org/73700039
maybe i get to old to understand all this "new" (its a point of view what is "new") stuff. bios+mbr was in my view as user much more easy. - not that i have understand all there, but with dos fdisk (and later with gparted) it was easy to create, check etc.... but to do not stand still this is my first approach to install gpt at really fast computer who will maybe used a long looooong time.
GPT is easy. No "tricks" like logical partitions. :-D -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Am 14.06.22 um 17:38 schrieb Carlos E. R.:
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors Disk model: Samsung SSD 850 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: DD259BAE-154F-49DC-83F9-EA43B4A27EEE
Device Start End Sectors Size Type /dev/sda1 2048 50333695 50331648 24G Linux swap /dev/sda2 50333696 50364415 30720 15M BIOS boot <====== /dev/sda3 50364416 81819647 31455232 15G Linux filesystem /dev/sda4 81819648 291534847 209715200 100G Linux filesystem /dev/sda5 291534848 343963647 52428800 25G Linux filesystem Elesar:~ #
https://paste.opensuse.org/73700039
GPT is easy. No "tricks" like logical partitions. :-D
Hi carlos, thanks, could you please mail the content of: /etc/default/grub_installdevice i will try to convert (hopefully) over the weekend an will then write here the result. -- www.becherer.de
On 2022-06-14 18:26, Simon Becherer wrote:
Am 14.06.22 um 17:38 schrieb Carlos E. R.:
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors Disk model: Samsung SSD 850 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: DD259BAE-154F-49DC-83F9-EA43B4A27EEE
Device Start End Sectors Size Type /dev/sda1 2048 50333695 50331648 24G Linux swap /dev/sda2 50333696 50364415 30720 15M BIOS boot <====== /dev/sda3 50364416 81819647 31455232 15G Linux filesystem /dev/sda4 81819648 291534847 209715200 100G Linux filesystem /dev/sda5 291534848 343963647 52428800 25G Linux filesystem Elesar:~ #
https://paste.opensuse.org/73700039
GPT is easy. No "tricks" like logical partitions. :-D
Hi carlos, thanks, could you please mail the content of:
/etc/default/grub_installdevice
Elesar:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NB0J535704L Elesar:~ #
i will try to convert (hopefully) over the weekend an will then write here the result.
:-) -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Am 14.06.22 um 18:31 schrieb Carlos E. R.:
On 2022-06-14 18:26, Simon Becherer wrote:
Am 14.06.22 um 17:38 schrieb Carlos E. R.:
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors Disk model: Samsung SSD 850 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: DD259BAE-154F-49DC-83F9-EA43B4A27EEE
Device Start End Sectors Size Type /dev/sda1 2048 50333695 50331648 24G Linux swap /dev/sda2 50333696 50364415 30720 15M BIOS boot <====== /dev/sda3 50364416 81819647 31455232 15G Linux filesystem /dev/sda4 81819648 291534847 209715200 100G Linux filesystem /dev/sda5 291534848 343963647 52428800 25G Linux filesystem Elesar:~ #
https://paste.opensuse.org/73700039
GPT is easy. No "tricks" like logical partitions. :-D
Hi carlos, thanks, could you please mail the content of:
/etc/default/grub_installdevice
Elesar:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NB0J535704L Elesar:~ # interresting, mine looks like:
cat /etc/default/grub_installdevice /dev/nvme0n1p1 activate generic_mbr maybe i try to delete the second and third line simoN
i will try to convert (hopefully) over the weekend an will then write here the result.
:-)
-- www.becherer.de
First of all thanks for all people here who gave me input to improve my knowledge for partitioning harddrives. ======================= what you read here: how to convert a msdos partition table (boot with grub2 and a opensuse tumbleweed on it) to a gpt table also booting, WITHOUT data loss in a modern pc. (no ueffi used) ------------------------ why? background: old sda from old system was copied 1:1 to a new system with nvme. using dd ------------------------ we will end up with a gpd disk and a grub-bios-boot-partition from sector 34 to sector 2047. (if your disk is mbr and aligned, this area should be always free) ======================= what i have used to boot system not from installed harddrive: https://www.system-rescue.org/ (you could do all this only if your drive is NOT mounted) ======================= tools involved (all on system-rescue-cd): parted gparted gdisk (so you need a linux system with graphic desktop) ======================= info: all here is written by hand and not copy/paste, so there could be some typos in. ======================= WARNING: you should know what you do and not blind copy some commands from here, you could destroy your system completely !!!!!!! !!!! for sure make a backup before !!!!! ======================= boot the system from system-rescue-cd (9.03) setkmap de-latin1 # for german keyboard (if you like it ;-)) startx ------------------ take a look about your partitions: gparted: partition table: msdos heads 255 sector/track 2 cylinders 3830411 total sectors 1953525168 sector size 512 nvme0n1p1 first sector ext4 boot / 60GiB 2048 ->125831167 nvme0n1p2 first secror ext4 /home 869.51GiB 125831168 -> 1949331455 nvme0n1p3 first secror linux swap 2GiB 1949331456 -> 1953525167 the nvme0n1p3 "swap" will be deleted because in future swap will be a "swapfile" on this system (docs to do this are not included here) ------------------- check alignment: parted /dev/nvme0n1 (parted) align-check opt 1 (parted) align-check opt 2 (parted) quit (could be also calculated for most drives by hand start of partition should be dividable by 2048) ------------------- delete and resize partitions: gparted: delete swap resize nvme0n1p2 to the end of disk, but leave one mb free (always align to MiB) (gparted shows after pressing "resize-move" 1.71 MiB free) apply all operations (its important to have some free space at end of disk for second gpt partition table i guess must be minimum 33 sectors) (for msdos mbr not needed) ------------------- only for information (partition table is still msdos, so parted shows free from 2 to 2047): parted /dev/nvme0n1 (parted) unit s (parted) print free (parted) quit ------------------- now change mbr to gpt: gdisk /dev/nvme0n1 (command) w (do you want to proceed) y ------------------- now make a small grub boot partition from sector 34 to 2047: (34 is first free if we would use gpt and we see, boot flag is now missing at partition 1) parted /dev/nvme0n1 (parted) unit s (parted) print free (parted) mkpart grub 34s 2047s (warning ...not aligned..) ignore (parted) print free (parted) quit the warning "not aligned" could be easily ignored this partition will be read once at boot so there should be "no" performance impact. ------------------- because now partiton number 3 is now the small grub partition at start, we change the numbering of partitions (i do not like to have 3 before 1): gdisk /dev/nvme0n1 (parted) s (parted) w (parted do you want to proceed) y (parted) quit ------------------- because kernel may have some wrong information's about this nvme now make a new-start of systemrescuecd (not sure if needed): ------------------- setkmap de-latin1 startx gparted set flag for new first partition (nvme0n1p1) "bios_grub" set flag for the old boot partition (nvme0n1p2) "legacy_boot" leave graphical desktop ------------- (the last block i have not done with system-rescue-cd, but with a second tumbleweed system, connected as sda, but i think it should work also with system-rescue-cd) ------------- chroot to the system: mkdir /mnt/nvme0n1p2 mount /dev/nvme0n1p2 /mnt/nvme0n1p2 mount --bind /dev /mnt/nvme0n1p2/dev mount --bind /proc /mnt/nvme0n1p2/proc mount --bind /sys /mnt/nvme0n1p2/sys chroot /mnt/nvme0n1p2 fix your /etc/fstab file from old partition numbers to the new one. grub2-install /dev/nvme0n1 (make sure you have nvme0n1 NOT nvme0n1pX !!) change /etc/default/grub_installdevice in my system change first line to: /dev/nvme0n1p2 and delete line 2: (activate) and line 3: (generic_mbr) so only one line is left (maybe this is not needed:) grub2-mkconfig -o /boot/grub2/grub.cfg (and here should be a newer command, for dracut? i do not know the command if somebody know it would be nice to tell me. - at the moment this will work fine:) mkinitrd exit shutdown -r now system boot with new gpt layout. =================================== simoN -- www.becherer.de
On 18.06.2022 16:57, Simon Becherer wrote: ...
grub2-install /dev/nvme0n1 (make sure you have nvme0n1 NOT nvme0n1pX !!)
change /etc/default/grub_installdevice in my system change first line to: /dev/nvme0n1p2 and delete line 2: (activate) and line 3: (generic_mbr) so only one line is left
That's wrong. First you install grub on the whole disk and then you tell openSUSE tools that grub is installed on partition. The end result will be - during grub update new version will be installed in partition /dev/nvme0n1p2 *and* in /boot/grub2 while system will continue to boot using grub core.img already present in MBR/BIOS grub partition. This may appear to work for some time until new version that has incompatible changes will be installed. Then new modules in /boot/grub2 will no more match core.img in BIOS grub partition and in the best case you will have error on boot, in the worst case - hard to debug problems or hung system. This was known to happen in the past, it is not something rare.
Am 18.06.22 um 16:13 schrieb Andrei Borzenkov:
On 18.06.2022 16:57, Simon Becherer wrote: ...
grub2-install /dev/nvme0n1 (make sure you have nvme0n1 NOT nvme0n1pX !!)
change /etc/default/grub_installdevice in my system change first line to: /dev/nvme0n1p2 and delete line 2: (activate) and line 3: (generic_mbr) so only one line is left
That's wrong. First you install grub on the whole disk and then you tell openSUSE tools that grub is installed on partition. The end result will be - during grub update new version will be installed in partition /dev/nvme0n1p2 *and* in /boot/grub2 while system will continue to boot using grub core.img already present in MBR/BIOS grub partition. This may appear to work for some time until new version that has incompatible changes will be installed. Then new modules in /boot/grub2 will no more match core.img in BIOS grub partition and in the best case you will have error on boot, in the worst case - hard to debug problems or hung system. This was known to happen in the past, it is not something rare.
Hi andrey, ok, then i have something misunderstand. i like to have grub2 inside /boot/grub (as it was with mbr) i have understand: 1 frist part of boot is inside the first 34 sectors of disk (at least a pointer to the bios-boot-partition) 2 part of grub (in this case some code who is able to read ext4) is now inside that bios-boot-partition (core.img). 3 part of grub is inside /boot/grub2 /the menue and all the other things needed) that is what i like to have. and what i was thinking i have now installed. if it is not like this, where is my mistake? simoN -- www.becherer.de/AGB
On 2022-06-18 16:33, Simon Becherer wrote:
Am 18.06.22 um 16:13 schrieb Andrei Borzenkov:
On 18.06.2022 16:57, Simon Becherer wrote: ...
grub2-install /dev/nvme0n1 (make sure you have nvme0n1 NOT nvme0n1pX !!)
change /etc/default/grub_installdevice in my system change first line to: /dev/nvme0n1p2 and delete line 2: (activate) and line 3: (generic_mbr) so only one line is left
That's wrong. First you install grub on the whole disk and then you tell openSUSE tools that grub is installed on partition. The end result will be - during grub update new version will be installed in partition /dev/nvme0n1p2 *and* in /boot/grub2 while system will continue to boot using grub core.img already present in MBR/BIOS grub partition. This may appear to work for some time until new version that has incompatible changes will be installed. Then new modules in /boot/grub2 will no more match core.img in BIOS grub partition and in the best case you will have error on boot, in the worst case - hard to debug problems or hung system. This was known to happen in the past, it is not something rare.
Hi andrey,
ok, then i have something misunderstand.
i like to have grub2 inside /boot/grub (as it was with mbr)
i have understand: 1 frist part of boot is inside the first 34 sectors of disk (at least a pointer to the bios-boot-partition)
I understand it is in the first sector, just one sector, which is called the MBR. In case of GPT partitioning table, it is called the protective MBR.
2 part of grub (in this case some code who is able to read ext4) is now inside that bios-boot-partition (core.img). 3 part of grub is inside /boot/grub2 /the menue and all the other things needed)
that is what i like to have. and what i was thinking i have now installed.
if it is not like this, where is my mistake?
/etc/default/grub_installdevice should have: /dev/nvme0n1 I think. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Am 18.06.22 um 17:05 schrieb Carlos E. R.:
On 2022-06-18 16:33, Simon Becherer wrote:
Am 18.06.22 um 16:13 schrieb Andrei Borzenkov:
On 18.06.2022 16:57, Simon Becherer wrote: ...
grub2-install /dev/nvme0n1 (make sure you have nvme0n1 NOT nvme0n1pX !!)
change /etc/default/grub_installdevice in my system change first line to: /dev/nvme0n1p2 and delete line 2: (activate) and line 3: (generic_mbr) so only one line is left
That's wrong. First you install grub on the whole disk and then you tell openSUSE tools that grub is installed on partition. The end result will be - during grub update new version will be installed in partition /dev/nvme0n1p2 *and* in /boot/grub2 while system will continue to boot using grub core.img already present in MBR/BIOS grub partition. This may appear to work for some time until new version that has incompatible changes will be installed. Then new modules in /boot/grub2 will no more match core.img in BIOS grub partition and in the best case you will have error on boot, in the worst case - hard to debug problems or hung system. This was known to happen in the past, it is not something rare.
Hi andrey,
ok, then i have something misunderstand.
i like to have grub2 inside /boot/grub (as it was with mbr)
i have understand: 1 frist part of boot is inside the first 34 sectors of disk (at least a pointer to the bios-boot-partition)
I understand it is in the first sector, just one sector, which is called the MBR. In case of GPT partitioning table, it is called the protective MBR.
2 part of grub (in this case some code who is able to read ext4) is now inside that bios-boot-partition (core.img). 3 part of grub is inside /boot/grub2 /the menue and all the other things needed)
that is what i like to have. and what i was thinking i have now installed.
if it is not like this, where is my mistake?
/etc/default/grub_installdevice should have:
/dev/nvme0n1
I think.
how sure you think ? do you know some documentation about this file? and maybe i have found another problem: https://www.gnu.org/software/grub/manual/grub/grub.html#Invoking-grub_002din... --recheck Recheck the device map, even if /boot/grub/device.map already exists. You should use this option whenever you add/remove a disk into/from your computer. so maybe a good idea to do a: grub2-install --recheck /dev/nvme0n1 simoN -- www.becherer.de
On 2022-06-18 17:22, Simon Becherer wrote:
Am 18.06.22 um 17:05 schrieb Carlos E. R.:
On 2022-06-18 16:33, Simon Becherer wrote:
Am 18.06.22 um 16:13 schrieb Andrei Borzenkov:
On 18.06.2022 16:57, Simon Becherer wrote: ...
if it is not like this, where is my mistake?
/etc/default/grub_installdevice should have:
/dev/nvme0n1
I think.
how sure you think ? do you know some documentation about this file?
My own system, which is BIOS based and has a GPT disk. Elesar:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NB0J535704L Elesar:~ # -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Am 18.06.22 um 17:31 schrieb Carlos E. R.:
On 2022-06-18 17:22, Simon Becherer wrote:
Am 18.06.22 um 17:05 schrieb Carlos E. R.:
On 2022-06-18 16:33, Simon Becherer wrote:
Am 18.06.22 um 16:13 schrieb Andrei Borzenkov:
On 18.06.2022 16:57, Simon Becherer wrote: ...
if it is not like this, where is my mistake?
/etc/default/grub_installdevice should have:
/dev/nvme0n1
I think.
how sure you think ? do you know some documentation about this file?
My own system, which is BIOS based and has a GPT disk.
Elesar:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NB0J535704L Elesar:~ #
good argument simoN -- www.becherer.de
Am 18.06.22 um 16:33 schrieb Simon Becherer:
Am 18.06.22 um 16:13 schrieb Andrei Borzenkov:
On 18.06.2022 16:57, Simon Becherer wrote: ...
grub2-install /dev/nvme0n1 (make sure you have nvme0n1 NOT nvme0n1pX !!)
change /etc/default/grub_installdevice in my system change first line to: /dev/nvme0n1p2 and delete line 2: (activate) and line 3: (generic_mbr) so only one line is left
That's wrong. First you install grub on the whole disk and then you tell openSUSE tools that grub is installed on partition. The end result will be - during grub update new version will be installed in partition /dev/nvme0n1p2 *and* in /boot/grub2 while system will continue to boot using grub core.img already present in MBR/BIOS grub partition. This may appear to work for some time until new version that has incompatible changes will be installed. Then new modules in /boot/grub2 will no more match core.img in BIOS grub partition and in the best case you will have error on boot, in the worst case - hard to debug problems or hung system. This was known to happen in the past, it is not something rare.
Hi andrey,
ok, then i have something misunderstand.
i like to have grub2 inside /boot/grub (as it was with mbr)
i have understand: 1 frist part of boot is inside the first 34 sectors of disk (at least a pointer to the bios-boot-partition) 2 part of grub (in this case some code who is able to read ext4) is now inside that bios-boot-partition (core.img). 3 part of grub is inside /boot/grub2 /the menue and all the other things needed)
that is what i like to have. and what i was thinking i have now installed.
if it is not like this, where is my mistake?
simoN
according to this: https://www.gnu.org/software/grub/manual/grub/grub.html#Invoking-grub_002din... grub-install /dev/sda is equivalent to grub-install --boot-directory=/boot/ /dev/sda in my case "/" is "nvme0n1p2" so the command above "grub2-install /dev/nvme0n1" is correct to install a core.img inside the bios-boot-partition and the files inside /boot/ as a result of this analysis you tell me that the content of my: "/etc/default/grub_installdevice" file is wrong ???????? i have inside only one line: /dev/nvme0n1p2 that points to the partition where /boot is. must it point to the partition where the core.img is ? that would be /dev/nvme0n1p1 or must there be not a partition inside instead a whole disk: /dev/nvme0n1 ?? sorry, i have not found any documentation what has to be inside that file. (using google) simoN --
On 2022-06-18 17:10, Simon Becherer wrote:
Am 18.06.22 um 16:33 schrieb Simon Becherer:
Am 18.06.22 um 16:13 schrieb Andrei Borzenkov:
On 18.06.2022 16:57, Simon Becherer wrote: ...
grub2-install /dev/nvme0n1 (make sure you have nvme0n1 NOT nvme0n1pX !!)
change /etc/default/grub_installdevice in my system change first line to: /dev/nvme0n1p2 and delete line 2: (activate) and line 3: (generic_mbr) so only one line is left
That's wrong. First you install grub on the whole disk and then you tell openSUSE tools that grub is installed on partition. The end result will be - during grub update new version will be installed in partition /dev/nvme0n1p2 *and* in /boot/grub2 while system will continue to boot using grub core.img already present in MBR/BIOS grub partition. This may appear to work for some time until new version that has incompatible changes will be installed. Then new modules in /boot/grub2 will no more match core.img in BIOS grub partition and in the best case you will have error on boot, in the worst case - hard to debug problems or hung system. This was known to happen in the past, it is not something rare.
Hi andrey,
ok, then i have something misunderstand.
i like to have grub2 inside /boot/grub (as it was with mbr)
i have understand: 1 frist part of boot is inside the first 34 sectors of disk (at least a pointer to the bios-boot-partition) 2 part of grub (in this case some code who is able to read ext4) is now inside that bios-boot-partition (core.img). 3 part of grub is inside /boot/grub2 /the menue and all the other things needed)
that is what i like to have. and what i was thinking i have now installed.
if it is not like this, where is my mistake?
simoN
according to this:
https://www.gnu.org/software/grub/manual/grub/grub.html#Invoking-grub_002din... grub-install /dev/sda is equivalent to grub-install --boot-directory=/boot/ /dev/sda
in my case "/" is "nvme0n1p2" so the command above "grub2-install /dev/nvme0n1" is correct to install a core.img inside the bios-boot-partition and the files inside /boot/
as a result of this analysis you tell me that the content of my: "/etc/default/grub_installdevice" file is wrong ???????? i have inside only one line: /dev/nvme0n1p2
that points to the partition where /boot is. must it point to the partition where the core.img is ? that would be /dev/nvme0n1p1 or must there be not a partition inside instead a whole disk: /dev/nvme0n1 ??
sorry, i have not found any documentation what has to be inside that file. (using google)
When using the MBR, it points to the disk. The system knows that the next stage is in the bios partition, and next in the boot directory or partition, if it is separate. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Am 18.06.22 um 17:16 schrieb Carlos E. R.:
On 2022-06-18 17:10, Simon Becherer wrote:
Am 18.06.22 um 16:33 schrieb Simon Becherer:
Am 18.06.22 um 16:13 schrieb Andrei Borzenkov:
On 18.06.2022 16:57, Simon Becherer wrote: ...
grub2-install /dev/nvme0n1 (make sure you have nvme0n1 NOT nvme0n1pX !!)
change /etc/default/grub_installdevice in my system change first line to: /dev/nvme0n1p2 and delete line 2: (activate) and line 3: (generic_mbr) so only one line is left
That's wrong. First you install grub on the whole disk and then you tell openSUSE tools that grub is installed on partition. The end result will be - during grub update new version will be installed in partition /dev/nvme0n1p2 *and* in /boot/grub2 while system will continue to boot using grub core.img already present in MBR/BIOS grub partition. This may appear to work for some time until new version that has incompatible changes will be installed. Then new modules in /boot/grub2 will no more match core.img in BIOS grub partition and in the best case you will have error on boot, in the worst case - hard to debug problems or hung system. This was known to happen in the past, it is not something rare.
Hi andrey,
ok, then i have something misunderstand.
i like to have grub2 inside /boot/grub (as it was with mbr)
i have understand: 1 frist part of boot is inside the first 34 sectors of disk (at least a pointer to the bios-boot-partition) 2 part of grub (in this case some code who is able to read ext4) is now inside that bios-boot-partition (core.img). 3 part of grub is inside /boot/grub2 /the menue and all the other things needed)
that is what i like to have. and what i was thinking i have now installed.
if it is not like this, where is my mistake?
simoN
according to this:
https://www.gnu.org/software/grub/manual/grub/grub.html#Invoking-grub_002din... grub-install /dev/sda is equivalent to grub-install --boot-directory=/boot/ /dev/sda
in my case "/" is "nvme0n1p2" so the command above "grub2-install /dev/nvme0n1" is correct to install a core.img inside the bios-boot-partition and the files inside /boot/
as a result of this analysis you tell me that the content of my: "/etc/default/grub_installdevice" file is wrong ???????? i have inside only one line: /dev/nvme0n1p2
that points to the partition where /boot is. must it point to the partition where the core.img is ? that would be /dev/nvme0n1p1 or must there be not a partition inside instead a whole disk: /dev/nvme0n1 ??
sorry, i have not found any documentation what has to be inside that file. (using google)
When using the MBR, it points to the disk. The system knows that the next stage is in the bios partition, and next in the boot directory or partition, if it is separate.
i do not understand, a other system tumbleweed i use, is mbr no gpt and has 3 lines inside: "/dev/nvme0n1p1 activate generic_mbr" i never touched this file by hand. so there is not a disk, there is a partition and that is the partition where /boot is on. why is this different to a gpt where i have (maybe) to write a disk not the partition in? where is the dorcumentation of this fiele ? simoN -- www.becherer.de
On 2022-06-18 17:40, Simon Becherer wrote:
Am 18.06.22 um 17:16 schrieb Carlos E. R.:
On 2022-06-18 17:10, Simon Becherer wrote:
Am 18.06.22 um 16:33 schrieb Simon Becherer:
Am 18.06.22 um 16:13 schrieb Andrei Borzenkov:
On 18.06.2022 16:57, Simon Becherer wrote:
...
as a result of this analysis you tell me that the content of my: "/etc/default/grub_installdevice" file is wrong ???????? i have inside only one line: /dev/nvme0n1p2
that points to the partition where /boot is. must it point to the partition where the core.img is ? that would be /dev/nvme0n1p1 or must there be not a partition inside instead a whole disk: /dev/nvme0n1 ??
sorry, i have not found any documentation what has to be inside that file. (using google)
When using the MBR, it points to the disk. The system knows that the next stage is in the bios partition, and next in the boot directory or partition, if it is separate.
i do not understand, a other system tumbleweed i use, is mbr no gpt and has 3 lines inside: "/dev/nvme0n1p1 activate generic_mbr"
I do not know what the other two lines do. I know that the first line, in this case, is the whole disk. I know that in my machine, which is bios based and uses a GPT disk, that file has a single line pointing to the disk: Elesar:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NB0J535704L Elesar:~ # And this was done by YaST, so it must be correct. And you have seen the partition table: Elesar:~ # fdisk -l /dev/sda Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors Disk model: Samsung SSD 850 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: DD259BAE-154F-49DC-83F9-EA43B4A27EEE Device Start End Sectors Size Type /dev/sda1 2048 50333695 50331648 24G Linux swap /dev/sda2 50333696 50364415 30720 15M BIOS boot /dev/sda3 50364416 81819647 31455232 15G Linux filesystem /dev/sda4 81819648 291534847 209715200 100G Linux filesystem /dev/sda5 291534848 343963647 52428800 25G Linux filesystem Elesar:~ #
sda sda 512 0 0 232.9G disk ... Samsung_SSD_850_EVO_250GB ├─sda1 sda1 24G part swap ssd-swap ssd-swap ├─sda2 sda2 15M part primary ├─sda3 sda3 15G part ext4 ssd-test primary ├─sda4 sda4 100G part crypto_LUKS ssd_home_cr
i never touched this file by hand.
so there is not a disk, there is a partition and that is the partition where /boot is on. why is this different to a gpt where i have (maybe) to write a disk not the partition in?
where is the dorcumentation of this fiele ?
simoN
-- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Am 18.06.22 um 18:01 schrieb Carlos E. R.:
i do not understand, a other system tumbleweed i use, is mbr no gpt and has 3 lines inside: "/dev/nvme0n1p1 activate generic_mbr"
I do not know what the other two lines do.
I know that the first line, in this case, is the whole disk.
no first line is a partition. disk would be nvme0n1 (without "p1")
I know that in my machine, which is bios based and uses a GPT disk, that file has a single line pointing to the disk:
Elesar:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NB0J535704L Elesar:~ #
And this was done by YaST, so it must be correct.
so i have changed my entry to the whole disk. and try to thrust you and yast ;-)) simoN -- www.becherer.de
On 18.06.2022 18:10, Simon Becherer wrote: ...
according to this:
https://www.gnu.org/software/grub/manual/grub/grub.html#Invoking-grub_002din... grub-install /dev/sda is equivalent to grub-install --boot-directory=/boot/ /dev/sda
in my case "/" is "nvme0n1p2" so the command above "grub2-install /dev/nvme0n1" is correct to install a core.img inside the bios-boot-partition and the files inside /boot/
as a result of this analysis you tell me that the content of my: "/etc/default/grub_installdevice" file is wrong ???????? i have inside only one line: /dev/nvme0n1p2
that points to the partition where /boot is.
This line should point to the disk location where the primary boot sector is installed. I already described it in this thread. I repeat first part is code in MBR or PBR (the very first sector of the disk or partition). This code knows how to load core.img from disk using absolute disk location computed by grub2-install and stored in this first sector. core.img contains drivers to access /boot/grub2 and location of /boot/grub2. This location is computed by grub2-install and stored in core.img. /boot/grub2 contains all other grub2 modules (drivers) and other supporting files and grub.cfg.
must it point to the partition where the core.img is ?
It must point to the location where the very first sector is written. core.img location is determined automatically by grub2-install depending on where this sector is written.
that would be /dev/nvme0n1p1 or must there be not a partition inside instead a whole disk: /dev/nvme0n1 ??
What it should be depends on what you need, but you should be consistent and do not tell different tools to install grub in different locations.
sorry, i have not found any documentation what has to be inside that file. (using google)
This file is (open)SUSE specific and I do not think it is documented anywhere except source code.
Hi andrei i get crazy here, i do not get the point. :-(( i really read carefully your explanation. another try: Am 18.06.22 um 18:36 schrieb Andrei Borzenkov:
first part is code in MBR or PBR (the very first sector of the disk or partition). This code knows how to load core.img from disk using
.. snip.....
It must point to the location where the very first sector is written.
ok. because i have done a: grub2-install /dev/nvme0n1 its on the very first part of the disk. (not the partition) is /dev/nvme0n1 for my detailed explained howto then correct? according to the grub2 manpage it must always be the whole disk behind the command so i have no chance to write it somewhere else? or how would be the command to write it into the first sector of second partition? why is then at my old mbr system inside the file /etc/default/grub_installdevice /dev/sda1 activate generic_mbr and not /dev/sda ?
This file is (open)SUSE specific and I do not think it is documented anywhere except source code.
that's bad. would be glad of you if you try again to explain me this. simoN -- becherer.de
On 18/06/2022 19.35, Simon Becherer wrote:
Hi andrei i get crazy here, i do not get the point. :-(( i really read carefully your explanation.
another try:
Am 18.06.22 um 18:36 schrieb Andrei Borzenkov:
first part is code in MBR or PBR (the very first sector of the disk or partition). This code knows how to load core.img from disk using
.. snip.....
It must point to the location where the very first sector is written.
ok. because i have done a: grub2-install /dev/nvme0n1 its on the very first part of the disk. (not the partition)
is /dev/nvme0n1 for my detailed explained howto then correct?
according to the grub2 manpage it must always be the whole disk behind the command so i have no chance to write it somewhere else? or how would be the command to write it into the first sector of second partition?
why is then at my old mbr system inside the file /etc/default/grub_installdevice /dev/sda1 activate generic_mbr
and not /dev/sda ?
Grub can be installed "on the disk" or "on a partition". You are installing it on a disk. If you install it to a partition instead, you also have to "activate" that partition, and write "generic" code to the disk, ie, the mbr. That's what those two lines mean. But you are installing instead to the disk, to the MBR. Where you install must match what that file says. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
Am 18.06.22 um 23:03 schrieb Carlos E. R.:
On 18/06/2022 19.35, Simon Becherer wrote:
why is then at my old mbr system inside the file /etc/default/grub_installdevice /dev/sda1 activate generic_mbr
and not /dev/sda ?
Grub can be installed "on the disk" or "on a partition". You are installing it on a disk.
If you install it to a partition instead, you also have to "activate" that partition, and write "generic" code to the disk, ie, the mbr. That's what those two lines mean. But you are installing instead to the disk, to the MBR. Where you install must match what that file says.
hi boris, hi carlos, ok. think i have now understand for me only a little unclear why WAS it on my disk, with a standart tumbleweed new installation installed inside the sda1 partition and not inside the whole disk mbr? installation was done 2019 (if as i read "not recommended") and boris i found: https://github.com/arvidjaar/bootinfoscript "Current developer: Andrei Borzenkov" on a dos-mbr nvme system (not gpt) with grub and same 2019 installed tumbleweed on it: grub_installdevice has: /dev/nvme0n1p1 activate generic_mbr the script tells me: ==================================================================== Boot Info Script 0.78 [09 October 2019] ============================= Boot Info Summary: =============================== ============================ Drive/Partition Info: ============================= no valid partition table found "blkid" output: ________________________________________________________________ Device UUID TYPE LABEL /dev/nvme0n1p1 aa8cbef7-c727-4923-85ab-9e2b51f09328 ext4 ssd-system /dev/nvme0n1p2 a0a40027-0dd6-4d06-b391-f6b222a2f17d ext4 ssd-home ========= i guess after a short eye on the script you do not support nvme for analyse? simoN -- B e c h e r e r GmbH Sondermaschinenbau Mauermatten Strasse 22 79183 Waldkirch Germany Tel.: (+49) (0)7681 3134 Fax: (+49) (0)7681 4378 Mail: info@becherer.de Web: www.becherer.de USt-ID-Nr.: DE 814912198 Registergericht: Freiburg HRB 701860 Geschäftsführer: Dipl.-Ing. (FH), EWE Simon H. Becherer Gerichtsstand / Sitz: Waldkirch Es gelten ausschließlich unsere allgemeinen Liefer- und Zahlungsbedingungen / Einkaufsbedingungen: www.becherer.de/AGB
On 19.06.2022 11:06, Simon Becherer wrote:
for me only a little unclear why WAS it on my disk, with a standart tumbleweed new installation installed inside the sda1 partition and not inside the whole disk mbr? installation was done 2019 (if as i read "not recommended")
Because this is the most safe default in general case. Many people use multiboot and there is only one MBR so only one OS can have bootloader in MBR. At which point it is much easier to have consistent installation where every OS has bootloader in its own partition.
i guess after a short eye on the script you do not support nvme for analyse?
Correct. Bootinfoscript is not of much use on UEFI and so far this is the first time I see someone using legacy BIOS boot with NVMe.
On 18.06.2022 20:35, Simon Becherer wrote:
Hi andrei i get crazy here, i do not get the point. :-(( i really read carefully your explanation.
Carlos already explained it again.
another try:
Am 18.06.22 um 18:36 schrieb Andrei Borzenkov:
first part is code in MBR or PBR (the very first sector of the disk or partition). This code knows how to load core.img from disk using
.. snip.....
It must point to the location where the very first sector is written.
ok. because i have done a: grub2-install /dev/nvme0n1 its on the very first part of the disk. (not the partition)
is /dev/nvme0n1 for my detailed explained howto then correct?
according to the grub2 manpage it must always be the whole disk behind the command so i have no chance to write it somewhere else? or how would be the command to write it into the first sector of second partition?
why is then at my old mbr system inside the file /etc/default/grub_installdevice /dev/sda1 activate generic_mbr
and not /dev/sda ?
Because your system was configured to install grub2 on /dev/sda1.
This file is (open)SUSE specific and I do not think it is documented anywhere except source code.
that's bad.
would be glad of you if you try again to explain me this.
simoN
-- becherer.de
On 2022-06-18 16:13, Andrei Borzenkov wrote:
On 18.06.2022 16:57, Simon Becherer wrote: ...
grub2-install /dev/nvme0n1 (make sure you have nvme0n1 NOT nvme0n1pX !!)
change /etc/default/grub_installdevice in my system change first line to: /dev/nvme0n1p2 and delete line 2: (activate) and line 3: (generic_mbr) so only one line is left
That's wrong. First you install grub on the whole disk and then you tell openSUSE tools that grub is installed on partition. The end result will be - during grub update new version will be installed in partition /dev/nvme0n1p2 *and* in /boot/grub2 while system will continue to boot using grub core.img already present in MBR/BIOS grub partition. This may appear to work for some time until new version that has incompatible changes will be installed. Then new modules in /boot/grub2 will no more match core.img in BIOS grub partition and in the best case you will have error on boot, in the worst case - hard to debug problems or hung system. This was known to happen in the past, it is not something rare.
That, or very similar, happened to me. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 2022-06-13 11:43, Simon Becherer wrote:
Am 13.06.22 um 11:26 schrieb Andrei Borzenkov:
On 13.06.2022 11:19, Simon Becherer wrote:
If you want to install grub in GPT MBR, you will need BIOS boot partition. It better be located in the beginning to avoid any possible issues with BIOS access disk size limits.
here i do also not understand. actually i was thinking somewhere in mbr or gpt (the firts 2048 sectors) is the grub part which only says: "read /boot...."
Correct for MBR, wrong for GPT.
sorry still very unclear in my mind. so its not possible to boot from gpt-ext4 partition without having an additional uefi boot partition?
Not uefi boot partition, but a special, tiny partition, used by the bios to boot from the MBR on GPT disks. It is about 8 megabytes. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Hi carlos, Am 13.06.22 um 18:39 schrieb Carlos E. R.:
On 2022-06-13 11:43, Simon Becherer wrote:
sorry still very unclear in my mind. so its not possible to boot from gpt-ext4 partition without having an additional uefi boot partition?
Not uefi boot partition, but a special, tiny partition, used by the bios to boot from the MBR on GPT disks. It is about 8 megabytes.
because my first partition starts at sector 2048x512bytes so there is no space for this partition. Am 13.06.22 um 18:22 schrieb Andrei Borzenkov:
If you convert MBR into GPT in place, your system will likely fail to boot because grub2 first stage code will not include GPT support and will not find /boot/grub2. You need to reinstall grub2 to build the correct first stage code and if you want to install it in MBR you need BIOS grub partition in this case.
i understand this like its not necesarry to have the thiny bios partition IF i have grub inside the ext4 partition /boot/grub2 BUT i have to reinstall grub2. maybe without arguments: "grub2-install" ? or "grub2-install --no-bootsector" ? simoN -- www.becherer.de
On 2022-06-13 18:57, Simon Becherer wrote:
Hi carlos,
Am 13.06.22 um 18:39 schrieb Carlos E. R.:
On 2022-06-13 11:43, Simon Becherer wrote:
sorry still very unclear in my mind. so its not possible to boot from gpt-ext4 partition without having an additional uefi boot partition?
Not uefi boot partition, but a special, tiny partition, used by the bios to boot from the MBR on GPT disks. It is about 8 megabytes.
because my first partition starts at sector 2048x512bytes so there is no space for this partition.
It doesn't have to be at the start.
Am 13.06.22 um 18:22 schrieb Andrei Borzenkov:
If you convert MBR into GPT in place, your system will likely fail to boot because grub2 first stage code will not include GPT support and will not find /boot/grub2. You need to reinstall grub2 to build the correct first stage code and if you want to install it in MBR you need BIOS grub partition in this case.
i understand this like its not necesarry to have the thiny bios partition IF i have grub inside the ext4 partition /boot/grub2 BUT i have to reinstall grub2. maybe without arguments: "grub2-install" ? or "grub2-install --no-bootsector" ?
Not exactly. If you have the grub "1st stage ?" (1) on the free space at the start of the root partition, before the filesystem starts, then the bios partition is not really needed. But YaST will bitterly complain, and make hell of upgrading your system and some other times :-P It doesn't go as files, it is raw data written to sectors which numbers are referred to in the (M)BR code. (1) Unsure if 1st, 2nd, or 1,5 stage. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 6/13/22 02:09, Simon Becherer wrote:
now of course the new hda1 is 2tb and have a 1tb unused. because i did not like to have a second partition on it, i have to change to gpt.
Simon I'm confused... You have: New System: 1T ssd (nvme0n1) 3T hdd (hda) Old System 1T hdd (hda) 2T hdd (hdb) You copied using dd?? Old System New System ------------ ------------ 1T hdd (hda) -> 1T ssd (nvme0n1) 2T hdd (hdb) -> 3T hdd (hda) Now you want to convert mbr to gpt on which drive? (the 3T drive right?) Otherwise there is no need to convert. -- David C. Rankin, J.D.,P.E.
Am 13.06.22 um 09:39 schrieb David C. Rankin:
On 6/13/22 02:09, Simon Becherer wrote:
now of course the new hda1 is 2tb and have a 1tb unused. because i did not like to have a second partition on it, i have to change to gpt.
Simon I'm confused...
You have:
New System: 1T ssd (nvme0n1) 3T hdd (hda)
Old System 1T hdd (hda) 2T hdd (hdb)
correct
You copied using dd??
Old System New System ------------ ------------ 1T hdd (hda) -> 1T ssd (nvme0n1) 2T hdd (hdb) -> 3T hdd (hda) correct
Now you want to convert mbr to gpt on which drive? (the 3T drive right?)
Otherwise there is no need to convert.
i was thinking to convert both drives. but you are correct, for the ssd there is not a MUST, i was thinking to be more modern and maybe more save for data loss. simoN -- www.becherer.de
participants (6)
-
Andrei Borzenkov -
Carlos E. R. -
David C. Rankin -
jdd＠dodin.org -
Markus Koßmann -
Simon Becherer