Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #225795

Re: Enlarging /boot

From Leslie Rhorer <lesrhorer@att.net>
Newsgroups linux.debian.user
Subject Re: Enlarging /boot
Date 2020-08-04 00:20 +0200
Message-ID <AzQYm-cT-37@gated-at.bofh.it> (permalink)
References <AzsVX-25w-1@gated-at.bofh.it> <Azu1I-2Hv-5@gated-at.bofh.it> <AzCiC-7Va-5@gated-at.bofh.it> <AzDol-89-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 8/3/2020 2:49 AM, Andrew Cater wrote:
> If you have room for two kernels and you are booting from the newest 
> one: potentially, you can remove the older one to gain some space. If 
> apt update installs another kernel of the same version so you have two 
> 4.19 - reboot when the apt run finishes, make sure that the new kernel 
> boots and runs fine, then remove the older one. The trick is to check 
> that you are booting from the latest version - you don't want to remove 
> a running kernel :(

	That is not quite accurate.  One the kernel is loaded, it can be moved, 
removed, or updated.  The machine does not care.  If it is no longer 
available where the boot system expects to find it, then it must be 
replaced and if necessary the boot system must be updated t point to the 
new kernel before the machine can boot again using the existing boot 
system.  Generally, the machine can be booted using a different system, 
such as a live CD, for example, even if the existing boot system is broken.

>      > ????????Um, the kernel is only about 5M in size.?? With 133M free, there
>      > should be plenty of room for multiple kernels.?? The initrd image is
>      > usually under 40M, so there should be room for the entire boot
>     image to
>      > be duplicated.?? Note the current use is only 41%.?? You shouldn't need
>      > more space, per se, except that normally the initrd is temporarily
>      > uncompressed while it is being created.?? I think you could get around
>      > this by employing chroot.
> 
>     My initrd is 69 M...

	That is pretty typical.


>      > ????????To answer your question, I am given to understand /boot/efi is a
>      > vfat file system, so it should be possible to shrink it, move the
>     /boot
>      > partition, and then expand it.
> 
>     However both /boot/efi and /boot are critoical for the booting process,
>     thus my concerns.

	Yes, and it is also one reason why I think using chroot to create 
virtual environment on a larger file system and then copying the result 
over to the existing partition might be a better, safer solution for 
someone not well experienced in managing the boot process.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Enlarging /boot Erwan David <erwan@rail.eu.org> - 2020-08-02 22:40 +0200
  Re: Enlarging /boot Leslie Rhorer <lesrhorer@att.net> - 2020-08-02 23:50 +0200
    Re: Enlarging /boot Erwan David <erwan@rail.eu.org> - 2020-08-03 08:40 +0200
      Re: Enlarging /boot Andrew Cater <amacater@gmail.com> - 2020-08-03 09:50 +0200
        Re: Enlarging /boot Leslie Rhorer <lesrhorer@att.net> - 2020-08-04 00:20 +0200
      Re: Enlarging /boot David Wright <deblis@lionunicorn.co.uk> - 2020-08-03 18:30 +0200
  Re: Enlarging /boot Doug McGarrett <dmcgarrett@optonline.net> - 2020-08-02 23:50 +0200
    Re: Enlarging /boot Leslie Rhorer <lesrhorer@att.net> - 2020-08-03 00:00 +0200
  Re: Enlarging /boot David Wright <deblis@lionunicorn.co.uk> - 2020-08-03 05:40 +0200
  Re: Enlarging /boot didier.gaumet@gmail.com - 2020-08-03 10:10 +0200

csiph-web