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

Groups > linux.debian.user > #233969 > unrolled thread

Boot better have mounted on root or /boot ?

Back to article view | Back to linux.debian.user

Contents

  Boot better have mounted on root or /boot ? Robbi Nespu <robbinespu@gmail.com> - 2021-04-08 03:00 +0200
    Re: Boot better have mounted on root or /boot ? Greg Wooledge <greg@wooledge.org> - 2021-04-08 05:20 +0200
      Re: Boot better have mounted on root or /boot ? Sven Hartge <sven@svenhartge.de> - 2021-04-08 13:30 +0200
    Re: Boot better have mounted on root or /boot ? Stefan Monnier <monnier@iro.umontreal.ca> - 2021-04-08 05:30 +0200
    Re: Boot better have mounted on root or /boot ? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-04-08 08:20 +0200
      Re: Boot better have mounted on root or /boot ? Eike Lantzsch ZP6CGE <zp6cge@gmx.net> - 2021-04-08 13:30 +0200
        Re: Boot better have mounted on root or /boot ? Marco Ippolito <maroloccio@gmail.com> - 2021-04-08 14:40 +0200
          Re: Boot better have mounted on root or /boot ? David Wright <deblis@lionunicorn.co.uk> - 2021-04-11 16:20 +0200
            Re: Boot better have mounted on root or /boot ? Felix Miata <mrmazda@earthlink.net> - 2021-04-11 20:40 +0200
              Re: Boot better have mounted on root or /boot ? David Wright <deblis@lionunicorn.co.uk> - 2021-04-13 17:00 +0200
                Re: Boot better have mounted on root or /boot ? Felix Miata <mrmazda@earthlink.net> - 2021-04-14 01:20 +0200
              Re: Boot better have mounted on root or /boot ? Michael Stone <mstone@debian.org> - 2021-04-16 15:00 +0200
        Re: Boot better have mounted on root or /boot ? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-04-09 08:10 +0200
          Re: Boot better have mounted on root or /boot ? <tomas@tuxteam.de> - 2021-04-09 09:20 +0200
            Re: Boot better have mounted on root or /boot ? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-04-09 20:20 +0200
              Re: Boot better have mounted on root or /boot ? Dan Ritter <dsr@randomstring.org> - 2021-04-09 20:40 +0200
                Re: Boot better have mounted on root or /boot ? <tomas@tuxteam.de> - 2021-04-09 21:10 +0200
              Re: Boot better have mounted on root or /boot ? David Wright <deblis@lionunicorn.co.uk> - 2021-04-11 16:20 +0200

#233969 — Boot better have mounted on root or /boot ?

I use auto partitioning (if not mistaken) and boot mounted on root "/" 
instead of creating own "/boot" partition

$ df -h /boot/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       110G   62G   43G  60% /

What actually the best way for boot directory? put on same root 
directory like I have right now or it better to have it own partition?

I am curious..
-- 
Email : Robbi Nespu <robbinespu AT SPAMFREE gmail DOT com>
PGP fingerprint : D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
PGP key : https://keybase.io/robbinespu/pgp_keys.asc

[toc] | [next] | [standalone]

#233971

On Thu, Apr 08, 2021 at 08:55:47AM +0800, Robbi Nespu wrote:
> $ df -h /boot/
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/sda1       110G   62G   43G  60% /
> 
> What actually the best way for boot directory? put on same root directory
> like I have right now or it better to have it own partition?

The only time you *need* to make it a separate partition is when
you're doing certain flavors of disk encryption.  Under those setups,
you need an unencrypted /boot so you can boot and mount your encrypted
root file system.

[toc] | [prev] | [next] | [standalone]

#233983

Greg Wooledge <greg@wooledge.org> wrote:
> On Thu, Apr 08, 2021 at 08:55:47AM +0800, Robbi Nespu wrote:

>> Filesystem      Size  Used Avail Use% Mounted on
>> /dev/sda1       110G   62G   43G  60% /
>> 
>> What actually the best way for boot directory? put on same root directory
>> like I have right now or it better to have it own partition?

> The only time you *need* to make it a separate partition is when
> you're doing certain flavors of disk encryption.  Under those setups,
> you need an unencrypted /boot so you can boot and mount your encrypted
> root file system.

Not even when doing FDE. GRUB2 is able to decipher LUKSv1 volumes.

But, given that LUKSv1 has been superceded by the newer v2 format, I
would still create a separate /boot, so only it needs to be encrypted
using the potential weaker LUKSv1 format while the rest of the system
can be on a LUKv2 volume.

https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#233972

> I use auto partitioning (if not mistaken) and boot mounted on root "/"
> instead of creating own "/boot" partition
>
> $ df -h /boot/
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/sda1       110G   62G   43G  60% /
>
> What actually the best way for boot directory?

The best way is the one that works.
Apparently your way works, so ...


        Stefan

[toc] | [prev] | [next] | [standalone]

#233977

[Multipart message — attachments visible in raw view] — view raw

On Jo, 08 apr 21, 08:55:47, Robbi Nespu wrote:
> 
> I use auto partitioning (if not mistaken) and boot mounted on root "/"
> instead of creating own "/boot" partition
> 
> $ df -h /boot/
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/sda1       110G   62G   43G  60% /
> 
> What actually the best way for boot directory? put on same root directory
> like I have right now or it better to have it own partition?

The "best" way depends a lot on the criteria used to evaluate.

For me the simplicity of having 'boot' on '/' wins in most cases. It 
avoids a lot of issues (like running out of space in /boot) with no 
significant downside I'm aware of.

I've used a separate boot only when there was no way around it, e.g. the 
original RaspberryPi needs a FAT /boot partition.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#233982

On Donnerstag, 8. April 2021 02:15:00 -04 Andrei POPESCU wrote:
> On Jo, 08 apr 21, 08:55:47, Robbi Nespu wrote:
> > I use auto partitioning (if not mistaken) and boot mounted on root
> > "/" instead of creating own "/boot" partition
> >
> > $ df -h /boot/
> > Filesystem      Size  Used Avail Use% Mounted on
> > /dev/sda1       110G   62G   43G  60% /
> >
> > What actually the best way for boot directory? put on same root
> > directory like I have right now or it better to have it own
> > partition?
> The "best" way depends a lot on the criteria used to evaluate.
>
> For me the simplicity of having 'boot' on '/' wins in most cases. It
> avoids a lot of issues (like running out of space in /boot) with no
> significant downside I'm aware of.
>
> I've used a separate boot only when there was no way around it, e.g.
> the original RaspberryPi needs a FAT /boot partition.
>
> Kind regards,
> Andrei

With my setups it is far more likely that / fills up than /boot so having
a separate /boot partition at least allows me to boot and solve the
problem easily.
On the other hand in this case booting from another disk or USB-stick is
possible but a wee bit more uncomfortable.

As you brought in the case of Raspberries: with today's available disk
space there is no reason to be frugal with /boot space except if one has
to make do with an SD-card or internal NAND memory.

I'd say: if you plan to use your setup for many years without
reinstalling, you are better off with separate partitions with well
planned sizes.
If you reinstall more often (like once or twice a year) put all on one
partition. Should it turn out that you use that computer for many years
without reinstallation but upgrade - upgrade - upgrade and you need more
diskspace for /var or /usr add a disk or two. Caveat: your installation
will become somewhat baroque. Power consumption is another concern.

Eventually it all boils down to one's ability to predict the future or
at least a subset thereof.

Cheers
Eike

[toc] | [prev] | [next] | [standalone]

#233988

> Eventually it all boils down to one's ability to predict the future or
> at least a subset thereof.

What would you consider in your future planning regarding sizing /boot?

e.g. how many kernels (with how many built-in modules and with what
compression) to keep around for alternate booting or reuse elsewhere...

... what else?

[toc] | [prev] | [next] | [standalone]

#234096

On Thu 08 Apr 2021 at 14:37:59 (+0200), Marco Ippolito wrote:
> > Eventually it all boils down to one's ability to predict the future or
> > at least a subset thereof.
> 
> What would you consider in your future planning regarding sizing /boot?

I create ~500MB ESP and /boot partitions on each system disk.
But because I don't encrypt my systems (only /home and swap),
I don't use the "boot" partition for /boot, but as swap instead.

As for the future: in the 1990's I would install the entire system
onto a 1GB disk. It's time I retired my oldest disk (14 years)
which is 500GB. So disk lifetimes can take disks "out of circulation"
before once-generous partition sizes start to look too small.

OTOH I have set up BIOS-booting disks as GPT, with both a BIOS Boot
partition and an ESP, so that they can be converted to UEFI booting
without problem.

> e.g. how many kernels (with how many built-in modules and with what
> compression) to keep around for alternate booting or reuse elsewhere...

If there are kernels etc for use elsewhere, there's no need
to keep them in /boot, is there?

Generally you need room for three sets of the four files:

  old,              current,  just installed,

which then become:

  about to purge,   backup,   current.

> ... what else?

Bear in mind that upgrading grub may generate a new initrd,
and hence a backup of the previous one (depending on
/etc/initramfs-tools/update-initramfs.conf). So currently
$ du -shx /boot/
119M    /boot/
$ 

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#234119

> On Thu 08 Apr 2021 at 14:37:59 (+0200), Marco Ippolito wrote:

>> What would you consider in your future planning regarding sizing /boot?
										
root@asa88:/boot# du -sh .
769M    .
root@asa88:/boot# dpkg -l | grep linux-image-4 | wc -l
10
root@asa88:/boot# dpkg -l | grep linux-image-4
ii  linux-image-4.19.0-1-amd64  4.19.12-1       amd64   Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-10-amd64 4.19.132-1      amd64   Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-12-amd64 4.19.152-1      amd64   Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-14-amd64 4.19.171-2      amd64   Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-2-amd64  4.19.16-1       amd64   Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-4-amd64  4.19.28-2       amd64   Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-5-amd64  4.19.37-5+deb10u2 amd64 Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-6-amd64  4.19.67-2+deb10u2 amd64 Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-8-amd64  4.19.98-1+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-9-amd64  4.19.118-2+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed)

Keep in mind, on average, each kernel release is larger than the last.
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#234150

On Sun 11 Apr 2021 at 14:33:22 (-0400), Felix Miata wrote:
> > On Thu 08 Apr 2021 at 14:37:59 (+0200), Marco Ippolito wrote:
> 
> >> What would you consider in your future planning regarding sizing /boot?
> 
> root@asa88:/boot# du -sh .
> 769M    .
> root@asa88:/boot# dpkg -l | grep linux-image-4 | wc -l
> 10

Perhaps it should be pointed out that it's atypical to maintain such
a large number of individual systems on one machine. ISTR your having
more than a score of root filesystem partitions on one of your disks …

> root@asa88:/boot# dpkg -l | grep linux-image-4
> ii  linux-image-4.19.0-1-amd64  4.19.12-1       amd64   Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-10-amd64 4.19.132-1      amd64   Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-12-amd64 4.19.152-1      amd64   Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-14-amd64 4.19.171-2      amd64   Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-2-amd64  4.19.16-1       amd64   Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-4-amd64  4.19.28-2       amd64   Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-5-amd64  4.19.37-5+deb10u2 amd64 Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-6-amd64  4.19.67-2+deb10u2 amd64 Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-8-amd64  4.19.98-1+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.19.0-9-amd64  4.19.118-2+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed)

… and I suppose that the contents of one of these partitions might
explain why you might still boot, say, a 4.19.12 kernel.

> Keep in mind, on average, each kernel release is larger than the last.

True, both the kernel itself and the amount that gets put into the
initrd. But also bear in mind that:

. if these kernels are all for just one system (which they appear to be),
  several of the older ones could be uninstalled, but the .debs kept for
  later reinstallation if and when required,

. if the kernels were for many different systems on the one machine,
  the System.map/config/initrd.img/vmlinuz ensemble for several of
  them could simply be moved to the day-to-day system's archive,
  and copied back into place as and when required, to boot a
  different, less frequently used system.

I think it's rare indeed to have to choose between ten different
kernels at the drop of a hat when booting up one system. What would
the use case be?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#234153

David Wright composed on 2021-04-13 09:52 (UTC-0500):

> On Sun 11 Apr 2021 at 14:33:22 (-0400), Felix Miata wrote:

>>> On Thu 08 Apr 2021 at 14:37:59 (+0200), Marco Ippolito wrote:

>>>> What would you consider in your future planning regarding sizing /boot?

>> root@asa88:/boot# du -sh .
>> 769M    .
>> root@asa88:/boot# dpkg -l | grep linux-image-4 | wc -l
>> 10

> Perhaps it should be pointed out that it's atypical to maintain such
> a large number of individual systems on one machine. ISTR your having
> more than a score of root filesystem partitions on one of your disks …
										
Only a small number of my "disks" have fewer than 10 total partitions. The only
installed one I can think of with only one / is on an inherited laptop. The vast
majority have more than 10 / filesystems. I have more than one with 40+ total.

I have a working Pentium III with 120G and 80G disks with 55 total between them,
40 / between them, that I just booted Debian 4 Etch on today for the first time in
many moons. It has a separate /boot/ for Etch only, 204MB, with 90% freespace and
3 installed kernels:

# ls -Gg /boot
total 18198
-rw-r--r-- 1  882748 Sep 27  2005 System.map-2.6.12-1-386
-rw-r--r-- 1  720074 Dec  4  2006 System.map-2.6.18-3-686
-rw-r--r-- 1  722037 May 10  2007 System.map-2.6.18-4-686
-rw------- 1     512 Dec 26  2005 backup_mbr
lrwxrwxrwx 1       1 Nov 14  2006 boot -> .
-rw-r--r-- 1   61577 Sep 26  2005 config-2.6.12-1-386
-rw-r--r-- 1   71331 Dec  4  2006 config-2.6.18-3-686
-rw-r--r-- 1   70781 May  9  2007 config-2.6.18-4-686
drwxr-xr-x 2    2048 Dec 14 05:32 grub
lrwxrwxrwx 1      23 Nov 14  2006 initrd.img -> initrd.img-2.6.12-1-386
-rw-r--r-- 1 1449984 Jan 11  2006 initrd.img-2.6.12-1-386
-rw-r--r-- 1 4496652 Dec  9  2006 initrd.img-2.6.18-3-686
-rw-r--r-- 1 4500813 Jun 14  2007 initrd.img-2.6.18-4-686
drwx------ 2   12288 Dec 12  2005 lost+found
-rw-rw-r-- 1  180856 May 13  2011 memtest.420
-rw-r--r-- 1   94356 Feb  2  2005 memtest86.bin
-rw-r--r-- 1  621056 Aug 16  2013 message
-rw-r--r-- 1  621056 Aug 16  2013 message-131m4-tux
-rw-r--r-- 1  128000 Dec 26  2005 message.prv
-rw-r--r-- 1   76803 Feb 12  2015 rdsosreport.txt
lrwxrwxrwx 1      20 Nov 14  2006 vmlinuz -> vmlinuz-2.6.12-1-386
-rw-r--r-- 1 1275119 Sep 27  2005 vmlinuz-2.6.12-1-386
-rw-r--r-- 1 1259920 Dec  4  2006 vmlinuz-2.6.18-3-686
-rw-r--r-- 1 1261213 May 10  2007 vmlinuz-2.6.18-4-686

Known to still be working with at least one OS updated less than a year ago 32 bit
systems number 12 here currently. 64 bit count is 28.

>> root@asa88:/boot# dpkg -l | grep linux-image-4
>> ii  linux-image-4.19.0-1-amd64  4.19.12-1       amd64   Linux 4.19 for 64-bit PCs (signed)
>> ii  linux-image-4.19.0-10-amd64 4.19.132-1      amd64   Linux 4.19 for 64-bit PCs (signed)
>> ii  linux-image-4.19.0-12-amd64 4.19.152-1      amd64   Linux 4.19 for 64-bit PCs (signed)
>> ii  linux-image-4.19.0-14-amd64 4.19.171-2      amd64   Linux 4.19 for 64-bit PCs (signed)
>> ii  linux-image-4.19.0-2-amd64  4.19.16-1       amd64   Linux 4.19 for 64-bit PCs (signed)
>> ii  linux-image-4.19.0-4-amd64  4.19.28-2       amd64   Linux 4.19 for 64-bit PCs (signed)
>> ii  linux-image-4.19.0-5-amd64  4.19.37-5+deb10u2 amd64 Linux 4.19 for 64-bit PCs (signed)
>> ii  linux-image-4.19.0-6-amd64  4.19.67-2+deb10u2 amd64 Linux 4.19 for 64-bit PCs (signed)
>> ii  linux-image-4.19.0-8-amd64  4.19.98-1+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed)
>> ii  linux-image-4.19.0-9-amd64  4.19.118-2+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed)

> … and I suppose that the contents of one of these partitions might
> explain why you might still boot, say, a 4.19.12 kernel.
										
Only one I can think of: the possibility to bisect without having to build a
kernel, or download anything to an out of support release. Essentially, bootable
archives on real hardware.

>> Keep in mind, on average, each kernel release is larger than the last.

> True, both the kernel itself and the amount that gets put into the
> initrd. But also bear in mind that:

> . if these kernels are all for just one system (which they appear to be),
>   several of the older ones could be uninstalled, but the .debs kept for
>   later reinstallation if and when required,

> . if the kernels were for many different systems on the one machine,
>   the System.map/config/initrd.img/vmlinuz ensemble for several of
>   them could simply be moved to the day-to-day system's archive,
>   and copied back into place as and when required, to boot a
>   different, less frequently used system.

> I think it's rare indeed to have to choose between ten different
> kernels at the drop of a hat when booting up one system. What would
> the use case be?										
The example in this thread is probably my only instance of so many Debian kernels
kept installed on one /. Reinstalling at some later time introduces the
possibility of impact from subsequent changes in the construction toolchain.

My sharing here was a simple matter of providing real world data for a calculation
of required space for a separate /boot/ filesystem.

I remember when 75MB was enough for more than two kernels, while now it might not
be enough for one.
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#234214

On Sun, Apr 11, 2021 at 02:33:22PM -0400, Felix Miata wrote:
>> On Thu 08 Apr 2021 at 14:37:59 (+0200), Marco Ippolito wrote:
>
>>> What would you consider in your future planning regarding sizing /boot?
>										
>root@asa88:/boot# du -sh .
>769M    .

You'll find that most of the space in boot is probably taken up by 
initrd images. If you change MODULES in the 
/etc/initramfs-tools/initramfs.conf file to "dep" (and rebuild initrds) 
you'll probably reduce the size of those significantly, by only 
including modules that you actually use. (Note: if you're planning to 
change your hardware you'll probably want an initrd built with "most" 
modules so it will include drivers for hardware you don't have 
installed!) Similarly you'll find that most of the space in the kernel 
packages is in /lib/modules, not /boot.

[toc] | [prev] | [next] | [standalone]

#234006

[Multipart message — attachments visible in raw view] — view raw

On Jo, 08 apr 21, 07:21:04, Eike Lantzsch ZP6CGE wrote:
> On Donnerstag, 8. April 2021 02:15:00 -04 Andrei POPESCU wrote:
> >
> > For me the simplicity of having 'boot' on '/' wins in most cases. It
> > avoids a lot of issues (like running out of space in /boot) with no
> > significant downside I'm aware of.
> 
> With my setups it is far more likely that / fills up than /boot so having
> a separate /boot partition at least allows me to boot and solve the
> problem easily.

Sorry, I just can't imagine a scenario in which some space in /boot can 
help with a full /, except maybe to (ab)use it to move stuff around(?).

> I'd say: if you plan to use your setup for many years without
> reinstalling, you are better off with separate partitions with well
> planned sizes.

[...]
 
> Eventually it all boils down to one's ability to predict the future or
> at least a subset thereof.

Or just don't bother and put "everything"[1] in one partition ;)


[1] "everything" for me usually means the OS, (user) data is a different 
topic.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#234009

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 09, 2021 at 09:07:04AM +0300, Andrei POPESCU wrote:
> On Jo, 08 apr 21, 07:21:04, Eike Lantzsch ZP6CGE wrote:
> > On Donnerstag, 8. April 2021 02:15:00 -04 Andrei POPESCU wrote:
> > >
> > > For me the simplicity of having 'boot' on '/' wins in most cases. It
> > > avoids a lot of issues (like running out of space in /boot) with no
> > > significant downside I'm aware of.
> > 
> > With my setups it is far more likely that / fills up than /boot so having
> > a separate /boot partition at least allows me to boot and solve the
> > problem easily.
> 
> Sorry, I just can't imagine a scenario in which some space in /boot can 
> help with a full /, except maybe to (ab)use it to move stuff around(?).

I think Eike's point of view is "from the other end": / filling up
makes /boot full and thus (possibly) disfunctional, preventing the
next boot.

I'm not sure about a concrete mechanism for that, but it would be
annoying indeed, forcing you to either whip-up a rescue medium.

(Remember: your only computer is currently refusing to boot, and
you lent your last USB stick [1] to that nice friend yesterday evening)
or surgically extracting your harddisk from your flimsy laptop to...
drats, your only computer, etc. you get the idea ;-)

Cheers

[1] which, of course, had a current rescue system, because everyone
   has that :-)

 - t

[toc] | [prev] | [next] | [standalone]

#234053

[Multipart message — attachments visible in raw view] — view raw

On Vi, 09 apr 21, 09:14:31, tomas@tuxteam.de wrote:
> On Fri, Apr 09, 2021 at 09:07:04AM +0300, Andrei POPESCU wrote:
> > On Jo, 08 apr 21, 07:21:04, Eike Lantzsch ZP6CGE wrote:
> > > On Donnerstag, 8. April 2021 02:15:00 -04 Andrei POPESCU wrote:
> > > >
> > > > For me the simplicity of having 'boot' on '/' wins in most cases. It
> > > > avoids a lot of issues (like running out of space in /boot) with no
> > > > significant downside I'm aware of.
> > > 
> > > With my setups it is far more likely that / fills up than /boot so having
> > > a separate /boot partition at least allows me to boot and solve the
> > > problem easily.
> > 
> > Sorry, I just can't imagine a scenario in which some space in /boot can 
> > help with a full /, except maybe to (ab)use it to move stuff around(?).
> 
> I think Eike's point of view is "from the other end": / filling up
> makes /boot full and thus (possibly) disfunctional, preventing the
> next boot.
> 
> I'm not sure about a concrete mechanism for that, but it would be
> annoying indeed, forcing you to either whip-up a rescue medium.

I'm not aware of anything needing to write to /boot during boot.

As far as I know /boot can even stay unmounted (or read-only), except 
for kernel, bootloader, etc. upgrades.

What am I missing?

> (Remember: your only computer is currently refusing to boot, and
> you lent your last USB stick [1] to that nice friend yesterday evening)
> or surgically extracting your harddisk from your flimsy laptop to...
> drats, your only computer, etc. you get the idea ;-)
> 
> Cheers
> 
> [1] which, of course, had a current rescue system, because everyone
>    has that :-)


    apt show grml-rescueboot

(which of course won't help if the boot device is failing, but then you 
have bigger problems anyway)


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#234056

Andrei POPESCU wrote: 
> 
>     apt show grml-rescueboot

Thanks muchly!

-dsr-

[toc] | [prev] | [next] | [standalone]

#234058

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 09, 2021 at 02:37:22PM -0400, Dan Ritter wrote:
> Andrei POPESCU wrote: 
> > 
> >     apt show grml-rescueboot
> 
> Thanks muchly!

Seconded :)

-- t

[toc] | [prev] | [next] | [standalone]

#234097

On Fri 09 Apr 2021 at 21:10:20 (+0300), Andrei POPESCU wrote:
> On Vi, 09 apr 21, 09:14:31, tomas@tuxteam.de wrote:
> > On Fri, Apr 09, 2021 at 09:07:04AM +0300, Andrei POPESCU wrote:
> > > On Jo, 08 apr 21, 07:21:04, Eike Lantzsch ZP6CGE wrote:
> > > > On Donnerstag, 8. April 2021 02:15:00 -04 Andrei POPESCU wrote:
> > > > >
> > > > > For me the simplicity of having 'boot' on '/' wins in most cases. It
> > > > > avoids a lot of issues (like running out of space in /boot) with no
> > > > > significant downside I'm aware of.
> > > > 
> > > > With my setups it is far more likely that / fills up than /boot so having
> > > > a separate /boot partition at least allows me to boot and solve the
> > > > problem easily.
> > > 
> > > Sorry, I just can't imagine a scenario in which some space in /boot can 
> > > help with a full /, except maybe to (ab)use it to move stuff around(?).
> > 
> > I think Eike's point of view is "from the other end": / filling up
> > makes /boot full and thus (possibly) disfunctional, preventing the
> > next boot.
> > 
> > I'm not sure about a concrete mechanism for that, but it would be
> > annoying indeed, forcing you to either whip-up a rescue medium.
> 
> I'm not aware of anything needing to write to /boot during boot.

Technically, grub might write to /boot/grub/grubenv, but the space for
that is pre-allocated, for that very reason..

> As far as I know /boot can even stay unmounted (or read-only), except 
> for kernel, bootloader, etc. upgrades.
> 
> What am I missing?

It might be necessary to know what Eike has in / that causes it to
fill up. /var, /tmp, /home ?

> > (Remember: your only computer is currently refusing to boot, and
> > you lent your last USB stick [1] to that nice friend yesterday evening)
> > or surgically extracting your harddisk from your flimsy laptop to...
> > drats, your only computer, etc. you get the idea ;-)
> > 
> > Cheers
> > 
> > [1] which, of course, had a current rescue system, because everyone
> >    has that :-)
> 
>     apt show grml-rescueboot
> 
> (which of course won't help if the boot device is failing, but then you 
> have bigger problems anyway)

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web