Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sat, May 09, 2020 at 08:05:48PM -0700, Rick Thomas wrote: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ├─sda1 8:10 512M 0 part /boot/efi ├─sda2 8:20 244M 0 part /boot What's the best way to increase the size of /boot ? First, of course, make sure you have a rescue boot method available (live CD or whatever), and up-to-date backups. I would look into swapping /boot and /boot/EFI. But I would also double check what properties the EFI partition needs, besides the files within it (and filesystem, etc.), are there any requirements on the partition type, label, etc., and make sure to set those correctly on sda2 (and unset them on sda1!) At least on my machine the EFI partition is almost unused (check that too for yours, of course!), so swapping them would give you another 256M in /boot, without needing to repartition, reinstall, etc.
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Mon, 11 May 2020 11:21:35 -0500 David Wright wrote: > On Mon 11 May 2020 at 10:27:48 (-0400), Celejar wrote: ... > > Yes. FDE including boot is doable, but it takes more work (and isn't > > necessarily worth it, depending on the threat model - see above): > > I don't encrypt root because it's far too useful to be able to remotely > boot up. To keep things simple, I set up my laptops similarly, except > that unlocking is earlier, in the boot sequence rather than after the > system is fully up. Well, I currently don't encrypt /boot, but since I'm anyway using the iDRAC console to supply the LUKS password, I suppose it wouldn't actually be *that* much more difficult to encrypt the entire disk and boot from virtual media over iDRAC: https://www.dell.com/support/article/en-us/sln296648/using-the-virtual-media-function-on-idrac-6-7-8-and-9 Celejar
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Mon 11 May 2020 at 10:27:48 (-0400), Celejar wrote: > On Mon, 11 May 2020 07:36:27 -0400 Greg Wooledge wrote: > > On Sat, May 09, 2020 at 10:05:40PM -0700, Will Mengarini wrote: > > > * Rick Thomas [20-05/09=Sa 20:05 -0700]: > > > > [...] died for lack of space in /boot [...] > > > > > > Long ago I stopped bothering with a separate /boot, and behold, I yet > > > live. ISTR the Debian installer doesn't default to creating one either. > > > > Unless you're doing some kind(s) of disk encryption. Which apparently is > > a thing that some laptop users go for in a major way. > > And some desktop / server users. I'd rather not have to worry about the > sensitive data on my disks when I decommission them / they fail. I'm surprised that more people aren't concerned about theft, and also their increasing obligations under confidentiality/privacy rules/laws. > > As a non-laptop person, my understanding is that, at least with some > > implementations of disk encryption, you need an UN-encrypted /boot to > > get the whole thing started. After that, the root file system and any > > other local file systems can be encrypted, and the code from /boot will > > be able to prompt you for the passphrase or whatever. > > Yes. FDE including boot is doable, but it takes more work (and isn't > necessarily worth it, depending on the threat model - see above): I don't encrypt root because it's far too useful to be able to remotely boot up. To keep things simple, I set up my laptops similarly, except that unlocking is earlier, in the boot sequence rather than after the system is fully up. > https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html I notice that this page (of 09 Jun 2019) mentions a typical /boot partition of 256MB, and laments not being able to reclaim the space if /boot is merged into the root filesystem. Cheers, David.
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Mon, 11 May 2020 07:36:27 -0400 Greg Wooledge wrote: > On Sat, May 09, 2020 at 10:05:40PM -0700, Will Mengarini wrote: > > * Rick Thomas [20-05/09=Sa 20:05 -0700]: > > > [...] died for lack of space in /boot [...] > > > > Long ago I stopped bothering with a separate /boot, and behold, I yet > > live. ISTR the Debian installer doesn't default to creating one either. > > Unless you're doing some kind(s) of disk encryption. Which apparently is > a thing that some laptop users go for in a major way. And some desktop / server users. I'd rather not have to worry about the sensitive data on my disks when I decommission them / they fail. > As a non-laptop person, my understanding is that, at least with some > implementations of disk encryption, you need an UN-encrypted /boot to > get the whole thing started. After that, the root file system and any > other local file systems can be encrypted, and the code from /boot will > be able to prompt you for the passphrase or whatever. Yes. FDE including boot is doable, but it takes more work (and isn't necessarily worth it, depending on the threat model - see above): https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html Celejar
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Lu, 11 mai 20, 01:09:46, David Christensen wrote: > On 2020-05-10 23:12, Andrei POPESCU wrote: > > On Du, 10 mai 20, 12:30:29, David Christensen wrote: > > > > > > As for using GRML, I have never heard of it. The Debian Installer can get > > > the job done. That said, I have about a half dozen machines and have been > > > feeling the need for installation and deployment automation. I have heard > > > of > > > Puppet more than once. Lucas [1] recommends Ansible [2], so I will > > > probably > > > try that. > > > > Puppet and ansible are for configuration management, you need something > > like FAI for installation. Just discovered vmdb2 which appears to combine nicely with ansible. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sat, May 09, 2020 at 10:05:40PM -0700, Will Mengarini wrote: > * Rick Thomas [20-05/09=Sa 20:05 -0700]: > > [...] died for lack of space in /boot [...] > > Long ago I stopped bothering with a separate /boot, and behold, I yet > live. ISTR the Debian installer doesn't default to creating one either. Unless you're doing some kind(s) of disk encryption. Which apparently is a thing that some laptop users go for in a major way. As a non-laptop person, my understanding is that, at least with some implementations of disk encryption, you need an UN-encrypted /boot to get the whole thing started. After that, the root file system and any other local file systems can be encrypted, and the code from /boot will be able to prompt you for the passphrase or whatever.
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On 2020-05-10 23:12, Andrei POPESCU wrote: On Du, 10 mai 20, 12:30:29, David Christensen wrote: As for using GRML, I have never heard of it. The Debian Installer can get the job done. That said, I have about a half dozen machines and have been feeling the need for installation and deployment automation. I have heard of Puppet more than once. Lucas [1] recommends Ansible [2], so I will probably try that. Puppet and ansible are for configuration management, you need something like FAI for installation. I am not doing "unattended mass deployment of Linux": https://fai-project.org/ Running an installer (or restoring an image), booting the system, and then configuring the system over SSH is already part of my work flow. If Ansible can help me with the last step for Debian, FreeBSD, macOS, Windows, Linode, and potentially other operating systems, I would be happy. But, I am not encouraged by all the RedHat marketing hype. David
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On 2020-05-10 15:53, Rick Thomas wrote: On Sun, May 10, 2020, at 12:30 PM, David Christensen wrote: As for using GRML, I have never heard of it. The Debian Installer can get the job done. GRML [1] says: "Grml is a bootable live system (Live-CD) based on Debian. Grml includes a collection of GNU/Linux software especially for system administrators. Users don't have to install anything on fixed storage. Grml is especially well suited for administrative tasks like installation, deployment and system rescue. Read more..." There's also Debian Live, which also has all the features I'll need to do a full backup, repartition, and restore. The installer in rescue mode is more limited than either of these alternatives. You are right -- I was focusing on the disk partitioning and Debian installation steps. The d-i rescue shell has a limited set of tools for general system administration chores. For "everything else", I install Debian onto a USB flash drive and then add my favorite packages, hosts file, profile, scripts, libraries, etc.. This gives me the control and flexibility of a complete Debian system, and I don't have to climb yet another learning curve. David
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Du, 10 mai 20, 12:30:29, David Christensen wrote: > > As for using GRML, I have never heard of it. The Debian Installer can get > the job done. That said, I have about a half dozen machines and have been > feeling the need for installation and deployment automation. I have heard of > Puppet more than once. Lucas [1] recommends Ansible [2], so I will probably > try that. Puppet and ansible are for configuration management, you need something like FAI for installation. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Du, 10 mai 20, 04:03:29, Rick Thomas wrote: > On Sun, May 10, 2020, at 3:22 AM, Andrei POPESCU wrote: > > On Du, 10 mai 20, 02:02:45, Rick Thomas wrote: > > > So... Here's another question: > > > > > > Why is the default size of /boot, as created by the installer, so > > > small? Disk (even SSD) is cheap enough these days that the default > > > size could be as much as a GB without great pain. > > > > > > Has this been thought about by the PTBs? Was there a discussion of > > > possibly raising the default? Maybe I missed it... > > > > A quick search in the BTS reveals #893886 and #951709 (both fixed in > > git). > > Thanks for the pointers, Andrei! Do you think those changes will get > into Bullseye before it's released? Yes. It should be available soon in the daily and weekly images. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
Old ways die hard, disk space is cheap! these days On 10/5/20 1:53 pm, The Wanderer wrote: On 2020-05-09 at 23:36, Andy Smith wrote: Hi Rick, On Sat, May 09, 2020 at 08:05:48PM -0700, Rick Thomas wrote: What's the best way to increase the size of /boot ? There is no easy way. If you boot into a live/rescue environment and run parted you *may* be able to shrink your LVM and grow your /boot but it's a procedure fraught with danger; make sure you have excellent backups first. I am not 100% sure that parted can handle partitions that are used as LVM PVs. I can easily create a gig or so of space by a shrink/resize of /home, but how do I add that space to /dev/sda2 ? This won't work because your /home is an LVM logical volume. Its actual extents could be all over sda3. I can't just move up the end of /dev/sda2 = start of /dev/sda3 without backing up and restoring, can I? parted can move partitions about, so if you run it from outside your install and it does support LVM PV then it might work. You'd basically have to shift everything up the disk, making your PV (sda3) slightly smaller in the process. I really wouldn't like to try it myself. With the backup that you'll need you may as well just reinstall as even if parted can do this it will take some time for it to rewrite all that data. In theory I *think* it should be possible to shrink /home, shrink the LV, shrink the PV, then expand /boot - but the practice may be quite different from the theory. https://unix.stackexchange.com/questions/479545/how-to-shrink-a-physical-volume has detailed instructions on how to do one part of the process, and indicates that gparted can indeed handle LVM PVs - but whether it's suitable for the actual scenario at hand here probably depends on how you've got your PVs and LVs set up, and I don't know enough about that to make a recommendation, aside from being very careful with backups no matter what. (I'm also up late, so don't necessarily trust me to have things right at the moment; double-check before going ahead, and if in doubt, don't.) This is a great example of why it's not good to be stingy with the size of /boot. Definitely. My current system started out with around 4-8 TB of usable space (across all partitions, after RAID overhead) when I first built it, and I have fully 22GB allocated to /boot. That's ridiculous overkill - even 1GB would probably have been more than I'm likely to ever need here, and 2GB would definitely have - but I'd far rather have erred on the side of too much than too little. And yet your 22GB hasn't cracked the $1 mark on a cost effective drive. -- All that glitters has a high refractive index.
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On 11/5/20 8:53 am, Rick Thomas wrote: On Sun, May 10, 2020, at 12:30 PM, David Christensen wrote: As for using GRML, I have never heard of it. The Debian Installer can get the job done. GRML [1] says: "Grml is a bootable live system (Live-CD) based on Debian. Grml includes a collection of GNU/Linux software especially for system administrators. Users don't have to install anything on fixed storage. Grml is especially well suited for administrative tasks like installation, deployment and system rescue. Read more..." There's also Debian Live, which also has all the features I'll need to do a full backup, repartition, and restore. The installer in rescue mode is more limited than either of these alternatives. Buy a cheap SSD and put boot and root on that. A WD green 120GB cost $39 AUD. Rick [1] http://grml.org -- Nuclear weapons can wipe out life on Earth, if used properly
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On 5/10/20 03:07, Rick Thomas wrote: > On Sun, May 10, 2020, at 1:17 AM, David Christensen wrote: >> On 2020-05-09 22:05, Will Mengarini wrote: >>> * Rick Thomas [20-05/09=Sa 20:05 -0700]: What's the best way to increase the size of /boot? >>> By creating a reliable backup and reformatting the disk to >>> the new format. I've never found it to be cost-effective >>> to try anything else. >> +1 As Charles Curley suggested, 248M usually is enough to hold a reasonable number of kernels, configs, and initrd files, along with the contents of /boot/grub. It might be worthwhile to examine it for extraneous files. But if /boot turns out to need more space, you could unmount /dev/sda1 and /dev/sda2, remount /dev/sda2 on (for example) /mnt, move its contents to /boot, remount /dev/sda1, and reinstall grub. After finishing, you could make an LVM physical volume on /dev/sda2 and add it to one of the other volume groups, although both seem to have plenty of space. Regards Tom Dial > > Yeah, that's probably what I'll do. Fortunately, it's an amd64 machine, so > I'll be able to use GRML to do the work. > Enjoy! > Rick >
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sun, May 10, 2020, at 12:30 PM, David Christensen wrote: > As for using GRML, I have never heard of it. The Debian Installer can > get the job done. GRML [1] says: "Grml is a bootable live system (Live-CD) based on Debian. Grml includes a collection of GNU/Linux software especially for system administrators. Users don't have to install anything on fixed storage. Grml is especially well suited for administrative tasks like installation, deployment and system rescue. Read more..." There's also Debian Live, which also has all the features I'll need to do a full backup, repartition, and restore. The installer in rescue mode is more limited than either of these alternatives. Rick [1] http://grml.org
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On 2020-05-10 02:07, Rick Thomas wrote: On Sun, May 10, 2020, at 1:17 AM, David Christensen wrote: On 2020-05-09 22:05, Will Mengarini wrote: * Rick Thomas [20-05/09=Sa 20:05 -0700]: What's the best way to increase the size of /boot? By creating a reliable backup and reformatting the disk to the new format. I've never found it to be cost-effective to try anything else. +1 Yeah, that's probably what I'll do. Fortunately, it's an amd64 machine, so I'll be able to use GRML to do the work. I advise that you put your operating system on one drive and your data on other drives (e.g. RAID file server), and that you keep your system drive image small enough to fit on a "16 GB" device -- HDD, SSD, USB flash drive, SD card, etc.. As for using GRML, I have never heard of it. The Debian Installer can get the job done. That said, I have about a half dozen machines and have been feeling the need for installation and deployment automation. I have heard of Puppet more than once. Lucas [1] recommends Ansible [2], so I will probably try that. David [1] https://mwl.io/ [2] https://www.ansible.com/
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sun 10 May 2020 at 16:30:56 (+0200), Sven Hartge wrote: > David Wright wrote: > > > If the answer is many, you could shrink some of them by rebuilding > > their initrd.img files with MODULES=dep, which could reduce each > > kernel's size from ~40M to <10M. > > While this will reduce this initrd size, you should also mention the > consequences of doing this: > > It only includes the modules update-initramfs thinks are needed to boot > the system. > > But this also results in two important consequences: > > 1) You lose portability of the system. By only including the modules >needed to boot in the current hardware this may limit your ability to >boot the system on different hardware. > > 2) MODULES=dep is a codepath less tested. In my experience this can lead >to modules missing which are needed for successful boot, resulting in >a failed or incomplete boot. That's why I wrote "some". We have no idea what this machine/disk is used for, nor how many kernels is considered reasonable. But with ~240M available, we're in the realm of compromise. The suggestion has already been made to backup (then presumably remove) some kernels. Copying the initrd.img files before rebuilding as dep is even easier. Were a disaster to befall, the OP has already mentioned having GRML available. Gigs of space is available in the df listing presented. So expanding /boot just doesn't seem urgent enough to be done at five in the morning. Cheers, David.
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
David Wright wrote: > If the answer is many, you could shrink some of them by rebuilding > their initrd.img files with MODULES=dep, which could reduce each > kernel's size from ~40M to <10M. While this will reduce this initrd size, you should also mention the consequences of doing this: It only includes the modules update-initramfs thinks are needed to boot the system. But this also results in two important consequences: 1) You lose portability of the system. By only including the modules needed to boot in the current hardware this may limit your ability to boot the system on different hardware. 2) MODULES=dep is a codepath less tested. In my experience this can lead to modules missing which are needed for successful boot, resulting in a failed or incomplete boot. Grüße, Sven -- Sigmentation fault. Core dumped.
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sat 09 May 2020 at 20:05:48 (-0700), Rick Thomas wrote: > I recently did a "apt update ; apt upgrade" and it died for lack of space in > /boot when trying to install the latest kernel. > > I purged a couple of old kernel packages (still present in the 'stable' repo, > so they weren't obsolete) to make enough space and tried again. Worked this > time, but I would have liked to have the old kernels around as fallbacks just > in case of a regression... > > Here's the disk layout: > > rbthomas@milli:~$ lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:00 111.8G 0 disk > ├─sda1 8:10 512M 0 part /boot/efi > ├─sda2 8:20 244M 0 part /boot > └─sda3 8:30 111.1G 0 part > ├─debian--vg-root 253:0028G 0 lvm / > ├─debian--vg-swap_1 253:10 7.9G 0 lvm [SWAP] > └─debian--vg-home 253:20 75.2G 0 lvm /home > sdb 8:16 1 239G 0 disk > └─sdb1 8:17 1 239G 0 part /media/rbthomas/Spare > mmcblk0 179:00 238.3G 0 disk > └─mmcblk0p1 179:10 238.3G 0 part /media/rbthomas/Downloads > rbthomas@milli:~$ > > rbthomas@milli:~$ df -HTP | grep -v tmpfs > Filesystem Type Size Used Avail Use% Mounted on > /dev/mapper/debian--vg-root ext4 30G 9.9G 19G 36% / > /dev/sda2 ext2 248M 78M 158M 34% /boot > /dev/sda1 vfat 536M 144k 536M 1% /boot/efi > /dev/mapper/debian--vg-home ext4 79G 4.4G 71G 6% /home > /dev/sdb1 ext4 252G 63M 239G 1% > /media/rbthomas/Spare > /dev/mmcblk0p1 ext4 251G 63M 238G 1% > /media/rbthomas/Downloads > rbthomas@milli:~$ > > > What's the best way to increase the size of /boot ? > > I can easily create a gig or so of space by a shrink/resize of /home, but how > do I add that space to /dev/sda2 ? > > I can't just move up the end of /dev/sda2 = start of /dev/sda3 without > backing up and restoring, can I? Apparently you have at least two kernels in under 80M, so one wonders how many you need to have available for booting at any one moment. If the answer is many, you could shrink some of them by rebuilding their initrd.img files with MODULES=dep, which could reduce each kernel's size from ~40M to <10M. 75G for /home is pretty small (the only disk I have that small is a 2004 laptop) so I'd look for an opportunity to repartition in the near to mid-term. (Is this one that you've converted to sysv, for example, or is it encrypted—excuses like that.) All of which assumes that you actually need a separate /boot … … and that you didn't repartition it already, before dawn. Cheers, David.
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sunday, May 10, 2020 05:07:24 AM Rick Thomas wrote: > > > * Rick Thomas [20-05/09=Sa 20:05 -0700]: > > >> What's the best way to increase the size of /boot? > Yeah, that's probably what I'll do. Fortunately, it's an amd64 machine, so > I'll be able to use GRML to do the work. Enjoy! Another option: it looks like there is room in your ~240 MB /boot for two kernels -- why not back up older kernels to somewhere else (somewhere in /home, /, or an external device and just keep the current and the previous kernel in /boot. Then on your next fresh install, make a bigger /boot... (or just leave it in / (particularly as I'm not sure of the implications of needing /usr during boot)).
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sun, May 10, 2020, at 3:22 AM, Andrei POPESCU wrote: > On Du, 10 mai 20, 02:02:45, Rick Thomas wrote: > > So... Here's another question: > > > > Why is the default size of /boot, as created by the installer, so > > small? Disk (even SSD) is cheap enough these days that the default > > size could be as much as a GB without great pain. > > > > Has this been thought about by the PTBs? Was there a discussion of > > possibly raising the default? Maybe I missed it... > > A quick search in the BTS reveals #893886 and #951709 (both fixed in > git). Thanks for the pointers, Andrei! Do you think those changes will get into Bullseye before it's released? Rick
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Du, 10 mai 20, 02:02:45, Rick Thomas wrote: > So... Here's another question: > > Why is the default size of /boot, as created by the installer, so > small? Disk (even SSD) is cheap enough these days that the default > size could be as much as a GB without great pain. > > Has this been thought about by the PTBs? Was there a discussion of > possibly raising the default? Maybe I missed it... A quick search in the BTS reveals #893886 and #951709 (both fixed in git). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sun, May 10, 2020, at 1:17 AM, David Christensen wrote: > On 2020-05-09 22:05, Will Mengarini wrote: > > * Rick Thomas [20-05/09=Sa 20:05 -0700]: > >> What's the best way to increase the size of /boot? > > By creating a reliable backup and reformatting the disk to > > the new format. I've never found it to be cost-effective > > to try anything else. > +1 Yeah, that's probably what I'll do. Fortunately, it's an amd64 machine, so I'll be able to use GRML to do the work. Enjoy! Rick
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
So... Here's another question: Why is the default size of /boot, as created by the installer, so small? Disk (even SSD) is cheap enough these days that the default size could be as much as a GB without great pain. Has this been thought about by the PTBs? Was there a discussion of possibly raising the default? Maybe I missed it... Stay safe and stay healthy! Rick
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
* Rick Thomas [20-05/09=Sa 20:05 -0700]: > [...] died for lack of space in /boot [...] Long ago I stopped bothering with a separate /boot, and behold, I yet live. ISTR the Debian installer doesn't default to creating one either. If you really want a bastion filesystem for booting, I suggest it be / (say 8G), because that'll also give you /bin, /lib, /etc, etc, without which you can't troubleshoot system horkage anyway. Then you can put /home and /usr on the beta release of FunkyFS and have fun. I'd also put /tmp on the same partition as /home, because when I want to rm $junk I typically do it with mv -t/tmp $junk for safety, which on the same filesystem just edits directory entries, but on a different one actually copies $junk, meh. Make sure your bastion filesystem has enough room for /var/spool; shouldn't be a problem unless you're one of those people who likes 30G mailboxes, or are running a news server. Stay safe, back up your files, and wash your hands. > rbthomas@milli:~$ lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:00 111.8G 0 disk > +-sda1 8:10 512M 0 part /boot/efi > +-sda2 8:20 244M 0 part /boot > +-sda3 8:30 111.1G 0 part > +-debian--vg-root 253:0028G 0 lvm / > +-debian--vg-swap_1 253:10 7.9G 0 lvm [SWAP] > +-debian--vg-home 253:20 75.2G 0 lvm /home > sdb 8:16 1 239G 0 disk > +-sdb1 8:17 1 239G 0 part /media/rbthomas/Spare > mmcblk0 179:00 238.3G 0 disk > +-mmcblk0p1 179:10 238.3G 0 part /media/rbthomas/Downloads > rbthomas@milli:~$ > > rbthomas@milli:~$ df -HTP | grep -v tmpfs > Filesystem Type Size Used Avail Use% Mounted on > /dev/mapper/debian--vg-root ext4 30G 9.9G 19G 36% / > /dev/sda2 ext2 248M 78M 158M 34% /boot > /dev/sda1 vfat 536M 144k 536M 1% /boot/efi > /dev/mapper/debian--vg-home ext4 79G 4.4G 71G 6% /home > /dev/sdb1 ext4 252G 63M 239G 1% /media/rbthomas/Spare > /dev/mmcblk0p1 ext4 251G 63M 238G 1% > /media/rbthomas/Downloads > rbthomas@milli:~$ > > What's the best way to increase the size of /boot? By creating a reliable backup and reformatting the disk to the new format. I've never found it to be cost-effective to try anything else. I don't even upgrade to new releases anymore; I just nuke everything and do a fresh install. > I can easily create a gig or so of space by a shrink/resize > of /home, but how do I add that space to /dev/sda2? > > I can't just move up the end of /dev/sda2 = start of > /dev/sda3 without backing up and restoring, can I? > > Any suggestions would be appreciated. Consider the time you've spent posing this question, waiting for the answers, and reading them. Dump and reload might've finished already. -- Will Mengarini Free software: the Source will be with you, always. This will be a memorable month -- no matter how hard you try to forget it. --Unix fortune cookie
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On 2020-05-09 22:05, Will Mengarini wrote: * Rick Thomas [20-05/09=Sa 20:05 -0700]: What's the best way to increase the size of /boot? By creating a reliable backup and reformatting the disk to the new format. I've never found it to be cost-effective to try anything else. +1 I don't even upgrade to new releases anymore; I just nuke everything and do a fresh install. +1 David
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
> Consider the time you've spent posing this question, waiting for the > answers, and reading them. Dump and reload might've finished already. True, but I wouldn't have learned half so much and wouldn't have had a third so much had so much fun learning it! Stay safe!
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sat, May 9, 2020, at 9:10 PM, Charles Curley wrote: > On Sat, 09 May 2020 20:05:48 -0700 > "Rick Thomas" wrote: > > > Filesystem Type Size Used Avail Use% Mounted on > > /dev/mapper/debian--vg-root ext4 30G 9.9G 19G 36% / > > /dev/sda2 ext2 248M 78M 158M 34% /boot > > Odd. That should be good for more than three kernels. I have: > > root@jhegaala:~# df /boot/ > Filesystem Size Used Avail Use% Mounted on > /dev/sda5 226M 92M 119M 44% /boot > root@jhegaala:~# > > with three kernels. > > My /boot is ext4, but I doubt that makes enough difference to matter. > My installation is not EFI. Would that make the difference? The figures above are *after* I deleted the two previous kernel versions. So yes, there's plenty of space there when this is taken. It looks like each kernel/initrd combo takes 75-80 MB so three of them could take as much as 240 MB, just a bit beyond the space available. Stay well and stay safe! Rick
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sb, 09 mai 20, 22:05:40, Will Mengarini wrote: > * Rick Thomas [20-05/09=Sa 20:05 -0700]: > > [...] died for lack of space in /boot [...] > > Long ago I stopped bothering with a separate /boot, and behold, I yet > live. ISTR the Debian installer doesn't default to creating one > either. Agreed. > If you really want a bastion filesystem for booting, I suggest it be / > (say 8G), because that'll also give you /bin, /lib, /etc, etc, without > which you can't troubleshoot system horkage anyway. Then you can > put /home and /usr on the beta release of FunkyFS and have fun. Booting without /usr is not supported anymore and with usrmerge most of the stuff from / was moved to /usr anyway. Unless you want to keep /usr read-only (except for package upgrades) and/or share it between systems there is no real need to have it on a separate partition. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On Sat, 09 May 2020 20:05:48 -0700 "Rick Thomas" wrote: > Filesystem Type Size Used Avail Use% Mounted on > /dev/mapper/debian--vg-root ext4 30G 9.9G 19G 36% / > /dev/sda2 ext2 248M 78M 158M 34% /boot Odd. That should be good for more than three kernels. I have: root@jhegaala:~# df /boot/ Filesystem Size Used Avail Use% Mounted on /dev/sda5 226M 92M 119M 44% /boot root@jhegaala:~# with three kernels. My /boot is ext4, but I doubt that makes enough difference to matter. My installation is not EFI. Would that make the difference? -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
On 2020-05-09 at 23:36, Andy Smith wrote: > Hi Rick, > > On Sat, May 09, 2020 at 08:05:48PM -0700, Rick Thomas wrote: >> What's the best way to increase the size of /boot ? > > There is no easy way. If you boot into a live/rescue environment and > run parted you *may* be able to shrink your LVM and grow your /boot > but it's a procedure fraught with danger; make sure you have > excellent backups first. > > I am not 100% sure that parted can handle partitions that are used as > LVM PVs. > >> I can easily create a gig or so of space by a shrink/resize of >> /home, but how do I add that space to /dev/sda2 ? > > This won't work because your /home is an LVM logical volume. Its > actual extents could be all over sda3. > >> I can't just move up the end of /dev/sda2 = start of /dev/sda3 >> without backing up and restoring, can I? > > parted can move partitions about, so if you run it from outside your > install and it does support LVM PV then it might work. You'd > basically have to shift everything up the disk, making your PV (sda3) > slightly smaller in the process. > > I really wouldn't like to try it myself. With the backup that you'll > need you may as well just reinstall as even if parted can do this it > will take some time for it to rewrite all that data. In theory I *think* it should be possible to shrink /home, shrink the LV, shrink the PV, then expand /boot - but the practice may be quite different from the theory. https://unix.stackexchange.com/questions/479545/how-to-shrink-a-physical-volume has detailed instructions on how to do one part of the process, and indicates that gparted can indeed handle LVM PVs - but whether it's suitable for the actual scenario at hand here probably depends on how you've got your PVs and LVs set up, and I don't know enough about that to make a recommendation, aside from being very careful with backups no matter what. (I'm also up late, so don't necessarily trust me to have things right at the moment; double-check before going ahead, and if in doubt, don't.) > This is a great example of why it's not good to be stingy with the > size of /boot. Definitely. My current system started out with around 4-8 TB of usable space (across all partitions, after RAID overhead) when I first built it, and I have fully 22GB allocated to /boot. That's ridiculous overkill - even 1GB would probably have been more than I'm likely to ever need here, and 2GB would definitely have - but I'd far rather have erred on the side of too much than too little. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
Another thought that is maybe a little outside the box: If your BIOS supports booting from USB or media slot then you could maybe make a new boot partition on one of those devices and switch to booting from that from now on. Ties up a USB or media slot forever of course, but possibly an acceptable compromise. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
Hi Rick, On Sat, May 09, 2020 at 08:05:48PM -0700, Rick Thomas wrote: > What's the best way to increase the size of /boot ? There is no easy way. If you boot into a live/rescue environment and run parted you *may* be able to shrink your LVM and grow your /boot but it's a procedure fraught with danger; make sure you have excellent backups first. I am not 100% sure that parted can handle partitions that are used as LVM PVs. > I can easily create a gig or so of space by a shrink/resize of /home, but how > do I add that space to /dev/sda2 ? This won't work because your /home is an LVM logical volume. Its actual extents could be all over sda3. > I can't just move up the end of /dev/sda2 = start of /dev/sda3 without > backing up and restoring, can I? parted can move partitions about, so if you run it from outside your install and it does support LVM PV then it might work. You'd basically have to shift everything up the disk, making your PV (sda3) slightly smaller in the process. I really wouldn't like to try it myself. With the backup that you'll need you may as well just reinstall as even if parted can do this it will take some time for it to rewrite all that data. This is a great example of why it's not good to be stingy with the size of /boot. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Hmmm... /boot is too small. what's the best way to increase it's size?
I recently did a "apt update ; apt upgrade" and it died for lack of space in /boot when trying to install the latest kernel. I purged a couple of old kernel packages (still present in the 'stable' repo, so they weren't obsolete) to make enough space and tried again. Worked this time, but I would have liked to have the old kernels around as fallbacks just in case of a regression... Here's the disk layout: rbthomas@milli:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 111.8G 0 disk ├─sda1 8:10 512M 0 part /boot/efi ├─sda2 8:20 244M 0 part /boot └─sda3 8:30 111.1G 0 part ├─debian--vg-root 253:0028G 0 lvm / ├─debian--vg-swap_1 253:10 7.9G 0 lvm [SWAP] └─debian--vg-home 253:20 75.2G 0 lvm /home sdb 8:16 1 239G 0 disk └─sdb1 8:17 1 239G 0 part /media/rbthomas/Spare mmcblk0 179:00 238.3G 0 disk └─mmcblk0p1 179:10 238.3G 0 part /media/rbthomas/Downloads rbthomas@milli:~$ rbthomas@milli:~$ df -HTP | grep -v tmpfs Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/debian--vg-root ext4 30G 9.9G 19G 36% / /dev/sda2 ext2 248M 78M 158M 34% /boot /dev/sda1 vfat 536M 144k 536M 1% /boot/efi /dev/mapper/debian--vg-home ext4 79G 4.4G 71G 6% /home /dev/sdb1 ext4 252G 63M 239G 1% /media/rbthomas/Spare /dev/mmcblk0p1 ext4 251G 63M 238G 1% /media/rbthomas/Downloads rbthomas@milli:~$ What's the best way to increase the size of /boot ? I can easily create a gig or so of space by a shrink/resize of /home, but how do I add that space to /dev/sda2 ? I can't just move up the end of /dev/sda2 = start of /dev/sda3 without backing up and restoring, can I? Any suggestions would be appreciated. Rick
