DevHeads.net

How to clean up full /boot safely?

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)

Comments

Re: How to clean up full /boot safely?

By Colin Watson at 02/09/2018 - 23:13

On Fri, Feb 09, 2018 at 08:47:20PM -0600, Peng Yu wrote:
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.

Re: How to clean up full /boot safely?

By silver.bullet at 02/12/2018 - 14:12

It's a bashism. Perhaps the OP's login shell is dash ;).

Re: How to clean up full /boot safely?

By Peter Flynn at 02/10/2018 - 16:41

On 10/02/18 03:13, Colin Watson wrote:
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

Re: How to clean up full /boot safely?

By silver.bullet at 02/10/2018 - 16:50

On Sat, 10 Feb 2018 20:41:05 +0000, Peter Flynn wrote:
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.

Re: How to clean up full /boot safely?

By silver.bullet at 02/10/2018 - 16:55

On Sat, 10 Feb 2018 21:50:52 +0100, Ralf Mardorf wrote:
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.

Re: How to clean up full /boot safely?

By Colin Law at 02/10/2018 - 17:03

On 10 February 2018 at 20:55, Ralf Mardorf <silver. ... at zoho dot com> wrote:
The problem arises if you have small /boot partition and do not
remember to run apt autoremove occasionally to remove the old ones.

Colin

Re: How to clean up full /boot safely?

By silver.bullet at 02/10/2018 - 17:26

On Sat, 10 Feb 2018 21:03:05 +0000, Colin Law wrote:
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).

Re: How to clean up full /boot safely?

By Liam Proven at 02/12/2018 - 06:00

On 10 February 2018 at 22:26, Ralf Mardorf <silver. ... at zoho dot com> wrote:
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.

Re: How to clean up full /boot safely?

By Colin Watson at 02/12/2018 - 06:53

On Mon, Feb 12, 2018 at 11:00:06AM +0100, Liam Proven 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.

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

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

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.)

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.)

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.

Re: How to clean up full /boot safely?

By silver.bullet at 02/12/2018 - 08:42

On Mon, 12 Feb 2018 10:53:01 +0000, Colin Watson wrote:
+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.

Re: How to clean up full /boot safely?

By Liam Proven at 02/12/2018 - 08:26

On 12 February 2018 at 11:53, Colin Watson < ... at ubuntu dot com> wrote:
Good point.

I stress the _might_ part...

"Pretty"

"Might be"

"Although"

"Possible"

"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.

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.

Re: How to clean up full /boot safely?

By Tom H at 02/12/2018 - 09:14

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.

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

Re: How to clean up full /boot safely?

By Liam Proven at 02/12/2018 - 11:19

On 12 February 2018 at 14:14, Tom H < ... at gmail dot com> wrote:
No, it isn't.

"Why" does not matter to me. "Will it absolutely definitely just work
in a crisis" matters. If the answer is "no" then "why" is of no
interest to me. The reasons may be perfectly good ones involving
non-GPL code in a GPL kernel but they are irrelevant.

"If I boot this machine off a known good current Linux bootable DVD or
USB medium, will it read all my disks? Yes or no."

"Well it depends on what dist--"

"Yes or no."

"Only if it is--"

"Yes or no."

"But..."

"YES OR NO."

"No."

Then I won't use it.

Why it won't work is not important in this discussion. I don't care.

I understand the reasons, they are valid, they are important, but they
are not relevant to this. If the answer to "will it work?" is not an
unqualified, unhesitating "yes" with zero riders or caveats, then my
answer is "no".

Comparison:

A few years ago, I wanted to move my personal website to a CMS.

All the main Linux CMSs are based on PHP.

I have some free webspace due to a kind friend. He is older and far
techier than me. He will not allow PHP on any machine he administers
or supports.

This meant that, at that time, there was no Free CMS for Linux I could
put on the machine.

It is a simple, absolute rule of his. PHP is a bad language. PHP is
unsafe. You _cannot_ write a known good, completely safe PHP app,
because PHP is not known good. It is known bad. It is unspecified,
badly-written, poorly-implemented and insecure.

So he said no.

I was a bit annoyed. I researched PHP. I learned why. He is right.

I do not run internet-facing webservers for a living.

I have, however, built significant corporate infrastructures that
supported hundreds of millions of US dollars' worth of business, every
day, with very high uptimes.

There was, back then, production stuff I would not allow on my
systems. Even if most of the rest of the industry used it.

My friend has the same attitude. If he knows it is untrustworthy, it
doesn't go on his boxes. Not in a VM, not in a container, not in a
special version, it does not go on, at all, ever.

And he is right to do this.

My attitude to things like filesystems is similar.

"This should work" is a 100% total no.

If someone says "X ought to work" then that means that they can
conceive of scenarios where it won't work. That is enough. No.

Re: How to clean up full /boot safely?

By Colin Watson at 02/12/2018 - 13:16

On Mon, Feb 12, 2018 at 04:19:24PM +0100, Liam Proven wrote:
To be clear: I don't object to any of this. You do you, and in very
many environments this approach is entirely appropriate. But if you
claim that something flat-out doesn't work when it does - even if there
are caveats - then I'll still point out the error.

Put another way: there is a difference between "here is our recommended
configuration; if you deviate from this then you're on your own" and
"other configurations will not work", and clear technical writing
distinguishes between the two.

Re: How to clean up full /boot safely?

By Liam Proven at 02/12/2018 - 13:57

My words were:

"Things GRUB might have problems with"

As I have emphasised before: *MIGHT*

Let me clarify with an example.

/ is on /dev/md1, which is a mirrored pair of drives, /dev/sda and /dev/sdb

(I have zero clue what the GRUB nomenclature is, which is the sort of
reason I don't like it. hd(0,0) and hd(1,0) or something, who knows?

Root is on a mirror. The /etc/grub directory is therefore on both, as
is /boot and the kernel.

GRUB, to the best of my knowledge, supports this just fine. So does
the kernel. It's not LVM, it's not GPT, it's nothing very fancy.

Must GRUB be installed to /dev/md1? I don't think that would boot
because that's a Linux kernel device, only visible when the kernel is
running.

So where is the boot sector? Is it on /dev/sda or /dev/sdb?

Is it on both?

Can it be on both?

If it is on both, and /dev/sda fails, if the firmware is configured so
that the secondary boot device is /dev/sdb, will GRUB automatically
failover and boot off /dev/sdb? If so, will it bring the kernel up
normally with a degraded RAID pair?

Is it possible to give a definite canonical answer to this, without
referring to firmware versions, BIOS restrictions, motherboard
support, etc?

I don't think it is. I could be wrong, of course.

GRUB supports this scenario, I believe. As far as what GRUB supports,
this is not problematic. It is clear cut and the answer is yes, it
works.

But the scenario in reality is significantly more complicated, as I
have explained. It is difficult to say what will happen in absolute
terms. It needs specific knowledge of the machine, the firmware and
more.

So *I* would say the answer here is at best "it might work".

And as I have explained, "it might work" is not good enough for me and
for many real life situations, so the answer in _reality_ is therefore
"no, do not do this", because although _yes_ GRUB supports it, it is
_not possible_ to say that yes this will work in all scenarios on all
hardware.

What it _is_ possible to say is:

Use a separate, non-mirrored /boot volume on a single drive. Have
arrangements to replace this if needed, have spares, have backups, but
if you need to _know_ it _will_ work, put /boot on a single unmirrored
hard disk and then _and only then_ is it possible to say "this will
work and it will boot your machine".

I have been shouted at and told off for saying "this _MIGHT_ not work"
because GRUB supports it. It doesn't matter if GRUB supports it. The
question is more complicated.

And the question here was, why use a /boot partition these days?

I have given an answer and I stand by it.

Am I wrong? Considering the additional factors I have outlined, am I wrong?

Re: How to clean up full /boot safely?

By Tom H at 02/12/2018 - 15:31

It's "(mduuid/the_array_uuid_which_is_not_the_fs_uuid)" in "grub.cfg"
and when you run "set" in the grub shell. But it's "(md/1)" when you
run "ls" in the grub shell.

[ BTW, it's "(hd0,msdos1)" - or "(hd0,gpt1)" - not "hd(0,0)". It used
to be - and can probably still be - "(hd0,0)". ]

You install to the component disks.

<BEGIN>
# findmnt -n /
/ /dev/md0 ext4 rw,relatime,data=ordered

# grub-probe -t drive -d /dev/md0
(mduuid/ed094b5258f2ddc765f884cd13f62c44)

[ I can't find a way to output "(md/0)" using grub-probe. ]

# grub-install /dev/md0
Installing for i386-pc platform.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible. GRUB can only be
installed in this setup by using blocklists. However, blocklists are
UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

# grub-install /dev/sdb
Installing for i386-pc platform.
Installation finished. No error reported.

#
</END>

AFAIR, Ubuntu's d-i installs to both and Debian's d-i installed to sda
but Debian's d-i now installs to both.

Yes.

Yes.

Yes because it doesn't matter. Unless both sda and sdb are broken.

Re: How to clean up full /boot safely?

By Liam Proven at 02/12/2018 - 16:35

Once again:

Yes you can configure a particular machine, or a particular detailed
spec, where this will work.

But I own machines where there is a single boot hard disk setting in
the BIOS and if that drive fails it is not possible to specify a
failover device.

It is _not_ possible to make a blanket statement "do this and this will work".

There are hardware setups where it won't. You are not considering that case.

Which is why I said _might_.

There are setups where it _might_ not work, and that kind of thing is
why people like me write manuals which carefully say "this might work
but don't rely on it", and why some people use /boot filesystems even
today, which is the point of this thread.

Re: How to clean up full /boot safely?

By Colin Watson at 02/12/2018 - 17:41

On Mon, Feb 12, 2018 at 09:35:30PM +0100, Liam Proven wrote:
Whoa. Back up. The end of your question, the one that Tom and I were
both replying to, was:

If it is on both, and /dev/sda fails, if the firmware is configured so
that the secondary boot device is /dev/sdb, will GRUB automatically
failover and boot off /dev/sdb? If so, will it bring the kernel up
normally with a degraded RAID pair?

Is it possible to give a definite canonical answer to this, without
referring to firmware versions, BIOS restrictions, motherboard
support, etc?

Here, "if the firmware is configured so that the secondary boot device
is /dev/sdb" implies that it's possible to do so on the firmware in
question. Now you're moving the goalposts: suddenly, the firmware
cannot be configured in that way, and you're criticising us for not
considering the case that you specifically excluded from consideration.
I don't know about Tom, but I would certainly have given a different
answer if you hadn't *specifically ruled out that case* in your
question.

Bad form.

I certainly wouldn't argue that a separate /boot is always wrong. (Ralf
said something along those lines, I think.) I do think that it causes a
different class of problems, some of which prove to be difficult in
their own way for users to deal with, and so it's worth trying to avoid
them in more situations than has traditionally been the case. Perhaps I
have a different set of biases due to having spent more time dealing
with that class of problem than you have; I don't know. But this is
just a difference in degree, not in kind.

And I don't think either of us know whether the original poster in this
thread has a complicated system where a separate /boot is worthwhile
(even if not strictly required), or a simple one where it's really just
unnecessary complexity ...

Re: How to clean up full /boot safely?

By silver.bullet at 02/12/2018 - 21:43

On Mon, 12 Feb 2018 21:41:33 +0000, Colin Watson wrote:
Btw. <a href="https://packages.ubuntu.com/xenial/syslinuxis" title="https://packages.ubuntu.com/xenial/syslinuxis">https://packages.ubuntu.com/xenial/syslinuxis</a> is in main, it's not
"just in universe". Again, syslinux suffers from a weakness neither
GRUB legacy, nor GRUB 2 suffers from. When using syslinux for a
multi-boot Linux only machine you need to bind /boot or you need to
chainload. When using GRUB you do not need to care about this.

Re: How to clean up full /boot safely?

By Tom H at 02/14/2018 - 16:02

On Mon, Feb 12, 2018 at 8:43 PM, Ralf Mardorf <silver. ... at zoho dot com> wrote:
Nitpick: "/boot" isn't bind-mounted in a dual-boot situation because a
bind-mount implies that both distributions/installs are running.

You don't have to mount "/boot" in order to run Linux.

For example, I have a VM in which a 17.10 install with a separate
"/boot" filesystem dual-boots with a Gentoo install. "/boot" only has
Ubuntu files on it and isn't mounted by the Gentoo install (it saves
my having to compile a kernel) and they have the same ip address and
share out the same filesystem via nfs, whichever one's running.

My grub.cfg is below. The only difference between the Ubuntu and
Gentoo entries is the "root=UUID=" value. The same must be possible
with extlinux.

$ cat /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/90-grub ###
# menu
set default=0
set timeout=2

# kernel
insmod gzio

# disk/partition
insmod part_msdos

# filesystem
insmod ext2

# /boot
search --no-floppy --fs-uuid --set=root c6c45a21-9b93-4575-aa11-2011da070d4d

# video
terminal_input console
terminal_output console

menuentry 'Ubuntu' {
linux /kernel root=UUID=5d16e6e7-19d3-4cc1-ad06-394a4d343fcf ro
consoleblank=0
initrd /ramfs
}

menuentry 'Gentoo' {
linux /kernel root=UUID=6ab1adaa-7d34-4494-9226-98e12af5763f ro
consoleblank=0
initrd /ramfs
}

### END /etc/grub.d/90-grub ###

Re: How to clean up full /boot safely?

By silver.bullet at 02/14/2018 - 21:26

On Wed, 14 Feb 2018 15:02:50 -0500, Tom H wrote:
Wrong, to bind doesn't require that both Linux are running, see the
fstab part of [1].

I don't know, perhaps it's not required, I'm to lazy to read how
initramfs exactly is used, but at least for kernel upgrades syslinux
requires the bind or a sync/copy workaround. What syslinux at least is
unable to do, would be to boot Ubuntu from one UUID and Gentoo from
another UUID, the kernel has to be on the same partition
as /boot/syslinux/, if you don't want to use chainloading,
while /boot/grub/ could be on one partition and the kernels could be on
other partitions, IOW there is no need to use chainloading. "The
factual accuracy of this article or section is disputed":
<a href="https://wiki.archlinux.org/index.php/syslinux#Chainloading_other_Linux_systems" title="https://wiki.archlinux.org/index.php/syslinux#Chainloading_other_Linux_systems">https://wiki.archlinux.org/index.php/syslinux#Chainloading_other_Linux_s...</a>
I don't know if EXTLINUX requires to bind /boot, when not using it for
chainloading, I'm again to lazy for research.

[1]
[rocketmouse@archlinux ~]$ cat /boot/syslinux/syslinux.cfg
# <a href="http://syslinux.zytor.com/wiki/index.php/Doc/menu" title="http://syslinux.zytor.com/wiki/index.php/Doc/menu">http://syslinux.zytor.com/wiki/index.php/Doc/menu</a>

PROMPT 0
TIMEOUT 600
UI menu.c32
MENU HIDDEN
MENU CLEAR
MENU COLOR screen 0;30;40
MENU COLOR border 0;30;40
MENU COLOR title 1;37;44
MENU COLOR unsel 0;37;40
MENU COLOR hotkey 1;37;40
MENU COLOR hotsel 7;37;40
MENU COLOR sel 7;37;40
MENU COLOR disabled 1;37;40
MENU COLOR scrollbar 0;30;40
MENU COLOR tabmsg 0;30;40
MENU COLOR cmdmark 0;31;40
MENU COLOR cmdline 0;37;40
MENU COLOR timeout_msg 0;37;40
MENU COLOR timeout 1;37;40

# Used hotkeys: ^8 ^A ^C ^e ^H ^i ^k ^M ^n ^P ^Q ^R ^S ^t ^V
DEFAULT Securityink

MENU TITLE HAL 9000
LABEL Toolbox
MENU LABEL Toolbox
MENU DISABLE
MENU SEPARATOR

LABEL Hardware
MENU LABEL ^Hardware Detection
COM32 hdt.c32

LABEL Memtest
MENU LABEL Memtest^86+
LINUX /.boot/ubuntu_moonstudio/boot/memtest86+.bin

LABEL Reset
MENU LABEL R^eset
COM32 reboot.c32

MENU SEPARATOR
MENU SEPARATOR
LABEL Arch Menu
MENU LABEL Arch Linux
MENU DISABLE
MENU SEPARATOR

LABEL Threadirqs
MENU LABEL Arch Linux ^threadirqs
LINUX ../vmlinuz-linux
APPEND root=LABEL=archlinux ro threadirqs
INITRD ../intel-ucode.img,../initramfs-linux.img

LABEL Threadirqs_nopti
MENU LABEL Arch Linux threadirqs ^nopti
LINUX ../vmlinuz-linux
APPEND root=LABEL=archlinux ro threadirqs nopti
INITRD ../intel-ucode.img,../initramfs-linux.img

LABEL Securityink
MENU LABEL Arch Linux Rt ^Securityink
LINUX ../vmlinuz-linux-rt-securityink
APPEND root=LABEL=archlinux ro
INITRD ../intel-ucode.img,../initramfs-linux-rt-securityink.img

# <a href="https://lists.archlinux.org/pipermail/arch-proaudio/2018-February/000078.html" title="https://lists.archlinux.org/pipermail/arch-proaudio/2018-February/000078.html">https://lists.archlinux.org/pipermail/arch-proaudio/2018-February/000078...</a>
LABEL Securityink_nopti
MENU LABEL Arch Linux Rt Securityink nopt^i
LINUX ../vmlinuz-linux-rt-securityink
APPEND root=LABEL=archlinux ro nopti
INITRD ../intel-ucode.img,../initramfs-linux-rt-securityink.img

LABEL Pussytoes
MENU LABEL Arch Linux Rt ^Pussytoes
LINUX ../vmlinuz-linux-rt-pussytoes
APPEND root=LABEL=archlinux ro
INITRD ../intel-ucode.img,../initramfs-linux-rt-pussytoes.img

LABEL Cornflower
MENU LABEL Arch Linux Rt ^Cornflower
LINUX ../vmlinuz-linux-rt-cornflower
APPEND root=LABEL=archlinux ro
INITRD ../intel-ucode.img,../initramfs-linux-rt-cornflower.img

LABEL Rt
MENU LABEL Arch Linux ^Rt
LINUX ../vmlinuz-linux-rt
APPEND root=LABEL=archlinux ro
INITRD ../intel-ucode.img,../initramfs-linux-rt.img

LABEL Arch
MENU LABEL ^Arch Linux
LINUX ../vmlinuz-linux
APPEND root=LABEL=archlinux ro
INITRD ../intel-ucode.img,../initramfs-linux.img

MENU SEPARATOR
MENU SEPARATOR
LABEL Other Menu
MENU LABEL Other Linux
MENU DISABLE
MENU SEPARATOR

LABEL Moonstudio
MENU LABEL Ubuntu X ^Moon Studio lowlatency
LINUX /.boot/ubuntu_moonstudio/boot/vmlinuz-lowlatency
APPEND root=LABEL=moonstudio ro
INITRD /.boot/ubuntu_moonstudio/boot/initrd.img-lowlatency

LABEL Nokaiser
MENU LABEL Ubuntu X Moon Studio lowlatency no^kaiser
LINUX /.boot/ubuntu_moonstudio/boot/vmlinuz-lowlatency
APPEND root=LABEL=moonstudio ro nokaiser
INITRD /.boot/ubuntu_moonstudio/boot/initrd.img-lowlatency

LABEL Light
MENU LABEL Ubuntu ^Q LightScribe Rt
LINUX /.boot/ubuntu_q/boot/vmlinuz-3.6.5-rt14
APPEND root=LABEL=q ro nomodeset
INITRD /.boot/ubuntu_q/boot/initrd.img-3.6.5-rt14

LABEL Suse
MENU LABEL ^Vintage SUSE 11.2 Rt
LINUX /.boot/suse11.2/boot/vmlinuz-2.6.31.6-rt19
APPEND root=LABEL=suse11.2
INITRD /.boot/suse11.2/boot/initrd-2.6.31.6-rt19
[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
[rocketmouse@archlinux ~]$ ls -hAl /mnt/moonstudio/boot/
total 0
[rocketmouse@archlinux ~]$ ls -hAl /boot/
total 214M
-rw-r--r-- 1 root root 29M Feb 14 09:12 initramfs-linux-fallback.img
-rw-r--r-- 1 root root 11M Feb 14 09:12 initramfs-linux.img
-rw-r--r-- 1 root root 26M Feb 14 09:05 initramfs-linux-rt-cornflower-fallback.img
-rw-r--r-- 1 root root 9.7M Feb 14 09:04 initramfs-linux-rt-cornflower.img
-rw-r--r-- 1 root root 29M Feb 14 09:05 initramfs-linux-rt-fallback.img
-rw-r--r-- 1 root root 10M Feb 14 09:05 initramfs-linux-rt.img
-rw-r--r-- 1 root root 29M Feb 14 09:05 initramfs-linux-rt-pussytoes-fallback.img
-rw-r--r-- 1 root root 10M Feb 14 09:05 initramfs-linux-rt-pussytoes.img
-rw-r--r-- 1 root root 29M Feb 14 09:05 initramfs-linux-rt-securityink-fallback.img
-rw-r--r-- 1 root root 10M Feb 14 09:05 initramfs-linux-rt-securityink.img
-rw-r--r-- 1 root root 1.6M Jan 10 09:53 intel-ucode.img
drwxr-xr-x 2 root root 4.0K Feb 10 18:47 syslinux
-rw-r--r-- 1 root root 5.0M Feb 13 00:23 vmlinuz-linux
-rw-r--r-- 1 root root 4.6M Jan 11 21:53 vmlinuz-linux-rt
-rw-r--r-- 1 root root 5.1M Oct 18 07:00 vmlinuz-linux-rt-cornflower
-rw-r--r-- 1 root root 4.6M Dec 25 21:01 vmlinuz-linux-rt-pussytoes
-rw-r--r-- 1 root root 4.6M Feb 10 09:55 vmlinuz-linux-rt-securityink
[rocketmouse@archlinux ~]$ ls -hAl /.boot/
total 12K
drwxr-xr-x 3 root root 4.0K Feb 16 2017 suse11.2
drwxr-xr-x 3 root root 4.0K Jan 23 08:57 ubuntu_moonstudio
drwxr-xr-x 3 root root 4.0K Feb 16 2017 ubuntu_q
[rocketmouse@archlinux ~]$ ls -hAl /.boot/ubuntu_moonstudio/
total 4.0K
drwxr-xr-x 3 root root 4.0K Feb 6 07:02 boot
[rocketmouse@archlinux ~]$ ls -hAl /.boot/ubuntu_moonstudio/boot/
total 46M
-rw-r--r-- 1 root root 1.2M Jan 19 14:42 abi-4.4.0-112-lowlatency
-rw-r--r-- 1 root root 186K Jan 19 14:42 config-4.4.0-112-lowlatency
drwxr-xr-x 5 root root 4.0K Feb 6 06:39 grub
-rw-r--r-- 1 root root 34M Feb 6 07:02 initrd.img-4.4.0-112-lowlatency
lrwxrwxrwx 1 root root 31 Jan 23 08:56 initrd.img-lowlatency -> initrd.img-4.4.0-112-lowlatency
-rw-r--r-- 1 root root 179K Jan 28 2016 memtest86+.bin
-rw-r--r-- 1 root root 181K Jan 28 2016 memtest86+.elf
-rw-r--r-- 1 root root 181K Jan 28 2016 memtest86+_multiboot.bin
-rw------- 1 root root 3.8M Jan 19 14:42 System.map-4.4.0-112-lowlatency
-rw------- 1 root root 6.9M Jan 19 14:42 vmlinuz-4.4.0-112-lowlatency
lrwxrwxrwx 1 root root 28 Jan 23 08:56 vmlinuz-lowlatency -> vmlinuz-4.4.0-112-lowlatency
[rocketmouse@archlinux ~]$

Re: How to clean up full /boot safely?

By Tom H at 02/15/2018 - 10:16

On Wed, Feb 14, 2018 at 8:26 PM, Ralf Mardorf <silver. ... at zoho dot com> wrote:

Copied from below:

You've already mounted the other install's "/boot".

In my case, the Ubuntu install has "/dev/sda1" as "/boot" and
"/dev/sdb1" as "/" and the Gentoo install has "/dev/sdc1" as "/".

They both boot from the kernel and grub files on "/dev/sdb1".

If I want/need to access Ubuntu's files on "/boot" from Gentoo, I run
"mount /dev/sda1 /boot". Of course, I could run "mount /dev/sdb1 /mnt
; mount /dev/sda1 /mnt/boot ; mount -o bind /mnt/boot /boot" manually
or when booting, but why?.

This has nothing to do with the initramfs. grub (and lilo) loads
"linux-image-..." and "initrd-..." from the "/boot" filesystem
(whether it's separate or not) without needing a mounted filesystem.

I set up a Debian VM, hostname "ralf1", and replaced grub with
extlinux. I duped it and purged "linux-image-..." and "extlinux" from
the copy. I can boot from either using the extlinux installed on
"ralf1" (there's not even a separate "/boot" filesystem on "ralf1").

root@ralf1 ~ # blkid
/dev/sda1: UUID="541ba927-f549-46a0-a79c-14205f90fec8" TYPE="ext3"
PARTUUID="46716548-01"
/dev/sdb1: UUID="c7d95e4f-f56f-4af5-9bab-8ba3318e1638" TYPE="ext3"
PARTUUID="46716548-01"

root@ralf1 ~ # findmnt -n /
/ /dev/sda1 ext3 rw,relatime,data=ordered

root@ralf1 ~ # ls /boot/
System.map-4.14.0-3-amd64 config-4.14.0-3-amd64
initrd.img-4.14.0-3-amd64 syslinux vmlinuz-4.14.0-3-amd64

root@ralf1 ~ # cat /boot/syslinux/syslinux.cfg
UI menu.c32
TIMEOUT 20
DEFAULT buster

LABEL buster
LINUX ../vmlinuz-4.14.0-3-amd64
APPEND root=UUID=541ba927-f549-46a0-a79c-14205f90fec8 ro
INITRD ../initrd.img-4.14.0-3-amd64

LABEL buster-no-boot
LINUX ../vmlinuz-4.14.0-3-amd64
APPEND root=UUID=c7d95e4f-f56f-4af5-9bab-8ba3318e1638 ro
INITRD ../initrd.img-4.14.0-3-amd64

root@ralf1 ~ #

AFAIK, unlike grub, extlinux couldn't load a kernel from
"c7d95e4f-f56f-4af5-9bab-8ba3318e163" (if it existed) without
chainloading a bootloader install on
"c7d95e4f-f56f-4af5-9bab-8ba3318e163"; but this isn't what I was
talking about.

Re: How to clean up full /boot safely?

By silver.bullet at 02/12/2018 - 21:59

On Tue, 13 Feb 2018 02:43:12 +0100, Ralf Mardorf wrote:

Re: How to clean up full /boot safely?

By silver.bullet at 02/12/2018 - 21:13

On Mon, 12 Feb 2018 21:41:33 +0000, Colin Watson wrote:
That is carefully worded :). Full ACK.

Re: How to clean up full /boot safely?

By Tom H at 02/12/2018 - 17:41

On Mon, Feb 12, 2018 at 3:35 PM, Liam Proven < ... at gmail dot com> wrote:
I'm not saying "might."

I'm saying that I've used an mdraid1 "/boot" as a separate filesystem
or as directory on "/" on at least 100 systems since 10.04 (when grub2
became the Ubuntu default; in those early days, the mdraid support was
flaky) and I haven't had a booting problem when one disk in a mirrored
pair has flaked out.

So, from my practical experience, I can make a blanket statement that
it works just as well as other crucial parts of a system like loading
a kernel, booting a system, or running a network-facing daemon.

You can hit a problem with grub, in the same way that you can hit a
problem with any other part of the software stack. But fretting about
grub being fragile or more fragile than other installed packages is
unreasonable.

Re: How to clean up full /boot safely?

By Colin Watson at 02/12/2018 - 14:52

On Mon, Feb 12, 2018 at 06:57:09PM +0100, Liam Proven wrote:
Your words were also "the kernel must be on something GRUB can read,
i.e. a straightforward Linux filesystem", and that was what I considered
to be the main substance of what I was objecting to. Do you see how
that reads as a claim that other configurations flat-out don't work?

I'd recommend that that actually be /dev/sda1 and /dev/sdb1 so that
there's a bit of room at the front for the boot loader; it can be made
to work otherwise, of course, but it's safer if you explicitly partition
the physical disks.

GRUB's nomenclature has traditionally been unpopular (though these days
you can use labels/UUIDs instead of having to care) but it's not without
rationale: since there's no reasonable way for a boot loader to exactly
replicate Linux's device naming, given that it's naming devices at all
it's best for it to have a naming scheme that isn't going to clash with
Linux.

It can and should be on both /dev/sda and /dev/sdb. If you put it
somewhere else then you're at the mercy of your firmware managing to
find it; if you only put it on one of those then you don't have a truly
redundant setup.

[This is my understanding of the design, but it's a very long time since
I've personally tried it. Anyone relying on this should test it on an
unimportant system first.]

In this scenario, the firmware will hand over control to the GRUB boot
image read from the start of /dev/sdb, which will proceed to read the
rest of the core image from near the start of the same disk (it does so
using sector addresses relative to the same disk, so it'll read that
from /dev/sdb). The GRUB core image will then build its own view of the
RAID array; in the case you outline, in the absence of further hardware
failures, it will have enough members to be able to read from the array.
When asked to read /boot/grub/grub.cfg and any further files that that
references, it will do so using that view of the array, which consists
of only data on /dev/sdb1, so that amounts to automatic failover.

In short: yes.

It will simply hand off to the kernel (and probably initramfs), and it's
their job to work that sort of thing out. This is true of any boot
loader.

I can see your position, although if the rest of the system is RAID then
this means you're deliberately arranging for the drive that contains
/boot to be a single point of failure. I don't really see a major
difference between having to recover /boot and having to recover the
boot loader in that kind of setup.

Personally, rather than deliberately eschewing boot loader support, I'd
prefer to set up a situation where the boot loader can automatically
deal with failover all the way from the firmware up, and test that on a
replica of the production environment. That way, when it fails in the
middle of the night on $holiday eve, it can last until somebody's normal
working hours rather than being an on-call emergency.

But this sort of thing depends on the situation.

As mentioned, you saying "this might not work" wasn't the part of your
message that I was saying was factually incorrect.

Re: How to clean up full /boot safely?

By Tom H at 02/12/2018 - 17:09

On Mon, Feb 12, 2018 at 1:52 PM, Colin Watson < ... at ubuntu dot com> wrote:
Indeed. In my previous email, I'd provided some output. It was from an
mdraid1 mirror of sda1 and sdb1, not sda and sdb.

Re: How to clean up full /boot safely?

By Liam Proven at 02/12/2018 - 16:31

On 12 February 2018 at 19:52, Colin Watson < ... at ubuntu dot com> wrote:
No. It is not and it does not.

It follows the word "might" and is thus _conditional_.

It expresses _uncertainty_ which is MY ENTIRE POINT.

And that uncertainty is what I am getting at, _not_ some subtle
linguistic quibble.

I am not disputing what GRUB can or can't do.

I'm saying that in the situation of trying to give general comments
about hypothetical situations in online advice -- which is what
technical writers must do, and that is what I am -- being careful and
general is essential and far more important than restrictive literal
statements about one software component can or can't do, which are not
generalisable to all systems in all cases.

Re: How to clean up full /boot safely?

By Colin Watson at 02/12/2018 - 17:28

On Mon, Feb 12, 2018 at 09:31:36PM +0100, Liam Proven wrote:
Huh? Please could you go back and check, because we seem to be arguing
past each other?

<a href="https://lists.ubuntu.com/archives/ubuntu-users/2018-February/293434.html" title="https://lists.ubuntu.com/archives/ubuntu-users/2018-February/293434.html">https://lists.ubuntu.com/archives/ubuntu-users/2018-February/293434.html</a>

Specifically this paragraph:

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.

That paragraph is the one and only thing I was referring to in the
innermost-quoted comment above. That paragraph did not follow the word
"might", and was not in any other kind of conditional construction that
I could see. The word "might" doesn't appear until the sentence *after*
that.

I have no issues with you saying that GRUB might have problems with
such-and-such a thing. Sure, I filled in some detail there in my reply,
but to me, "might have problems" is barely even falsifiable, and I
certainly wouldn't try to refute it (for any piece of software at all,
really - I mean, I found a bug in strchr(3) once).

I'm sure I'm uncertain about lots of things that are absolutely safe and
reliable. Nobody should deduce anything from my uncertainty.

Right. But when technical writers make statements that come across as a
careful and general statement that such-and-such a thing *doesn't* work,
then this can make users flail around trying to avoid something because
they were told it didn't work, when it would actually have been their
easiest path to a working system.

That's all I'm getting at here. I really am not going to argue with you
saying that something is unreliable and should be avoided (I may
disagree in some cases, will probably agree in others, and perhaps I can
supply some extra factual information for the benefit of others, but I'm
obviously not going to persuade you in any case and life is generally
too short).

Re: How to clean up full /boot safely?

By silver.bullet at 02/12/2018 - 12:22

Liam, you aren't a novice, we all are aware that you are a power user,
but actually you are just melodramatic. Much likely "we" get your
point, at least I got your point. You know better ;).

Re: How to clean up full /boot safely?

By Liam Proven at 02/12/2018 - 13:00

On 12 February 2018 at 17:22, Ralf Mardorf <silver. ... at zoho dot com> wrote:
It seemed (and seems) to me to be a simple point that people are
refusing to confront and trying to deflect by claiming that the
discussion is about something else.

To pick an example I have seen in a few places recently... people
running some FOSS OS on a laptop and saying that the solution for wifi
problems is [a] replace the internal wifi card or [b] use a USB wifi
adaptor.

This is _not_ the "solution" for wifi "problems". What this _really_
means is "this computer's wifi does not work with Linux. If you intend
to run Linux, get a different computer."

Once, decades ago, I would do days or weeks of work to get some
obscure kit that I already had working. I did not mind the time. I had
plenty.

Now, I mind. I don't have much. I want it to work when I plug it in.
If it does not, that means _it does not work_ and I will go buy
something else. A "solution" that involves any significant additional
work is not a real solution.

E.g. I had a problem that my Mac mini would not mount external USB
drives. I spent some time Googling and researching. Nothing
definitive.

I accidentally found the answer.

Use a powered hub. The Mac mini's internal PSU is underpowered. It
can't drive USB devices that require more than a minimal amount of
current. Plug it into a hub, it just works. That is the answer. Done.
Over. Easy.

No amount of fscking or installing drivers will help. It's an
electrical power problem.

But a €5 hub and it's solved, and now, the ports are easier to get at, too.

Sometimes there are complex difficult answers, and sometimes, there
are simple clear ones. And sometimes, there are answers that are
_both_ and having a rule for what you want makes life easier.

I attempted to explain my rule. Several people said "no it's not about that".

Yes, it is.

It's similar to my attitude to playing games. If a game takes longer
to learn than to play for the first time, I am not interested. I
*hate* learning new games. So if the explanation takes more than a few
seconds, forget it, it is too hard.

If explaining how to boot off a particular type of device _with all
the warning and advisory notes included_ takes more than a few
seconds, _it doesn't work_ so do something else.

If someone enjoys playing, as I used to, fine. Go for it. Enjoy. But
do not say "it just works" because it does not.

It's a big, important difference. Very few companies in IT understand that.

Canonical does. Apple does. Red Hat doesn't. Most Linux companies don't.

As a consultant, it took me a long time (many years, nearly a decade) to learn.

Re: How to clean up full /boot safely?

By silver.bullet at 02/12/2018 - 12:40

On Mon, 12 Feb 2018 17:22:31 +0100, Ralf Mardorf wrote:
There is no good translation for "Korinthenkacker"
<a href="https://www.dict.cc/deutsch-englisch/Korinthenkacker.html" title="https://www.dict.cc/deutsch-englisch/Korinthenkacker.html">https://www.dict.cc/deutsch-englisch/Korinthenkacker.html</a> .

Re: How to clean up full /boot safely?

By silver.bullet at 02/12/2018 - 08:55

On Mon, 12 Feb 2018 13:26:20 +0100, Liam Proven wrote:
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.

Re: How to clean up full /boot safely?

By Colin Watson at 02/12/2018 - 08:51

On Mon, Feb 12, 2018 at 01:26:20PM +0100, Liam Proven wrote:
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.

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.

Re: How to clean up full /boot safely?

By Liam Proven at 02/12/2018 - 11:08

On 12 February 2018 at 13:51, Colin Watson < ... at ubuntu dot com> wrote:
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.

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.

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.

Re: How to clean up full /boot safely?

By Colin Watson at 02/12/2018 - 13:10

On Mon, Feb 12, 2018 at 04:08:52PM +0100, Liam Proven wrote:
If that was your point then you rather obscured it by peppering your
reply with air-quotes of all my qualifiers. Please don't do that again.

I'm almost never willing to tell you on a mailing list that something is
absolutely guaranteed, because for a mailing list post I'm not going to
put the research time in to back that sort of claim, and I don't want
the liability of somebody then coming back and blaming me if I made some
kind of mistake, or even if they made some kind of mistake and didn't
realise it. (Somebody who's paying me for my time will obviously get
more effort put into my replies.) If you don't like that, you can stop
reading anything else I write, because on the whole it's what you're
going to get.

"Any express or implied warranties, including, but not limited to, the
implied warranties of merchantability and fitness for a particular
purpose are disclaimed", and all that, as the BSD licence has it.

Then you were simply wrong. You may not *like* putting /boot on
something that isn't a straightforward Linux filesystem; I'm not going
to make you. But GRUB supports many such configurations, and it is not
true to say that the kernel must be on a straightforward Linux
filesystem in order to work with GRUB.

I have no problem with you deciding that you don't want to use a
particular facility because you don't trust it; that's your prerogative.
I don't care about selling you on using GRUB. But you specifically said
that a thing is not possible, when it absolutely is, so I made a factual
correction in order that other people might not take your post as a true
statement of GRUB's limitations. I was posting to the mailing list
rather than replying privately to you, after all, so I didn't think you
were the sole audience.

(Normally that sort of "must" statement means "it definitely won't work
otherwise". Perhaps you meant something like "the kernel must
[according to my personal policies for setting up systems] be on a
straightforward Linux filesystem". That'd be quite different, although
I don't think it's the most natural reading. If you in fact meant that,
then I hope you'll note the ambiguity and clarify.)

Of course not. Nevertheless, they're supported by GRUB.

Notwithstanding my second paragraph above, I am extremely confident in
GRUB's LVM support, for instance, and I would be happy to say that it
will just work in the absence of hardware failures or configuration
errors. (There is one caveat, which is that the small number of
operations in GRUB that require *writing* to the block device aren't
currently implemented for LVM, mainly due to an abundance of caution
about the risks of getting write support wrong; fortunately, the only
such operations are a few obvious partition-table-modification commands
for emergency use, and the "save_env" command for persisting variables
in an environment block file, and none of that is essential
functionality.)

I'm not prepared to make that sort of claim about other configurations
such as RAID or ZFS, simply because I haven't spent much time with those
parts of GRUB beyond a few passing bug-fixes and I don't personally use
them. To my mind that says nothing about their reliability; I'm just
not personally prepared to say anything about them beyond having seen
them work in development environments. I think it's nevertheless worth
me pointing out that they're supported upstream, though, because that
may very well simplify somebody's life.

Re: How to clean up full /boot safely?

By silver.bullet at 02/12/2018 - 11:15

On Mon, 12 Feb 2018 16:08:52 +0100, Liam Proven wrote:
I'm not, so I need to use a dictionary for my response:
<a href="https://www.dict.cc/?s=pathetisch" title="https://www.dict.cc/?s=pathetisch">https://www.dict.cc/?s=pathetisch</a>

Re: How to clean up full /boot safely?

By Colin Law at 02/12/2018 - 06:29

On 12 February 2018 at 10:00, Liam Proven < ... at gmail dot com> wrote:
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

Re: How to clean up full /boot safely?

By Colin Watson at 02/12/2018 - 07:14

On Mon, Feb 12, 2018 at 10:29:35AM +0000, Colin Law wrote:
Indeed, it works fine.

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.

Re: How to clean up full /boot safely?

By Colin Law at 02/12/2018 - 13:10

Thanks for that Colin, I may give it a go.

Colin L.

Re: How to clean up full /boot safely?

By silver.bullet at 02/10/2018 - 17:46

On Sat, 10 Feb 2018 22:26:23 +0100, Ralf Mardorf wrote:
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!

Re: How to clean up full /boot safely?

By Colin Law at 02/10/2018 - 17:45

On 10 February 2018 at 21:26, Ralf Mardorf <silver. ... at zoho dot com> wrote:
Absolutely.

Colin