Linux / boot分区的建议大小是多少?


46

Linux /boot分区的建议大小是多少?

没有/boot分区是否安全?

我看到有些服务器没有/boot分区,而有些服务器却有128 MB /boot分区。我有点困惑。是/boot分区的必要吗?如果是,应该多大?

Answers:


40

如今,100 MB或200 MB已成为常态。

您不需要具有/ boot分区。但是,出于灵活性的原因(LVM,加密,BIOS限制)而拥有它是很好的。

编辑:

推荐大小已增加到300MB-500MB。

另请参阅:https : //superuser.com/questions/66015/installing-ubuntu-do-i-really-need-a-boot-parition


3
200 MB是大多数现代Linux上的最小值,但是我将其增加到至少300 MB,以避免重新调整大小。
2015年

@josten我可以在单个btrfs上安装基本OS,而无需进一步/boot分区或发布。不知道为什么要这么说。
2015年

@josten好的,有些甚至更“您可能需要”。感谢您的澄清。
2015年

我希望在安装之前能看到这个答案-安装了具有100MB引导的Debian 8,并意识到几乎一半的引导分区都消失了。
Codism 2015年

@ewwhite这个推荐的尺寸从哪里来?
蒂姆(Tim)2015年

36

我倾向于创建一个1 GB的磁盘/boot。我留下了一个实时CD映像,其中包含各种修复工具/boot。我主要是针对我支持的远程站点上的系统执行此操作。

使用正确的配置和足够的内存,GRUB 2可以启动映像而无需提取内容。我曾几次与远程工作人员交谈过,将系统重新启动到实时CD映像,并在出现问题的系统上启动网络/ ssh,以便我可以连接和维修设备。

这当然不是必需的,甚至不是常见的。


在这种情况下,您更喜欢哪种Live CD?
ewwhite 2011年

1
对我来说,发行版是SystemRescueCD,而Finnix是另一个不错的发行版。
火星人

9
先生,您真棒。
SpacemanSpiff

1
@zoredache我正在出于工作目的在外部硬盘上安装arch linux,我想像您所说的那样添加实时图像,以进行救援,请您指出任何链接该怎么做?
pahnin

3
@pahnin这是我执行此操作的说明:help.ubuntu.com/community/Grub2/ISOBoot(这可能值得一提)
Thaeli 2014年

22

Linux /boot分区的建议大小是多少?

/boot分区包含GRUB配置,带有System.map的内核,...我认为〜100 MB就足够了。

没有/boot分区是否安全?

是。但是,单独的/boot分区具有一些优点:

  • 作为救援分区
  • rootfs位于LVM,RAID上,已加密或不受GRUB支持
  • 也许节省了几秒钟的启动时间

2
最近,我也因为无法访问高于1023(?)气瓶的BIOS感到惊讶。
2011年

2
@quanta如何“可以节省几秒钟的启动时间”
亚历山德罗·佩扎托

2
因为/ boot通常位于磁盘的开头,通常位于外部扇区,因此碎片的机会较小,路径较小(目录读取较少),因此它通常是主分区(无需读取逻辑分区)链)。但我怀疑您获得的收益超过1秒。
Mircea Vutcovici 2011年

8

它也与分发不同。例如,对于Fedora,最小为250 MB [1],默认为500 MB,如果您打算将来进行(预)升级,则需要500 MB [2]。如果空间不成问题,那么我会拨出1 GB的空间以防止稍后重新分配分区,就像最近升级时所做的那样。

[1] http://docs.fedoraproject.org/zh-CN/Fedora/16/html/Installation_Guide/s2-diskpartrecommend-x86.html
[2] http://fedoraproject.org/wiki/How_to_use_PreUpgrade#Not_enough_space_in_.2Fboot


5

我刚刚安装了105 MB的Ubuntu 13.10(Saucy Salamander)/boot。它安装正常,但是重新启动后我做了更新程序,并说没有足够的空间。

它需要大约196 MB的升级空间。它一定是内核升级之类的东西。所以不得不重新安装一个更大的/boot。我花了500 MB,这似乎行得通。不需要花费很长时间进行新安装是一件好事:)


升级后,Ubuntu并不总是删除旧内核。您需要自己做。否则,可能会使其中几个保持很长时间。
马特

我在笔记本电脑上使用默认大小,该大小小于100Mb。结果是,每当我更新时,都需要删除以前的更新,因此我的计算机上始终有两个版本。在我的新笔记本电脑上,我将使/ boot 1Gb。在我的台式机上为500Mb,看起来还可以。
克里斯汀

4

现代系统通常安装有比过去更大的/ boot分区。随着时间的推移,这个数字一直在增长。

考虑:

RHEL 5创建了一个101 MiB / boot分区。

RHEL 5分区

RHEL 6创建了一个500 MiB / boot分区。

RHEL 6分区

RHEL 7还创建了500 MiB / boot分区,但是在7.3中已更改为1024 MiB,因为发行说明指出

在以前的Red Hat Enterprise Linux 7版本中,/ boot分区的默认大小设置为500 MB。这可能导致在具有多个内核和附加软件包(例如,安装的kernel-debuginfo)的系统上出现问题。在这种情况下,/ boot分区可能已满或几乎已满,从而阻止了系统升级,并且需要手动清理以释放更多空间。

在Red Hat Enterprise Linux 7.3中,/ boot分区的默认大小增加到1 GB,并且在新安装的系统上不再出现这些问题。请注意,使用先前版本进行的安装将不会调整其/ boot分区的大小,并且可能仍需要手动清理才能升级。(BZ#1369837)

RHEL 7分区

我当前的EL7系统在/ boot中使用了大约200 MiB,但是我通常不安装内核调试软件包。

随着Linux内核随着时间的推移持续增长(主要是由于添加了硬件设备驱动程序),此建议也可能会继续增长。

同样,正如其他人所指出的那样,大多数安装不再严格要求/ boot分区。例如,VM通常不需要它,UEFI引导系统也不需要它(尽管它们具有EFI系统分区,该分区必须存在并且足够大以容纳各种UEFI文件)。对于一些非常旧的旧系统以及使用LUKS全盘加密,需要/ boot分区。


4

正如我们已经看到的Linux内核存储需求的增加和initrds的不断增加一样,我现在(2018年2月)倾向于为分配1 GB的存储空间/boot

由于/boot通常是不在LVM的唯一的事情,这是你不能轻易调整唯一的分区。因此,“浪费”几百兆字节通常不会像/boot文件系统在5或10年内变得太小那样严重。


3

它主要取决于您安装了多少个内核以及其initrd的大小。

对于3.0系列内核,initrd运行大约13 MB。对于早期的2.6内核,这是3.4 MB。因此,如果计划保留多个内核,则至少需要几百MB。

多少以及是否适用于您取决于您​​的用例。如果您多次引导,测试内核和/或升级,则可能会/boot很快耗尽100 MB 分区上的空间。如果您不执行任何这些操作,那么可能就足够了。

几乎没有理由跳过存储(便宜,BIOS,装载和引导加载程序对块的限制已成过去),而且我看到内核资源会随着时间显着增长,因此,安全的押注将是现在约为250 MB-1 GB。我仍然通常更喜欢使用单独的/ boot分区进行控制和隔离,尽管这几乎已经成为一个问题(RAID设备将是一个明显的例外,LVM和加密以及其他人注意到的)。


1

这也取决于您要拥有多少个内核。一个普通的内核,一个“ xen”内核,一个“桌面”内核以及多个版本确实可以很好地概括。我不会少于500MB。之后,调整前排分区的大小会花费大量时间。

如果您正在创建虚拟机,则如果您不熟悉LVM,则可以为多个分区(/ home,/ boot,/)使用单独的(虚拟)磁盘。


0

构建系统时,通常总是使用100MB。我想如果您要测试大量不同的内核(或构建自己的自定义内核),则可能需要一个更大的内核,但对于大多数人来说100MB就足够了。同样,如前所述,出于多种原因,拥有一个单独的启动分区也是一个好主意。


5
当前发行版需要200MB +。
ewwhite

1
2017年更新:也可能使您的/ boot更像500MB。200MB可以使用,但是存储空间很便宜,并且有一些呼吸空间会很不错。用你的判断。
詹姆斯·T·斯内尔

1
@JamesTSnell btw在经过约3年的更新和新内核后,已在200MB / boot上完成了Ubuntu 16.04安装的磁盘空间用尽-显然,Ubuntu 16.04更新系统不善于清理旧内核。现在/ boot那里有240MB的空间..修复它很麻烦,必须将启动中的所有内容移到其他地方,然后删除启动分区,然后调整根分区的大小,然后重新创建启动分区,然后移回所有内容,然后确保新的引导分区具有引导标志等等
hanshenrik

@hanshenrik-我已经解决了这个问题。您不必调整/ boot的大小,但是这样做可以让您更改再次出现之前经过的时间。这肯定很烦人,我不确定是否有适当的解决方案来管理它自己。
James T Snell
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.