How to clean up full /boot safely?

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

How to clean up full /boot safely?

Peng Yu
Hi,

I have a full /boot. When I run the following command, I got the
following error. Does anybody know to fix this problem?

$ sudo apt-get -f autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
  linux-image-3.13.0-129-generic
Suggested packages:
  fdutils linux-doc-3.13.0 linux-source-3.13.0 linux-tools
The following packages will be REMOVED:
  linux-headers-3.13.0-116 linux-headers-3.13.0-116-generic
  linux-headers-3.13.0-117 linux-headers-3.13.0-117-generic
  linux-headers-3.13.0-119 linux-headers-3.13.0-119-generic
  linux-headers-3.13.0-121 linux-headers-3.13.0-121-generic
  linux-headers-3.13.0-123 linux-headers-3.13.0-123-generic
  linux-headers-3.13.0-128 linux-headers-3.13.0-128-generic
  linux-image-3.13.0-116-generic linux-image-3.13.0-117-generic
  linux-image-3.13.0-119-generic linux-image-3.13.0-121-generic
  linux-image-3.13.0-123-generic linux-image-3.13.0-128-generic
  linux-image-extra-3.13.0-116-generic linux-image-extra-3.13.0-117-generic
  linux-image-extra-3.13.0-119-generic linux-image-extra-3.13.0-121-generic
  linux-image-extra-3.13.0-123-generic linux-image-extra-3.13.0-128-generic
The following NEW packages will be installed:
  linux-image-3.13.0-129-generic
0 upgraded, 1 newly installed, 24 to remove and 22 not upgraded.
10 not fully installed or removed.
Need to get 0 B/15.5 MB of archives.
After this operation, 1,590 MB disk space will be freed.
Do you want to continue? [Y/n] Y
(Reading database ... 366682 files and directories currently installed.)
Removing linux-image-extra-3.13.0-128-generic (3.13.0-128.177) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal
3.13.0-128-generic /boot/vmlinuz-3.13.0-128-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools
3.13.0-128-generic /boot/vmlinuz-3.13.0-128-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-128-generic

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-3.13.0-128-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-extra-3.13.0-128-generic (--remove):
 subprocess installed post-removal script returned error exit status 1
Removing linux-image-3.13.0-128-generic (3.13.0-128.177) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools
3.13.0-128-generic /boot/vmlinuz-3.13.0-128-generic
update-initramfs: Deleting /boot/initrd.img-3.13.0-128-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub
3.13.0-128-generic /boot/vmlinuz-3.13.0-128-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.13.0-126-generic
Found initrd image: /boot/initrd.img-3.13.0-126-generic
Found linux image: /boot/vmlinuz-3.13.0-125-generic
Found initrd image: /boot/initrd.img-3.13.0-125-generic
Found linux image: /boot/vmlinuz-3.13.0-123-generic
Found initrd image: /boot/initrd.img-3.13.0-123-generic
Found linux image: /boot/vmlinuz-3.13.0-121-generic
Found initrd image: /boot/initrd.img-3.13.0-121-generic
Found linux image: /boot/vmlinuz-3.13.0-119-generic
Found initrd image: /boot/initrd.img-3.13.0-119-generic
Found linux image: /boot/vmlinuz-3.13.0-117-generic
Found initrd image: /boot/initrd.img-3.13.0-117-generic
Found linux image: /boot/vmlinuz-3.13.0-116-generic
Found initrd image: /boot/initrd.img-3.13.0-116-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
done
The link /vmlinuz is a damaged link
Removing symbolic link vmlinuz
 you may need to re-run your boot loader[grub]
Errors were encountered while processing:
 linux-image-extra-3.13.0-128-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)


--
Regards,
Peng

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Colin Watson
On Fri, Feb 09, 2018 at 08:47:20PM -0600, Peng Yu wrote:
> I have a full /boot. When I run the following command, I got the
> following error. Does anybody know to fix this problem?

To make room, you can safely manually remove some of the old files from
packages that are going to be removed anyway.  In your case, I'd go for
this:

  sudo rm -f /boot/initrd.img-3.13.0-{116,117,119,121,123}-generic

(You may want to first check what "uname -r" reports as your running
kernel, and remove that from the list above if necessary.)

This should make enough working space for you to be able to do the
autoremove.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Peter Flynn
On 10/02/18 03:13, Colin Watson wrote:

> On Fri, Feb 09, 2018 at 08:47:20PM -0600, Peng Yu wrote:
>> I have a full /boot. When I run the following command, I got the
>> following error. Does anybody know to fix this problem?
>
> To make room, you can safely manually remove some of the old files from
> packages that are going to be removed anyway.  In your case, I'd go for
> this:
>
>   sudo rm -f /boot/initrd.img-3.13.0-{116,117,119,121,123}-generic
>
> (You may want to first check what "uname -r" reports as your running
> kernel, and remove that from the list above if necessary.)
>
> This should make enough working space for you to be able to do the
> autoremove.

I had this problem a couple of years ago and I found a script that did
the removal a step at a time. Trouble is I can't remember where I found
it, but if you Google deep enough it'll be there.

Memo to self for next installation: partition manually and create a
separate /boot, /home, and /

///Peter

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Ralf Mardorf-5
On Sat, 10 Feb 2018 20:41:05 +0000, Peter Flynn wrote:
>Memo to self for next installation: partition manually and create a
>separate /boot, /home, and /

Actually you would avoid the OP's issue by not seperating /boot from /.
The issue is caused by a seperated /boot partition and an assumed size
that is idiotic, if somebody should need to install many kernels.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Ralf Mardorf-5
On Sat, 10 Feb 2018 21:50:52 +0100, Ralf Mardorf wrote:
>On Sat, 10 Feb 2018 20:41:05 +0000, Peter Flynn wrote:
>>Memo to self for next installation: partition manually and create a
>>separate /boot, /home, and /  
>
>Actually you would avoid the OP's issue by not seperating /boot from /.
>The issue is caused by a seperated /boot partition and an assumed size
          ^usually
>that is idiotic, if somebody should need to install many kernels.

Sure, even / including /boot, could be too small, but usually this
issue is related to a too small separated /boot partition, resp. to
users how don't know how to handle kernel upgrades, since just a
minority needs many installed kernels.

--
$ pacman -Q linux{,-rt-securityink,-rt,-rt-pussytoes,-rt-cornflower}
linux 4.15.2-2
linux-rt-securityink 4.14.18_rt15-1
linux-rt 4.14.12_rt10-1
linux-rt-pussytoes 4.14.8_rt9-2
linux-rt-cornflower 4.11.12_rt16-1


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Colin Law-2
On 10 February 2018 at 20:55, Ralf Mardorf <[hidden email]> wrote:

> On Sat, 10 Feb 2018 21:50:52 +0100, Ralf Mardorf wrote:
>>On Sat, 10 Feb 2018 20:41:05 +0000, Peter Flynn wrote:
>>>Memo to self for next installation: partition manually and create a
>>>separate /boot, /home, and /
>>
>>Actually you would avoid the OP's issue by not seperating /boot from /.
>>The issue is caused by a seperated /boot partition and an assumed size
>           ^usually
>>that is idiotic, if somebody should need to install many kernels.
>
> Sure, even / including /boot, could be too small, but usually this
> issue is related to a too small separated /boot partition, resp. to
> users how don't know how to handle kernel upgrades, since just a
> minority needs many installed kernels.

The problem arises if you have small /boot partition and do not
remember to run apt autoremove occasionally to remove the old ones.

Colin

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Ralf Mardorf-5
On Sat, 10 Feb 2018 21:03:05 +0000, Colin Law wrote:

>On 10 February 2018 at 20:55, Ralf Mardorf <[hidden email]>
>wrote:
>> On Sat, 10 Feb 2018 21:50:52 +0100, Ralf Mardorf wrote:  
>>>On Sat, 10 Feb 2018 20:41:05 +0000, Peter Flynn wrote:  
>>>>Memo to self for next installation: partition manually and create a
>>>>separate /boot, /home, and /  
>>>
>>>Actually you would avoid the OP's issue by not seperating /boot
>>>from /. The issue is caused by a seperated /boot partition and an
>>>assumed size  
>>           ^usually  
>>>that is idiotic, if somebody should need to install many kernels.  
>>
>> Sure, even / including /boot, could be too small, but usually this
>> issue is related to a too small separated /boot partition, resp. to
>> users how don't know how to handle kernel upgrades, since just a
>> minority needs many installed kernels.  
>
>The problem arises if you have small /boot partition and do not
>remember to run apt autoremove occasionally to remove the old ones.

Indeed, but there actually is no plausible reason for GRUB users to
seperate /boot from /. For this majority of users, it makes much more
sense to make /boot part of /, since they would get rid of the need to
estimate potentially needed space for /boot. Actually I'm a syslinux
user, so seperating /boot from / makes much sense, regarding a weekness
of the syslinux bootloader (JFTR off-topic, apart from this weekness,
there are advantages when chosing syslinux over GRUB, but those are
irrelevant for this thread).


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Colin Law-2
On 10 February 2018 at 21:26, Ralf Mardorf <[hidden email]> wrote:

> On Sat, 10 Feb 2018 21:03:05 +0000, Colin Law wrote:
>>On 10 February 2018 at 20:55, Ralf Mardorf <[hidden email]>
>>wrote:
>>> On Sat, 10 Feb 2018 21:50:52 +0100, Ralf Mardorf wrote:
>>>>On Sat, 10 Feb 2018 20:41:05 +0000, Peter Flynn wrote:
>>>>>Memo to self for next installation: partition manually and create a
>>>>>separate /boot, /home, and /
>>>>
>>>>Actually you would avoid the OP's issue by not seperating /boot
>>>>from /. The issue is caused by a seperated /boot partition and an
>>>>assumed size
>>>           ^usually
>>>>that is idiotic, if somebody should need to install many kernels.
>>>
>>> Sure, even / including /boot, could be too small, but usually this
>>> issue is related to a too small separated /boot partition, resp. to
>>> users how don't know how to handle kernel upgrades, since just a
>>> minority needs many installed kernels.
>>
>>The problem arises if you have small /boot partition and do not
>>remember to run apt autoremove occasionally to remove the old ones.
>
> Indeed, but there actually is no plausible reason for GRUB users to
> seperate /boot from /. For this majority of users, it makes much more
> sense to make /boot part of /, since they would get rid of the need to
> estimate potentially needed space for /boot.

Absolutely.

Colin

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Ralf Mardorf-5
In reply to this post by Ralf Mardorf-5
On Sat, 10 Feb 2018 22:26:23 +0100, Ralf Mardorf wrote:

>On Sat, 10 Feb 2018 21:03:05 +0000, Colin Law wrote:
>>On 10 February 2018 at 20:55, Ralf Mardorf <[hidden email]>
>>wrote:  
>>> On Sat, 10 Feb 2018 21:50:52 +0100, Ralf Mardorf wrote:    
>>>>On Sat, 10 Feb 2018 20:41:05 +0000, Peter Flynn wrote:    
>>>>>Memo to self for next installation: partition manually and create a
>>>>>separate /boot, /home, and /    
>>>>
>>>>Actually you would avoid the OP's issue by not seperating /boot
>>>>from /. The issue is caused by a seperated /boot partition and an
>>>>assumed size    
>>>           ^usually    
>>>>that is idiotic, if somebody should need to install many
>>>>kernels.    
>>>
>>> Sure, even / including /boot, could be too small, but usually this
>>> issue is related to a too small separated /boot partition, resp. to
>>> users how don't know how to handle kernel upgrades, since just a
>>> minority needs many installed kernels.    
>>
>>The problem arises if you have small /boot partition and do not
>>remember to run apt autoremove occasionally to remove the old ones.  
>
>Indeed, but there actually is no plausible reason for GRUB users to
>seperate /boot from /. For this majority of users, it makes much more
>sense to make /boot part of /, since they would get rid of the need to
>estimate potentially needed space for /boot. Actually I'm a syslinux
>user, so seperating /boot from / makes much sense, regarding a weekness
>of the syslinux bootloader (JFTR off-topic, apart from this weekness,
>there are advantages when chosing syslinux over GRUB, but those are
>irrelevant for this thread).

PS, before you asked:

[rocketmouse@archlinux ~]$ cat /mnt/moonstudio/etc/fstab
#<file system>                             <mount point>  <type> <options>  <dump pass>
/dev/sdb11                                  /              ext4   rw,relatime       0 1
/dev/sda10                                  none           swap   sw                0 0
/dev/sdb7                                   none           swap   sw                0 0
/dev/sda9                                   /mnt/archlinux ext4   defaults,relatime 0 2
/dev/sdb5                                   /mnt/winos7    ext4   defaults,relatime 0 2
/mnt/archlinux/.boot/ubuntu_moonstudio/boot /boot          none   bind              0 0

If you wouldn't bind the mount point, syslinux would require
chainloading. In this regard and probably a few others, GRUB is better
than syslinux. Anyway, in my experiences GRUB has got a lot of more
pitfalls, than syslinux has got. YMMV!


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Liam Proven
In reply to this post by Ralf Mardorf-5
On 10 February 2018 at 22:26, Ralf Mardorf <[hidden email]> wrote:
>
> Indeed, but there actually is no plausible reason for GRUB users to
> seperate /boot from /.

The main reason _used_ to be that the initial part of the boot process
was done in Real Mode, via BIOS calls, and this could not access some
areas of the hard disk (e.g. cylinders above 1024, or anything above
511MB on C/H/S EIDE controllers -- i.e. pre-EIDE, or any area above
8GB (on pre-UltraATA EIDE controllers).

This could affect GRUB.

Now, it is the a different issue.

The kernel can access anything it likes, once the drivers are loaded
-- but the kernel must be on something GRUB can read, i.e. a
straightforward Linux filesystem.

Things GRUB might have problems with:

* filesystems that are not built into the kernel but run as modules (e.g. ZFS)
* filesystems that spread across multiple disks (e.g. ZFS, LVM, software RAID)
* filesystems which are encrypted

I no longer use /boot on any of my machines, it's true -- but I don't
use RAID or encryption or anything.

However my home server badly needs an upgrade to be useful again. It
has 2GB RAM and a Linux software RAID5 of 4 × 300GB disks, formatted
ext4.

The plan is 8GB of RAM and a Zraid of 4 × 2TB disks using ZFS.

It boots off a non-RAID drive, but that kind of thing is why /boot is
still relevant for some.

--
Liam Proven • Profile: https://about.me/liamproven
Email: [hidden email] • Google Mail/Hangouts/Plus: [hidden email]
witter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Colin Law-2
On 12 February 2018 at 10:00, Liam Proven <[hidden email]> wrote:
> ...
>
> Things GRUB might have problems with:
>
> * filesystems that are not built into the kernel but run as modules (e.g. ZFS)
> * filesystems that spread across multiple disks (e.g. ZFS, LVM, software RAID)
> * filesystems which are encrypted

I believe that later versions of grub will cope with LVM, though I
have not tried it.

The only system that I have a separate boot (and it could do with
being larger) is one that I installed on some time ago using LVM to
give me a large virtual disk. The installer set up a /boot for me and
I am nervous about trying to shrink the LVM partition (if that is the
right word, probably not) in order to grow /boot. I don't want to risk
losing the LVM data as it would be a pain to recover.

Colin

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Colin Watson
In reply to this post by Liam Proven
On Mon, Feb 12, 2018 at 11:00:06AM +0100, Liam Proven wrote:
> On 10 February 2018 at 22:26, Ralf Mardorf <[hidden email]> wrote:
> > Indeed, but there actually is no plausible reason for GRUB users to
> > seperate /boot from /.
>
> The main reason _used_ to be that the initial part of the boot process
> was done in Real Mode, via BIOS calls, and this could not access some
> areas of the hard disk (e.g. cylinders above 1024, or anything above
> 511MB on C/H/S EIDE controllers -- i.e. pre-EIDE, or any area above
> 8GB (on pre-UltraATA EIDE controllers).

There are conceivably some similar kinds of requirements on more recent
systems.  For instance, it's possible to use GPT on most non-UEFI
systems with a bit of luck and a following wind, and thus make use of
disks larger than 2TB; but if you do that then you need to make sure
that /boot is in the bottom 2TB of the disk.

http://www.tldp.org/HOWTO/html_single/Large-Disk-HOWTO/ is mostly of
historical interest these days, but contains descriptions of the various
limits that have been in effect at various times.

> The kernel can access anything it likes, once the drivers are loaded
> -- but the kernel must be on something GRUB can read, i.e. a
> straightforward Linux filesystem.

This was the traditional requirement, but GRUB is quite a bit more
powerful these days and can read more than just straightforward
filesystems.

> Things GRUB might have problems with:
>
> * filesystems that are not built into the kernel but run as modules (e.g. ZFS)
> * filesystems that spread across multiple disks (e.g. ZFS, LVM, software RAID)

All your examples are supported by GRUB.

Of course it's necessary for GRUB to track on-disk format changes, and
the more code you're relying on in the boot loader the more there is to
go wrong, so it's true that there "might" be problems and I can
understand it if people choose to avoid it anyway; but generally
speaking if grub-install manages to work then you're OK.  Things like
LVM are pretty safe these days - the system my email client is running
on has had its /boot on LVM for quite a while now.

(Of course, there might also be problems even with what you might view
as relatively straightforward filesystems.  XFS has had on-disk format
changes in the last few years that GRUB has had to keep up with, for
instance.)

> * filesystems which are encrypted

This is supported by GRUB, although it does mean entering your
encryption passphrase twice.  Depending on your threat model you may or
may not consider this to be worth it.  (It's possible to avoid this
requirement by embedding a keyfile in the initramfs, at the cost of some
administrative effort.)

> However my home server badly needs an upgrade to be useful again. It
> has 2GB RAM and a Linux software RAID5 of 4 × 300GB disks, formatted
> ext4.
>
> The plan is 8GB of RAM and a Zraid of 4 × 2TB disks using ZFS.
>
> It boots off a non-RAID drive, but that kind of thing is why /boot is
> still relevant for some.

In principle all this should be fine with GRUB >= 2.02; just not exactly
the most common configuration.  I would try /boot on ZFS, but be
prepared to fall back to a traditional separate /boot in case of
problems.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Colin Watson
In reply to this post by Colin Law-2
On Mon, Feb 12, 2018 at 10:29:35AM +0000, Colin Law wrote:
> I believe that later versions of grub will cope with LVM, though I
> have not tried it.

Indeed, it works fine.

> The only system that I have a separate boot (and it could do with
> being larger) is one that I installed on some time ago using LVM to
> give me a large virtual disk. The installer set up a /boot for me and
> I am nervous about trying to shrink the LVM partition (if that is the
> right word, probably not) in order to grow /boot. I don't want to risk
> losing the LVM data as it would be a pain to recover.

You should of course have backups first, but I don't think this is
particularly risky as LVM operations go.

If you have enough space in your root filesystem, and a suitable live
USB recovery image to hand, then you can remount /boot in a temporary
location, rsync all its data to /boot on your root filesystem, unmount
/boot and comment it out in /etc/fstab, run grub-install and update-grub
to point GRUB at the new /boot, and reboot.  If all goes well then you
can replace the old /boot partition with a new LVM physical volume
(using pvcreate) and add that to your volume group (using vgextend),
thus making more unallocated space that you can use freely for logical
volumes; if it doesn't go well then you can repair or revert using your
recovery image.

If you wanted to create a separate logical volume and filesystem for
/boot and you didn't have enough unallocated space in your volume group
for that, then it would be a slightly more complicated operation, though
still possible.  However, I don't recommend this.  Having a separate
/boot filesystem is only worth it if your boot loader can't read your
root filesystem for whatever reason; if it can (and why would you be
moving it into LVM otherwise?), then it's just more administrative
overhead.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Liam Proven
In reply to this post by Colin Watson
On 12 February 2018 at 11:53, Colin Watson <[hidden email]> wrote:
>
> There are conceivably some similar kinds of requirements on more recent
> systems.  For instance, it's possible to use GPT on most non-UEFI
> systems with a bit of luck and a following wind, and thus make use of
> disks larger than 2TB; but if you do that then you need to make sure
> that /boot is in the bottom 2TB of the disk.

Good point.

> This was the traditional requirement, but GRUB is quite a bit more
> powerful these days and can read more than just straightforward
> filesystems.
>
>> Things GRUB might have problems with:
                               ^^^^^^

I stress the _might_ part...

> All your examples are supported by GRUB.
>
> Of course it's necessary for GRUB to track on-disk format changes, and
> the more code you're relying on in the boot loader the more there is to
> go wrong, so it's true that there "might" be problems

> Things like
> LVM are pretty safe these days

"Pretty"

> (Of course, there might also be problems even with what you might view

"Might be"

>> * filesystems which are encrypted
>
> This is supported by GRUB, although it does mean entering your
> encryption passphrase twice.

"Although"

> may not consider this to be worth it.  (It's possible to avoid this

"Possible"

> In principle all this should be fine with GRUB >= 2.02;

"Should be"

That's the thing.

I'm a pretty old hand now.

I have 2 slightly different perspectives.

[1]

I was a sysadmin and the like for *decades.*

As such, I just won't tolerate "might" and "should" and "ought to" and
"probably".

I insist on "absolutely will always without fail" except for hardware
failure, major disk corruption etc.

[2]

I'm old and grumpy and lazy and my desktop is a Mac on which I run
macOS {$CURRENT-1 release}

I don't trust Apple not to fsck up the version they are currently
fiddling with. So I run the _superseded_ version which gets a lot
fewer breakages, and if there are breakages, well, they're historical
which means everyone knows and works around them and they are easy to
find on Google.

I want to go to the absolute minimum effort.

That means not "trying" stuff that "should" work on specified recent
versions of stuff or that requires any extra steps from me
_whatsoever_.

I want stuff that just *does* work, on any currently supported version
of any mainstream OS or distro,

Which is what makes me a bit nervous of ZFS itself because only Ubuntu
supports it, other distros eschew it, and it's thus nonstandard. Those
words all set off alarm bells.

But it's in FreeBSD and they are super-conservative. The sort of
greybeard elder geeks I know who regard me as dangerously radical like
and trust ZFS, and I trust them.

> I would try /boot on ZFS, but be
> prepared to fall back to a traditional separate /boot in case of
> problems.

You see, a comment like that makes me think "not a chance in hell". No
way, José. Nope.

No, the box will boot off a separate dedicated non-RAID volume, using
something boring and totally non-experimental like ext4, so if
anything weird happens, it will still come up and I can connect to it
and fix it.

--
Liam Proven • Profile: https://about.me/liamproven
Email: [hidden email] • Google Mail/Hangouts/Plus: [hidden email]
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Ralf Mardorf-5
In reply to this post by Colin Watson
On Mon, 12 Feb 2018 10:53:01 +0000, Colin Watson wrote:
>Of course it's necessary for GRUB to track on-disk format changes, and
>the more code you're relying on in the boot loader the more there is to
>go wrong, so it's true that there "might" be problems and I can
>understand it if people choose to avoid it anyway; but generally
>speaking if grub-install manages to work then you're OK.

+1

We don't need to discuss pros and cons of different bootloaders. We
might find a valid reason to seperate /boot from /, even when using
GRUB 2, but usually GRUB 2 doesn't require a separted /boot partition.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Colin Watson
In reply to this post by Liam Proven
On Mon, Feb 12, 2018 at 01:26:20PM +0100, Liam Proven wrote:

> On 12 February 2018 at 11:53, Colin Watson <[hidden email]> wrote:
> > All your examples are supported by GRUB.
> >
> > Of course it's necessary for GRUB to track on-disk format changes, and
> > the more code you're relying on in the boot loader the more there is to
> > go wrong, so it's true that there "might" be problems
>
> > Things like
> > LVM are pretty safe these days
>
> "Pretty"

OK, at this point (and in most of the rest of it) you're just having a
go at my idiolect.  I tend to stick qualifiers on things out of habit,
and I don't always remember to remove them in a later editing pass.  It
doesn't have much bearing on my actual level of confidence in something.
Sorry about that; I'm a developer, not a technical writer.

One thing I particularly enjoy about developing GRUB (specifically GRUB
2 rather than 0.9x - the latter has some similar ideas but in a much
more primitive form) is that the block device and filesystem access code
is written such that the same code works in userspace as well as in the
boot loader, and it's used by grub-install.  This allows for a high
degree of confidence: if grub-install works, then you know that GRUB
understands the block device and filesystem layout.  And if something
goes wrong, because it's software and it would be naïve to pretend that
it never will, then it can be debugged using grub-fstest using normal
Unix tools rather than the limited environment available at boot time.

> I'm a pretty old hand now.

It's obviously fine to be technically-conservative.  But you made a very
specific claim which went above and beyond merely not wanting to use
more complex facilities:

  "the kernel must be on something GRUB can read, i.e. a straightforward
  Linux filesystem."

I called you on that claim, because it's incorrect; GRUB can read more
than just straightforward Linux filesystems, and has been able to do so
in one form or another for well over a decade.  If you meant "e.g."
rather than "i.e.", then that would be different.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Ralf Mardorf-5
In reply to this post by Liam Proven
On Mon, 12 Feb 2018 13:26:20 +0100, Liam Proven wrote:
>As such, I just won't tolerate "might" and "should" and "ought to" and
>"probably".

In my last reply I used the word "usually", I suspect you forgot to
include it to the above list ;). A power user "perhaps" (another woolly
word) is able to balance pros and cons, for a nocive  "perhaps",
"might", "ought to", "probably", "usually" and similar words shouldn't
be warnings against something that seems to be fishy.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Tom H
In reply to this post by Liam Proven
On Mon, Feb 12, 2018 at 7:26 AM, Liam Proven <[hidden email]> wrote:

Your entire reply to Colin is about parsing his language in a rather
stupidly nit-picking way for the sake of argument rather than for the
sake of furthering understanding and knowledge.

> Which is what makes me a bit nervous of ZFS itself because only Ubuntu
> supports it, other distros eschew it, and it's thus nonstandard. Those
> words all set off alarm bells.

Other distributions have philosophical rather than technical
objections to distributing zfs kernel modules.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Liam Proven
In reply to this post by Colin Watson
On 12 February 2018 at 13:51, Colin Watson <[hidden email]> wrote:
>
> OK, at this point (and in most of the rest of it) you're just having a
> go at my idiolect.

No, I am really not.

I am a native English speaker living in a non-English-speaking country
and I am currently working in my 4th job over here in
non-English-based companies, almost entirely with colleagues who are
not native speakers.

Avoiding ambiguity is a life skill for me.

Also, whereas I cheerfully admit that you've picked me up on errors
plenty of times and it's good that you do it, both for me to learn,
and so that I do not misinform others -- despite that, I am pretty
tech-savvy. I've been a tech pro for 30 years.

So *no*, this is *not* about your language. It is about your message.

Your paranoid assumption that I am attacking your use of language
appears to have blinded you to my actual point.

Which is this stuff is _not guaranteed_. It is _not_ known safe,
absolutely reliable, rock-solid "this will just work if your computer
is functioning".

This is a case of "if nothing is weird and if you've done it the right
way, this stuff _should_ work, probably, and you _ought to be able_ to
do it.

And _that_ is my point.

I am not willing to rely on ought to, should, probably, almost all the
time stuff.

I want "this WILL WORK" without caveats.

If you install GRUB onto the MBR of a smallish disk with a plain MBR
partition with plain filesystem in a Linux-centric filesystem, *it
will work*.

Promise, guarantee.

Yes the hardware might be iffy. The user might have mispartitioned the
disk. They might have forgotten to format it. All sorts of qualifiers,
but if it was done right, it WILL work.

This _cannot_ be said of a software RAID or of a non-Linux filesystem
or of any arbitrary kernel on any arbitrary distro.

If, for instance, my server wouldn't boot and all I had was a Fedora
or Debian boot USB, and /boot and / were on ZFS, I probably could not
read it or fix it.

That is not acceptable to me.

If they are on a simple partition on ext4, *any* distro will let me
fix it, and then boot it, and when it boots, then I can get at the
weird stuff on a striped ZFS filesystem.

And if I can't, if it's a plain ZFS stripe set with no weird bootable
volumes and zero executable files, then I should be able to boot the
dead server off a FreeBSD stick and read that volume.

That's what I demand.

I am not willing to do anything which requires special measures.

I am *not* picking at your English. I am addressing your point: that
"it ought to work" is not good enough for me.

> One thing I particularly enjoy about developing GRUB (specifically GRUB
> 2 rather than 0.9x - the latter has some similar ideas but in a much
> more primitive form)

I am glad you enjoy hacking on it, and I'm glad it exists.

However, TBH, I personally have alway found GRUB arcane and I don't
like it as a tool.

My testbed machine at home uses Powerquest BootMagic as its boot
manager, not GRUB, _because_ I find it arcane and I wanted to avoid
working with it.

> It's obviously fine to be technically-conservative.  But you made a very
> specific claim which went above and beyond merely not wanting to use
> more complex facilities:
>
>   "the kernel must be on something GRUB can read, i.e. a straightforward
>   Linux filesystem."
>
> I called you on that claim, because it's incorrect; GRUB can read more
> than just straightforward Linux filesystems, and has been able to do so
> in one form or another for well over a decade.  If you meant "e.g."
> rather than "i.e.", then that would be different.

I meant "that is".

A Linux kernel software RAID is _not_  a straightforward Linux
filesystem. A ZFS volume set isn't. Anything encrypted or striped or
mirrored isn't.

Even btrfs isn't. I have personally in the last month rendered a
testbed server booting off btrfs unbootable because of something I
did. I don't know what but I couldn't fix it.


--
Liam Proven • Profile: https://about.me/liamproven
Email: [hidden email] • Google Mail/Hangouts/Plus: [hidden email]
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to clean up full /boot safely?

Ralf Mardorf-5
On Mon, 12 Feb 2018 16:08:52 +0100, Liam Proven wrote:
>I am a native English speaker

I'm not, so I need to use a dictionary for my response:
https://www.dict.cc/?s=pathetisch


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
123