What are the differences between the purposes of `core.img` and files in `/boot/grub`?
Clash Royale CLAN TAG#URR8PPP
What are the differences between the purposes of core.img and files in /boot/grub? Thanks.
I often heard of two stage bootloading. while here seems to be three stage bootloading in
https://en.wikipedia.org/wiki/GNU_GRUB#Version_2_(GRUB)
Stage 1: boot.img is stored in the master boot record (MBR) or
optionally in any of the volume boot records (VBRs), and addresses the
next stage by an LBA48 address (thus, the 1024-cylinder limitation of
GRUB legacy is avoided); at installation time it is configured to load
the first sector of core.img.
Stage 1.5: core.img is by default written to the sectors between the
MBR and the first partition, when these sectors are free and
available. For legacy reasons, the first partition of a hard drive
does not begin at sector 1 (counting begins with 0) but at sector 63,
leaving 62 sectors of empty space not part of any partition or file
system, and therefore not prone to any problems related with it. Once
executed, core.img will load its configuration file and any other
modules needed, particularly file system drivers; at installation
time, it is generated from diskboot.img and configured to load the
stage 2 by its file path.
Stage 2: files belonging to the stage 2 are all held in /boot/grub,
which is a subdirectory of the /boot directory specified by the
Filesystem Hierarchy Standard (FHS).
grub2 grub
asked Feb 22 at 12:40
TimTim
27.8k78269486
add a comment |
What are the differences between the purposes of core.img and files in /boot/grub? Thanks.
I often heard of two stage bootloading. while here seems to be three stage bootloading in
https://en.wikipedia.org/wiki/GNU_GRUB#Version_2_(GRUB)
Stage 1: boot.img is stored in the master boot record (MBR) or
optionally in any of the volume boot records (VBRs), and addresses the
next stage by an LBA48 address (thus, the 1024-cylinder limitation of
GRUB legacy is avoided); at installation time it is configured to load
the first sector of core.img.
Stage 1.5: core.img is by default written to the sectors between the
MBR and the first partition, when these sectors are free and
available. For legacy reasons, the first partition of a hard drive
does not begin at sector 1 (counting begins with 0) but at sector 63,
leaving 62 sectors of empty space not part of any partition or file
system, and therefore not prone to any problems related with it. Once
executed, core.img will load its configuration file and any other
modules needed, particularly file system drivers; at installation
time, it is generated from diskboot.img and configured to load the
stage 2 by its file path.
Stage 2: files belonging to the stage 2 are all held in /boot/grub,
which is a subdirectory of the /boot directory specified by the
Filesystem Hierarchy Standard (FHS).
grub2 grub
asked Feb 22 at 12:40
TimTim
27.8k78269486
Isn't the answer already in the question?
– 炸鱼薯条德里克
Feb 22 at 13:58
No, it isn't...
– Tim
Feb 22 at 14:06
They're used to show you the general idea of how grub works, doesn't mean all bootloader work like this. It can be completely different.
– 炸鱼薯条德里克
Feb 23 at 6:44
add a comment |
What are the differences between the purposes of core.img and files in /boot/grub? Thanks.
I often heard of two stage bootloading. while here seems to be three stage bootloading in
https://en.wikipedia.org/wiki/GNU_GRUB#Version_2_(GRUB)
Stage 1: boot.img is stored in the master boot record (MBR) or
optionally in any of the volume boot records (VBRs), and addresses the
next stage by an LBA48 address (thus, the 1024-cylinder limitation of
GRUB legacy is avoided); at installation time it is configured to load
the first sector of core.img.
Stage 1.5: core.img is by default written to the sectors between the
MBR and the first partition, when these sectors are free and
available. For legacy reasons, the first partition of a hard drive
does not begin at sector 1 (counting begins with 0) but at sector 63,
leaving 62 sectors of empty space not part of any partition or file
system, and therefore not prone to any problems related with it. Once
executed, core.img will load its configuration file and any other
modules needed, particularly file system drivers; at installation
time, it is generated from diskboot.img and configured to load the
stage 2 by its file path.
Stage 2: files belonging to the stage 2 are all held in /boot/grub,
which is a subdirectory of the /boot directory specified by the
Filesystem Hierarchy Standard (FHS).
grub2 grub
asked Feb 22 at 12:40
TimTim
27.8k78269486
What are the differences between the purposes of core.img and files in /boot/grub? Thanks.
I often heard of two stage bootloading. while here seems to be three stage bootloading in
https://en.wikipedia.org/wiki/GNU_GRUB#Version_2_(GRUB)
Stage 1: boot.img is stored in the master boot record (MBR) or
optionally in any of the volume boot records (VBRs), and addresses the
next stage by an LBA48 address (thus, the 1024-cylinder limitation of
GRUB legacy is avoided); at installation time it is configured to load
the first sector of core.img.
Stage 1.5: core.img is by default written to the sectors between the
MBR and the first partition, when these sectors are free and
available. For legacy reasons, the first partition of a hard drive
does not begin at sector 1 (counting begins with 0) but at sector 63,
leaving 62 sectors of empty space not part of any partition or file
system, and therefore not prone to any problems related with it. Once
executed, core.img will load its configuration file and any other
modules needed, particularly file system drivers; at installation
time, it is generated from diskboot.img and configured to load the
stage 2 by its file path.
Stage 2: files belonging to the stage 2 are all held in /boot/grub,
which is a subdirectory of the /boot directory specified by the
Filesystem Hierarchy Standard (FHS).
grub2 grub
grub2 grub
asked Feb 22 at 12:40
TimTim
27.8k78269486
asked Feb 22 at 12:40
TimTim
27.8k78269486
asked Feb 22 at 12:40
TimTim
27.8k78269486
asked Feb 22 at 12:40
TimTim
27.8k78269486
asked Feb 22 at 12:40
TimTim
27.8k78269486
27.8k78269486
Isn't the answer already in the question?
– 炸鱼薯条德里克
Feb 22 at 13:58
No, it isn't...
– Tim
Feb 22 at 14:06
They're used to show you the general idea of how grub works, doesn't mean all bootloader work like this. It can be completely different.
– 炸鱼薯条德里克
Feb 23 at 6:44
add a comment |
Isn't the answer already in the question?
– 炸鱼薯条德里克
Feb 22 at 13:58
No, it isn't...
– Tim
Feb 22 at 14:06
They're used to show you the general idea of how grub works, doesn't mean all bootloader work like this. It can be completely different.
– 炸鱼薯条德里克
Feb 23 at 6:44
Isn't the answer already in the question?
– 炸鱼薯条德里克
Feb 22 at 13:58
Isn't the answer already in the question?
– 炸鱼薯条德里克
Feb 22 at 13:58
No, it isn't...
– Tim
Feb 22 at 14:06
No, it isn't...
– Tim
Feb 22 at 14:06
They're used to show you the general idea of how grub works, doesn't mean all bootloader work like this. It can be completely different.
– 炸鱼薯条德里克
Feb 23 at 6:44
They're used to show you the general idea of how grub works, doesn't mean all bootloader work like this. It can be completely different.
– 炸鱼薯条德里克
Feb 23 at 6:44
add a comment |
1 Answer
1
active
oldest
votes
/boot/grub contains all of GRUB (which is split up into modules). The purpose of GRUB is to provide an environment from which a full-blown operating system can be booted; GRUB has become a small operating system in its own right, with modules providing support for a variety of storage devices, file systems, encryption layers, software RAID layers, partition maps, methods of interaction with the user, etc.
core.img contains a small subset of GRUB, typically aiming for 32KiB or less. Its purpose is to provide access to /boot/grub: it contains a minimal user interface, and whatever modules are necessary to find and read /boot/grub. It is built specifically for each system it is installed on, based on the requirements of that system, using the grub-mkimage program. See the list of images in the GRUB documentation.
answered Feb 22 at 13:09
Stephen KittStephen Kitt
176k24402479
Thanks. I saw the link. But I thinkcore.imgis the main part of GRUB. If Its purpose is to provide access to /boot/grub, why not just makeboot.imgaccess directly /boot/grub?
– Tim
Feb 22 at 13:29
boot.imgis too limited because of size constraints.
– Stephen Kitt
Feb 22 at 13:35
This exemplifies the huge technical difference between booting using the legacy BIOS and UEFI. The only thing the BIOS is capable of doing is provide a primitive interface to read a disk sector by sector, read the MBR into memory an start execution of the code. UEFI, on the other hand, contains code in ROM that is able to read files from a FAT file system, and provides a rich assortment of system services that the EFI executables can use.
– Johan Myréen
Feb 22 at 16:49
Is this a three stage boot loading? Then what about the two-stage boot loading often heard and seen in OS textbooks: first stage bootloader code is in MBR of a boot disk, and second stage bootloader code in boot sector of a partition?
– Tim
Feb 23 at 2:50
@JohanMyréen How many stages are there in the bootloading stages in UEFI? I am trying to picture a diagram for the bootloading stages in UEFI, similar to the diagram of bootloading stages in BIOS in upload.wikimedia.org/wikipedia/commons/4/45/…?
– Tim
Feb 23 at 3:09
|
show 2 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502287%2fwhat-are-the-differences-between-the-purposes-of-core-img-and-files-in-boot%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
/boot/grub contains all of GRUB (which is split up into modules). The purpose of GRUB is to provide an environment from which a full-blown operating system can be booted; GRUB has become a small operating system in its own right, with modules providing support for a variety of storage devices, file systems, encryption layers, software RAID layers, partition maps, methods of interaction with the user, etc.
core.img contains a small subset of GRUB, typically aiming for 32KiB or less. Its purpose is to provide access to /boot/grub: it contains a minimal user interface, and whatever modules are necessary to find and read /boot/grub. It is built specifically for each system it is installed on, based on the requirements of that system, using the grub-mkimage program. See the list of images in the GRUB documentation.
answered Feb 22 at 13:09
Stephen KittStephen Kitt
176k24402479
Thanks. I saw the link. But I thinkcore.imgis the main part of GRUB. If Its purpose is to provide access to /boot/grub, why not just makeboot.imgaccess directly /boot/grub?
– Tim
Feb 22 at 13:29
boot.imgis too limited because of size constraints.
– Stephen Kitt
Feb 22 at 13:35
This exemplifies the huge technical difference between booting using the legacy BIOS and UEFI. The only thing the BIOS is capable of doing is provide a primitive interface to read a disk sector by sector, read the MBR into memory an start execution of the code. UEFI, on the other hand, contains code in ROM that is able to read files from a FAT file system, and provides a rich assortment of system services that the EFI executables can use.
– Johan Myréen
Feb 22 at 16:49
Is this a three stage boot loading? Then what about the two-stage boot loading often heard and seen in OS textbooks: first stage bootloader code is in MBR of a boot disk, and second stage bootloader code in boot sector of a partition?
– Tim
Feb 23 at 2:50
@JohanMyréen How many stages are there in the bootloading stages in UEFI? I am trying to picture a diagram for the bootloading stages in UEFI, similar to the diagram of bootloading stages in BIOS in upload.wikimedia.org/wikipedia/commons/4/45/…?
– Tim
Feb 23 at 3:09
|
show 2 more comments
/boot/grub contains all of GRUB (which is split up into modules). The purpose of GRUB is to provide an environment from which a full-blown operating system can be booted; GRUB has become a small operating system in its own right, with modules providing support for a variety of storage devices, file systems, encryption layers, software RAID layers, partition maps, methods of interaction with the user, etc.
core.img contains a small subset of GRUB, typically aiming for 32KiB or less. Its purpose is to provide access to /boot/grub: it contains a minimal user interface, and whatever modules are necessary to find and read /boot/grub. It is built specifically for each system it is installed on, based on the requirements of that system, using the grub-mkimage program. See the list of images in the GRUB documentation.
answered Feb 22 at 13:09
Stephen KittStephen Kitt
176k24402479
Thanks. I saw the link. But I thinkcore.imgis the main part of GRUB. If Its purpose is to provide access to /boot/grub, why not just makeboot.imgaccess directly /boot/grub?
– Tim
Feb 22 at 13:29
boot.imgis too limited because of size constraints.
– Stephen Kitt
Feb 22 at 13:35
This exemplifies the huge technical difference between booting using the legacy BIOS and UEFI. The only thing the BIOS is capable of doing is provide a primitive interface to read a disk sector by sector, read the MBR into memory an start execution of the code. UEFI, on the other hand, contains code in ROM that is able to read files from a FAT file system, and provides a rich assortment of system services that the EFI executables can use.
– Johan Myréen
Feb 22 at 16:49
Is this a three stage boot loading? Then what about the two-stage boot loading often heard and seen in OS textbooks: first stage bootloader code is in MBR of a boot disk, and second stage bootloader code in boot sector of a partition?
– Tim
Feb 23 at 2:50
@JohanMyréen How many stages are there in the bootloading stages in UEFI? I am trying to picture a diagram for the bootloading stages in UEFI, similar to the diagram of bootloading stages in BIOS in upload.wikimedia.org/wikipedia/commons/4/45/…?
– Tim
Feb 23 at 3:09
|
show 2 more comments
/boot/grub contains all of GRUB (which is split up into modules). The purpose of GRUB is to provide an environment from which a full-blown operating system can be booted; GRUB has become a small operating system in its own right, with modules providing support for a variety of storage devices, file systems, encryption layers, software RAID layers, partition maps, methods of interaction with the user, etc.
core.img contains a small subset of GRUB, typically aiming for 32KiB or less. Its purpose is to provide access to /boot/grub: it contains a minimal user interface, and whatever modules are necessary to find and read /boot/grub. It is built specifically for each system it is installed on, based on the requirements of that system, using the grub-mkimage program. See the list of images in the GRUB documentation.
answered Feb 22 at 13:09
Stephen KittStephen Kitt
176k24402479
/boot/grub contains all of GRUB (which is split up into modules). The purpose of GRUB is to provide an environment from which a full-blown operating system can be booted; GRUB has become a small operating system in its own right, with modules providing support for a variety of storage devices, file systems, encryption layers, software RAID layers, partition maps, methods of interaction with the user, etc.
core.img contains a small subset of GRUB, typically aiming for 32KiB or less. Its purpose is to provide access to /boot/grub: it contains a minimal user interface, and whatever modules are necessary to find and read /boot/grub. It is built specifically for each system it is installed on, based on the requirements of that system, using the grub-mkimage program. See the list of images in the GRUB documentation.
answered Feb 22 at 13:09
Stephen KittStephen Kitt
176k24402479
answered Feb 22 at 13:09
Stephen KittStephen Kitt
176k24402479
answered Feb 22 at 13:09
Stephen KittStephen Kitt
176k24402479
answered Feb 22 at 13:09
Stephen KittStephen Kitt
176k24402479
176k24402479
Thanks. I saw the link. But I thinkcore.imgis the main part of GRUB. If Its purpose is to provide access to /boot/grub, why not just makeboot.imgaccess directly /boot/grub?
– Tim
Feb 22 at 13:29
boot.imgis too limited because of size constraints.
– Stephen Kitt
Feb 22 at 13:35
This exemplifies the huge technical difference between booting using the legacy BIOS and UEFI. The only thing the BIOS is capable of doing is provide a primitive interface to read a disk sector by sector, read the MBR into memory an start execution of the code. UEFI, on the other hand, contains code in ROM that is able to read files from a FAT file system, and provides a rich assortment of system services that the EFI executables can use.
– Johan Myréen
Feb 22 at 16:49
Is this a three stage boot loading? Then what about the two-stage boot loading often heard and seen in OS textbooks: first stage bootloader code is in MBR of a boot disk, and second stage bootloader code in boot sector of a partition?
– Tim
Feb 23 at 2:50
@JohanMyréen How many stages are there in the bootloading stages in UEFI? I am trying to picture a diagram for the bootloading stages in UEFI, similar to the diagram of bootloading stages in BIOS in upload.wikimedia.org/wikipedia/commons/4/45/…?
– Tim
Feb 23 at 3:09
|
show 2 more comments
Thanks. I saw the link. But I thinkcore.imgis the main part of GRUB. If Its purpose is to provide access to /boot/grub, why not just makeboot.imgaccess directly /boot/grub?
– Tim
Feb 22 at 13:29
boot.imgis too limited because of size constraints.
– Stephen Kitt
Feb 22 at 13:35
This exemplifies the huge technical difference between booting using the legacy BIOS and UEFI. The only thing the BIOS is capable of doing is provide a primitive interface to read a disk sector by sector, read the MBR into memory an start execution of the code. UEFI, on the other hand, contains code in ROM that is able to read files from a FAT file system, and provides a rich assortment of system services that the EFI executables can use.
– Johan Myréen
Feb 22 at 16:49
Is this a three stage boot loading? Then what about the two-stage boot loading often heard and seen in OS textbooks: first stage bootloader code is in MBR of a boot disk, and second stage bootloader code in boot sector of a partition?
– Tim
Feb 23 at 2:50
@JohanMyréen How many stages are there in the bootloading stages in UEFI? I am trying to picture a diagram for the bootloading stages in UEFI, similar to the diagram of bootloading stages in BIOS in upload.wikimedia.org/wikipedia/commons/4/45/…?
– Tim
Feb 23 at 3:09
Thanks. I saw the link. But I think
core.img is the main part of GRUB. If Its purpose is to provide access to /boot/grub, why not just make boot.img access directly /boot/grub?– Tim
Feb 22 at 13:29
Thanks. I saw the link. But I think
core.img is the main part of GRUB. If Its purpose is to provide access to /boot/grub, why not just make boot.img access directly /boot/grub?– Tim
Feb 22 at 13:29
boot.img is too limited because of size constraints.– Stephen Kitt
Feb 22 at 13:35
boot.img is too limited because of size constraints.– Stephen Kitt
Feb 22 at 13:35
This exemplifies the huge technical difference between booting using the legacy BIOS and UEFI. The only thing the BIOS is capable of doing is provide a primitive interface to read a disk sector by sector, read the MBR into memory an start execution of the code. UEFI, on the other hand, contains code in ROM that is able to read files from a FAT file system, and provides a rich assortment of system services that the EFI executables can use.
– Johan Myréen
Feb 22 at 16:49
This exemplifies the huge technical difference between booting using the legacy BIOS and UEFI. The only thing the BIOS is capable of doing is provide a primitive interface to read a disk sector by sector, read the MBR into memory an start execution of the code. UEFI, on the other hand, contains code in ROM that is able to read files from a FAT file system, and provides a rich assortment of system services that the EFI executables can use.
– Johan Myréen
Feb 22 at 16:49
Is this a three stage boot loading? Then what about the two-stage boot loading often heard and seen in OS textbooks: first stage bootloader code is in MBR of a boot disk, and second stage bootloader code in boot sector of a partition?
– Tim
Feb 23 at 2:50
Is this a three stage boot loading? Then what about the two-stage boot loading often heard and seen in OS textbooks: first stage bootloader code is in MBR of a boot disk, and second stage bootloader code in boot sector of a partition?
– Tim
Feb 23 at 2:50
@JohanMyréen How many stages are there in the bootloading stages in UEFI? I am trying to picture a diagram for the bootloading stages in UEFI, similar to the diagram of bootloading stages in BIOS in upload.wikimedia.org/wikipedia/commons/4/45/…?
– Tim
Feb 23 at 3:09
@JohanMyréen How many stages are there in the bootloading stages in UEFI? I am trying to picture a diagram for the bootloading stages in UEFI, similar to the diagram of bootloading stages in BIOS in upload.wikimedia.org/wikipedia/commons/4/45/…?
– Tim
Feb 23 at 3:09
|
show 2 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502287%2fwhat-are-the-differences-between-the-purposes-of-core-img-and-files-in-boot%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Isn't the answer already in the question?
– 炸鱼薯条德里克
Feb 22 at 13:58
No, it isn't...
– Tim
Feb 22 at 14:06
They're used to show you the general idea of how grub works, doesn't mean all bootloader work like this. It can be completely different.
– 炸鱼薯条德里克
Feb 23 at 6:44