Hi!
I need to use Full Disk Encryption (FDE), but what I've discovered is that if I take the Kernel updates in Update Manager, at some point /boot runs out of space. That can be fixed, but it's a major hassle for new Mint users, IMO.
1) Is there a limitation on /boot size using FDE? Can /boot be enlarged on the fly?
2) If /boot size is fixed, why not simply have Update Manager check /boot size for users before it tries to install via Update Manager, and fail to install if there isn't enough room?
At least if a user sees this error message, they get a hint to remove the other kernels before running out of space (and getting all those errors when trying to update). Thanks!
/boot size and full disk encryption
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
/boot size and full disk encryption
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Re: /boot size and full disk encryption
Please post the output of
...and a screenshot of Gparted looking at your HD...
Thanx!
Code: Select all
inxi -Fxz
Thanx!
Re: /boot size and full disk encryption
Thanks Reorx! I'll try and do that tonight, when I get home for at least my laptop (it happened on my desktop as well).
Re: /boot size and full disk encryption
System: Host: john-ThinkPad-T500 Kernel: 4.13.0-45-generic x86_64 (64 bit gcc: 5.4.0)
Desktop: Xfce 4.12.3 (Gtk 2.24.28) Distro: Linux Mint 18.3 Sylvia
Machine: System: LENOVO (portable) product: 208958U v: ThinkPad T500
Mobo: LENOVO model: 208958U
Bios: LENOVO v: 6FET88WW (3.18 ) date: 03/17/2011
CPU: Dual core Intel Core2 Duo T9400 (-MCP-) cache: 6144 KB
flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx) bmips: 10109
clock speeds: max: 2534 MHz 1: 2211 MHz 2: 2129 MHz
Graphics: Card: Intel Mobile 4 Series Integrated Graphics Controller
bus-ID: 00:02.0
Display Server: X.Org 1.18.4 drivers: (unloaded: fbdev,vesa)
Resolution: 1280x800@60.03hz
GLX Renderer: Mesa DRI Mobile Intel GM45 Express
GLX Version: 2.1 Mesa 17.2.8 Direct Rendering: Yes
Audio: Card Intel 82801I (ICH9 Family) HD Audio Controller
driver: snd_hda_intel bus-ID: 00:1b.0
Sound: Advanced Linux Sound Architecture v: k4.13.0-45-generic
Network: Card-1: Intel 82567LM Gigabit Network Connection
driver: e1000e v: 3.2.6-k port: 1840 bus-ID: 00:19.0
IF: enp0s25 state: down mac: <filter>
Card-2: Intel PRO/Wireless 5100 AGN [Shiloh] Network Connection
driver: iwlwifi bus-ID: 03:00.0
IF: wlp3s0 state: up mac: <filter>
Drives: HDD Total Size: 240.1GB (53.5% used)
ID-1: /dev/sda model: SanDisk_SDSSDA24 size: 240.1GB
Partition: ID-1: / size: 212G used: 112G (56%) fs: ext4 dev: /dev/dm-1
ID-2: /boot size: 472M used: 220M (50%) fs: ext2 dev: /dev/sda1
ID-3: swap-1 size: 8.48GB used: 0.00GB (0%) fs: swap dev: /dev/dm-3
RAID: No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors: System Temperatures: cpu: 49.0C mobo: 40.0C
Fan Speeds (in rpm): cpu: 2959
Info: Processes: 222 Uptime: 3:37 Memory: 1922.5/7871.7MB
Init: systemd runlevel: 5 Gcc sys: 5.4.0
Client: Shell (bash 4.3.481) inxi: 2.2.35
(default install of Mint XFCE 18.3, I let Mint determine the partitions. Below is the snap of Gparted)
Right now, I have 1 active kernel and 2 other installed ones...that's almost 50% of /boot! You can see how if a user just installs the latest kernels from Update manager, how they can fill that easily with 5-6.
Desktop: Xfce 4.12.3 (Gtk 2.24.28) Distro: Linux Mint 18.3 Sylvia
Machine: System: LENOVO (portable) product: 208958U v: ThinkPad T500
Mobo: LENOVO model: 208958U
Bios: LENOVO v: 6FET88WW (3.18 ) date: 03/17/2011
CPU: Dual core Intel Core2 Duo T9400 (-MCP-) cache: 6144 KB
flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx) bmips: 10109
clock speeds: max: 2534 MHz 1: 2211 MHz 2: 2129 MHz
Graphics: Card: Intel Mobile 4 Series Integrated Graphics Controller
bus-ID: 00:02.0
Display Server: X.Org 1.18.4 drivers: (unloaded: fbdev,vesa)
Resolution: 1280x800@60.03hz
GLX Renderer: Mesa DRI Mobile Intel GM45 Express
GLX Version: 2.1 Mesa 17.2.8 Direct Rendering: Yes
Audio: Card Intel 82801I (ICH9 Family) HD Audio Controller
driver: snd_hda_intel bus-ID: 00:1b.0
Sound: Advanced Linux Sound Architecture v: k4.13.0-45-generic
Network: Card-1: Intel 82567LM Gigabit Network Connection
driver: e1000e v: 3.2.6-k port: 1840 bus-ID: 00:19.0
IF: enp0s25 state: down mac: <filter>
Card-2: Intel PRO/Wireless 5100 AGN [Shiloh] Network Connection
driver: iwlwifi bus-ID: 03:00.0
IF: wlp3s0 state: up mac: <filter>
Drives: HDD Total Size: 240.1GB (53.5% used)
ID-1: /dev/sda model: SanDisk_SDSSDA24 size: 240.1GB
Partition: ID-1: / size: 212G used: 112G (56%) fs: ext4 dev: /dev/dm-1
ID-2: /boot size: 472M used: 220M (50%) fs: ext2 dev: /dev/sda1
ID-3: swap-1 size: 8.48GB used: 0.00GB (0%) fs: swap dev: /dev/dm-3
RAID: No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors: System Temperatures: cpu: 49.0C mobo: 40.0C
Fan Speeds (in rpm): cpu: 2959
Info: Processes: 222 Uptime: 3:37 Memory: 1922.5/7871.7MB
Init: systemd runlevel: 5 Gcc sys: 5.4.0
Client: Shell (bash 4.3.481) inxi: 2.2.35
(default install of Mint XFCE 18.3, I let Mint determine the partitions. Below is the snap of Gparted)
Right now, I have 1 active kernel and 2 other installed ones...that's almost 50% of /boot! You can see how if a user just installs the latest kernels from Update manager, how they can fill that easily with 5-6.
Re: /boot size and full disk encryption
Maybe you could use links to the big files which you move somewhere else.
I'm pretty sure you can "expand right" of a boot partition (don't move the beginning [left end] of it; move the "right" end) because the grub install/MBR looks for the beginning of the partition. And before the full-blown disk IO software is running.2) If /boot size is fixed,
Please edit your original post title to include [SOLVED] if/when it is solved!
Your data and OS are backed up....right?
Your data and OS are backed up....right?
Re: /boot size and full disk encryption
Thanks Flemur, those are excellent suggestions!
My concern, though, is for users who haven't been exposed to Linux for a while, and who would find the following intimidating, especially if they are coming from OS's that don't encourage using the terminal/command line. For example, the following link:
https://askubuntu.com/questions/345588/ ... -partition
I never thought that having 6 kernels (5 installed, 1 active) would cause this, and it was a bit of a shock when I ran into the error messages when installing a new kernel that came up in Update Manager. Similar to this:
Unpacking linux-image-4.4.0-72-generic (4.4.0-72.93) ...
dpkg: error processing archive /var/cache/apt/archives/linux-image-4.4.0-72-generic_4.4.0-72.93_amd64.deb (--unpack):
cannot copy extracted data for './boot/vmlinuz-4.4.0-72-generic' to '/boot/vmlinuz-4.4.0-72-generic.dpkg-new': failed to write (No space left on device)
No apport report written because the error message indicates a disk full error
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-72-generic /boot/vmlinuz-4.4.0-72-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-72-generic /boot/vmlinuz-4.4.0-72-generic
Errors were encountered while processing:
/var/cache/apt/archives/linux-image-4.4.0-72-generic_4.4.0-72.93_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
I can't imagine what a Windows user who is just starting out with Mint would think!
I do think there ought to be some sort of script that would warn users that they are running low on disk space in /boot (with the option to abort and remove older kernels not active to open up space), instead of just trying the install and failing. The default /boot partition ought to be much bigger, in any case, considering the rapidity of new (and likely larger) Kernels in Update manager.
My concern, though, is for users who haven't been exposed to Linux for a while, and who would find the following intimidating, especially if they are coming from OS's that don't encourage using the terminal/command line. For example, the following link:
https://askubuntu.com/questions/345588/ ... -partition
I never thought that having 6 kernels (5 installed, 1 active) would cause this, and it was a bit of a shock when I ran into the error messages when installing a new kernel that came up in Update Manager. Similar to this:
Unpacking linux-image-4.4.0-72-generic (4.4.0-72.93) ...
dpkg: error processing archive /var/cache/apt/archives/linux-image-4.4.0-72-generic_4.4.0-72.93_amd64.deb (--unpack):
cannot copy extracted data for './boot/vmlinuz-4.4.0-72-generic' to '/boot/vmlinuz-4.4.0-72-generic.dpkg-new': failed to write (No space left on device)
No apport report written because the error message indicates a disk full error
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-72-generic /boot/vmlinuz-4.4.0-72-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-72-generic /boot/vmlinuz-4.4.0-72-generic
Errors were encountered while processing:
/var/cache/apt/archives/linux-image-4.4.0-72-generic_4.4.0-72.93_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
I can't imagine what a Windows user who is just starting out with Mint would think!
I do think there ought to be some sort of script that would warn users that they are running low on disk space in /boot (with the option to abort and remove older kernels not active to open up space), instead of just trying the install and failing. The default /boot partition ought to be much bigger, in any case, considering the rapidity of new (and likely larger) Kernels in Update manager.
Re: /boot size and full disk encryption
Check this forum for a kernel-cleaning script (edit: because the "size" error keeps coming up), but don't use the forum search, use
Code: Select all
site:forums.linuxmint.com old kernel script
I think people should be discouraged from making a /boot partition unless they have good reasons (which there are, sometimes).The default /boot partition ought to be much bigger, in any case, considering the rapidity of new (and likely larger) Kernels in Update manager
Please edit your original post title to include [SOLVED] if/when it is solved!
Your data and OS are backed up....right?
Your data and OS are backed up....right?
Re: /boot size and full disk encryption
Thanx for posting that requested info. That made replying easier...
OK, it seems that you have this one figured out but here are some additional thoughts from a somewhat experienced Linux Mint user (FWIW).
1) I NEVER update a kernel unless there is a compelling reason to do so. So far, I have never found myself regretting that policy. As a result, I seldom update kernels.
2) I NEVER encrypt partitions without a compelling reason to do so (on a production machine). There are several reasons for this but as you may have noticed, it's no small task to manipulate (change) encrypted partitions without losing data. I have fiddled with encryption on an experimentation machine for "educational" purposes though.
3) I NEVER let the install routine "do its thing" as it almost never does what I would do when creating partitioning architecture. I honestly don't know how your partition structure got to be what it is on that drive but IF I were inclined to do something like that, I would create all of the partitions before ever clicking the install button. During the install, I choose "something else" and manually configure the partitions and mount points. I rarely use a separate /boot partition but the one that I can remember is much larger than it needs to be (2GB - only 110MB is used!) as disk space is cheap and I'd rather err on the side of caution than on the side of headache/heartache/disaster! These days, I typically leave some unallocated disk space between partitions - typically 10 to 50 GB (depending on disk size) - so that in the event of the need to expand a partition in one direction or another, there is some space available. This can save you a fair amount of BS&T in some situations...
As an example, this the the current HD partition architecture on my new laptop that I will be using to install LM19. Right now it is running the 19 Beta and doing reasonably well. I am learning about and playing with some of the new features. This may not be the "final" architecture but it will be some reasonably similar variation on this theme...
In terms of your questions >>>
1) Is there a size limit for /boot? Not that I know of.
2) Can /boot be resized on the fly? Yes and no! You can not manipulate (resize, etc) any partition while it is mounted. But, if you booted the machine to a live USB stick, you would be able to enlarge /boot (to the right) if you had the unallocated space to the right of the partition to do it. Because you can't easily resize (shrink) your encrypted partition, you are pretty much stuck with the current size of your /boot partition.
3) ...why not simply have Update Manager check /boot size?... If the install fails, I wouldn't expect any problems other than using the current active kernel. If the install fails, I would expect some error message to tell you. You could then do whatever you like to remedy the problem... but in the interim, your machine will continue to boot (no harm no fowl).
The take home message is that folks who blindly follow (typically) someone else's recommendations without thinking things thru will likely come to regret at least some of those decisions. That's no great tragedy, that's how we learn some very important lessons in Linux as well as in life.
Best regards and, as always, Enjoy the Mint!
OK, it seems that you have this one figured out but here are some additional thoughts from a somewhat experienced Linux Mint user (FWIW).
1) I NEVER update a kernel unless there is a compelling reason to do so. So far, I have never found myself regretting that policy. As a result, I seldom update kernels.
2) I NEVER encrypt partitions without a compelling reason to do so (on a production machine). There are several reasons for this but as you may have noticed, it's no small task to manipulate (change) encrypted partitions without losing data. I have fiddled with encryption on an experimentation machine for "educational" purposes though.
3) I NEVER let the install routine "do its thing" as it almost never does what I would do when creating partitioning architecture. I honestly don't know how your partition structure got to be what it is on that drive but IF I were inclined to do something like that, I would create all of the partitions before ever clicking the install button. During the install, I choose "something else" and manually configure the partitions and mount points. I rarely use a separate /boot partition but the one that I can remember is much larger than it needs to be (2GB - only 110MB is used!) as disk space is cheap and I'd rather err on the side of caution than on the side of headache/heartache/disaster! These days, I typically leave some unallocated disk space between partitions - typically 10 to 50 GB (depending on disk size) - so that in the event of the need to expand a partition in one direction or another, there is some space available. This can save you a fair amount of BS&T in some situations...
As an example, this the the current HD partition architecture on my new laptop that I will be using to install LM19. Right now it is running the 19 Beta and doing reasonably well. I am learning about and playing with some of the new features. This may not be the "final" architecture but it will be some reasonably similar variation on this theme...
In terms of your questions >>>
1) Is there a size limit for /boot? Not that I know of.
2) Can /boot be resized on the fly? Yes and no! You can not manipulate (resize, etc) any partition while it is mounted. But, if you booted the machine to a live USB stick, you would be able to enlarge /boot (to the right) if you had the unallocated space to the right of the partition to do it. Because you can't easily resize (shrink) your encrypted partition, you are pretty much stuck with the current size of your /boot partition.
3) ...why not simply have Update Manager check /boot size?... If the install fails, I wouldn't expect any problems other than using the current active kernel. If the install fails, I would expect some error message to tell you. You could then do whatever you like to remedy the problem... but in the interim, your machine will continue to boot (no harm no fowl).
The take home message is that folks who blindly follow (typically) someone else's recommendations without thinking things thru will likely come to regret at least some of those decisions. That's no great tragedy, that's how we learn some very important lessons in Linux as well as in life.
Best regards and, as always, Enjoy the Mint!