blocks|key|1817575|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<code>update-grub</code>, at least in Debian and its relatives like Ubuntu, is basically just a wrapper around <code>grub-mkconfig</code>. So it creates/updates/regenerates the GRUB configuration, not the actual bootloader itself.
What the <code>grub-install</code> actually does depends on which version of GRUB you are running: traditional BIOS GRUB or UEFI GRUB?
With the traditional BIOS GRUB, <code>grub-install</code> will (re)write the part of the GRUB embedded in the Master Boot Record, and encode into it the physical disk block numbers from where to read the next part of GRUB. It will also determine from which partition the actual GRUB configuration file (<code>/boot/grub/grub.cfg</code>) will be read. An important factor here is the <code>/boot/grub/device.map</code> file, which tells GRUB how BIOS's (and therefore GRUB's) device numbering maps to Linux disk devices.
With the UEFI GRUB, the main part of the GRUB bootloader will be located as a file in the EFI System Partition, typically as <code>/boot/efi/EFI/&lt;name of distribution&gt;/grubx64.efi</code> or similar. This bootloader pathname is stored in system NVRAM (= the place where BIOS settings are stored) in the UEFI boot variables. The main part of GRUB may be completely self-contained (and must be if Secure Boot is in use!) or it may load additional functionality as GRUB modules, typically from the <code>/boot/grub</code> directory of the Linux distribution it's part of.
The UEFI boot variables will identify the disk the system should use to look for the EFI System Partition and the bootloader file inside it. You can view these variables yourself, using <code>efibootmgr -v</code> command. The <code>grub-install</code> command will update those variables, unless you use the <code>--no-nvram</code> option to specify otherwise.
<hr />
Once GRUB is running, the next thing to be determined is: where it should read its configuration file from?
<code>grub-install</code> has the capability to insert the desired value of the GRUB <code>prefix</code> variable directly into the main part of GRUB. This embedded prefix can either fully specify the path, or leave some parts out to be determined at run-time, using architecture-specific defaults.
With a traditional BIOS GRUB, the embedded prefix usually leaves the actual disk specifier out, so the same disk GRUB was loaded from will be used. In that case, the stored prefix will be e.g. <code>(,msdos1)/grub</code> when
<code>/boot</code> is the first primary partition on the disk GRUB is installed to.
With the UEFI GRUB, the embedded prefix usually specifies just the directory, and then it refers to the distribution's directory on the EFI System Partition (ESP). So a typical embedded prefix would be <code>/EFI/debian</code> or <code>/EFI/redhat</code> or similar. The default value for the disk and partition will be &quot;the same partition the UEFI GRUB binary was loaded from&quot;.
Some distributions like RHEL will just place the actual configuration for UEFI GRUB directly onto the ESP. Debian and related distributions will usually do one more bit of indirection: the mini-<code>grub.cfg</code> file on the ESP will contain just a few lines that will tell GRUB to read the real configuration file from what will be <code>/boot/grub/grub.cfg</code> once Linux has booted up and mounted all the disks. At its simplest, this mini-configuration will be just three lines:
<ol>
<li>Setting the GRUB root to point to the filesystem that contains the real GRUB configuration file (for the upcoming <code>configfile</code> command), in modern distributions usually using the <code>search</code> command and a filesystem UUID. The oldest implementations of this scheme might have actually used a fixed GRUB partition specification, e.g. <code>set root=(hd0,gpt1)</code></li>
<li>Setting the GRUB <code>prefix</code> variable (to enable GRUB module auto-loading if Secure Boot is not in effect). If the filesystem where the configuration will be loaded is the Linux root filesystem, this line will be <code>set prefix=($root)'/boot/grub'</code>; if <code>/boot</code> is a separate filesystem, this line will be <code>set prefix=($root)'/grub'</code></li>
<li>Reading the actual GRUB configuration file with <code>configfile $prefix/grub.cfg</code>.</li>
</ol>
If the filesystem that contains the GRUB configuration is on a LVM logical volume, encrypted volume, or a software RAID set, then the first line will be more complex or there might even be additional line(s) as necessary.
<hr />
As a result, with both traditional BIOS and UEFI, running <code>grub-install</code> can update your bootloader to read a completely different GRUB configuration file on a completely different disk - although the details of that process will be completely different.
With UEFI, you can actually change your boot device selection from within the OS, with either <code>efibootmgr</code> or <code>grub-install</code>. But <code>grub-install</code> is a massive overkill for that: if both your installations are UEFI and have their own separate ESP partitions, they will have their own UEFI boot variables and selecting between them can easily be done with <code>efibootmgr</code>, or indeed in the UEFI BIOS settings.
With traditional BIOS, it's a bit messier: you'll want to make sure each installation's <code>/boot/grub/device.map</code> identifies the disk of that specific installation as <code>hd0</code>, and the other one as <code>hd1</code>. Then use <code>grub-install</code> to only write the bootloader to each installation's own disk; never to the &quot;opposite&quot; disk. That way, both disks will be completely stand-alone and bootable even if the other disk is completely removed. You can add a menu item on the configuration files of each GRUB that will allow you to boot the &quot;opposite&quot; installation, if you want. Or you can just use the BIOS to select the disk to boot from.
The thing you must know that the boot order selector of traditional BIOSes will usually work by making the disk selected for booting the &quot;first&quot; disk for BIOS functions, and so GRUB's <code>hd0</code> will always refer to &quot;the disk that is currently selected for booting in BIOS&quot;.
So, if you are currently booting from <code>/dev/sda</code> (so BIOS says <code>sda</code> is <code>hd0</code>), and you want a GRUB menu item on that disk to switch to <code>/dev/sdb</code>'s boot menu, you'd use something like:
<pre><code>menuentry &quot;Switch to /dev/sdb&quot;
{
 # flip the disk mappings and reload configuration
 drivemap -s (hd0) (hd1)
 set root=&lt;the identifier for sdb's partition that contains grub.cfg&gt;
 configfile /boot/grub/grub.cfg # or just /grub/grub.cfg is /boot is a separate partition
} 
</code></pre>
... and likewise on /dev/sdb's GRUB configuration too.

Some examples found online say that update-grub should be run AFTER grub-install. Others reverse the order. Which is correct?

If I have two Linux installations (one on sda and one on sdb), if I run update-grub on the sda installation, it will place the sda installation at the top of the boot menu. If I run update-grub on the sdb installation, it will place the sdb installation at the top of the menu.

Assuming DEFAULT=0, this should, theoretically, allow me to select my OS by selecting the boot device in the BIOS. Does "grub-install /dev/sda" change the sda boot menu to correspond to the last "update-grub", regardless if it was run from the sda or sdb version of Linux?

update-grub vs. grub-install?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在网上发现的一些例子表明，更新-grub应该在之后运行。其他人则颠倒了秩序。哪个是对的？如果我有两个Linux安装(一个在sda上，一个在sdb上)，如果我在sda安装上运行update，它将把sda安装放在引导菜单的顶部。如果我在sdb安装上运行更新-grub，它将把sdb安装放在菜单的顶部。假设DEFAULT=0，理论上应该允许我通过选择BIOS中的引导设备来选择操作系统。"grub-inst

问更新-grub与grub-安装？
EN

回答 1

Unix & Linux用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问更新-grub与grub-安装？EN