Ubuntu Revisiting Its Initramfs Compression Approach

[slalomsk8er]

Ubuntu has had those /boot problems for a long time while the solutions are plenty and easy. First dont use an extra /boot if not nessesary (might be hard since UEFI but the problem is much older), second make /boot 1GB, or third just make the initramfs build a little more error tolerant.

Would be nice if the distribution wouldn't leave this as "exercise for the user" but would provide solutions for problems caused by there defaults

[Anux]

That constant liveCD -> chroot -> delete oldest image -> apt install -f shouldn't be nessecary or atleast easy to automate. But who cares, since arch linux I don't need to deal with such trivial design errors.

[Weasel]

How about just go back to XZ everywhere and stop bitching about a couple seconds of extra boot time?

All these morons who think shaving off ~10 seconds is worth it, I hope you're precisely timing when you eat, gotta save those 10 seconds of your life. Gulp down your coffee too, or brush your teeth under systematic watch.

God forbid you waste 10 seconds. Clowns.

[NobodyXu]

How about just go back to XZ everywhere and stop bitching about a couple seconds of extra boot time?

All these morons who think shaving off ~10 seconds is worth it, I hope you're precisely timing when you eat, gotta save those 10 seconds of your life. Gulp down your coffee too, or brush your teeth under systematic watch.

God forbid you waste 10 seconds. Clowns.

They are optimizing for the compression time at installation on arm-like devices or old devices, not boot time.
It is mentioned in the article.

[Weasel]

They are optimizing for the compression time at installation on arm-like devices or old devices, not boot time.
It is mentioned in the article.

The problem is that for such devices, storage also tends to be on the low end.

[NobodyXu]

The problem is that for such devices, storage also tends to be on the low end.

True, but compression time is also legit concern.
If apt-get install takes like 5m or more, then it's certainly not good.

[Anux]

The problem is that for such devices, storage also tends to be on the low end.

I'm not sure if you have ever xz compressed that image on a slow CPU, it already takes several minutes on a fast CPU.

[arQon]

Are you implying he should resize (grow) the partition to 1GB? I had such an issue and I wanted to but I didn't know how to do it because I already had another non-boot partition next to it, and another one next, so I couldn't just resize it. I just didn't know what's the right thing to do, moving all partitions to the right seemed way too much work and putting the boot partition anywhere then from the start I worried that some OS (windows maybe) wouldn't support that properly.

Yeah, partitioning can be a pain in the ass, and like you say there are other OS's that can complicate things significantly further.
But yes, my question was essentially that. Although it IS "way too much work", it's actually very quick to do IF you notice the problem before you've filled the drive with data. I certainly wouldn't try to correct a bad partition setup if it was on a 8+TB HDD, but if the drive is currently split as something like [garbage /boot][y GB /usr][x GB /], I'd be inclined to poach a few GB from /usr to resize /boot to something sensible, because you can do so without touching the root partition at all.
If the ordering is [/boot][/][/usr], or there's only /boot and /, I might well still go with fixing the problem even at the expense of gparted unfortunately having to relocate all of the root partition. I've had to do similar things in the past, and I generally kick them off when I go to bed, they run overnight, and by the next morning everything's done.

Assuming you have decent backups (which everyone really should at this point), then even if the drive wasn't partitioned well originally you can also use scenarios like this to check your recovery procedures. If / is full of stuff that should have been put in a /data partition in the first place, the more of it you delete before starting gparted the quicker the fs relocation is. Once you've done that, you restore the data from the backup, and either validate your process or fix the pieces that you missed.

I'm not saying it's a fun time: it always sucks when you end up in this sort of situation, regardless of the cause. But when you have two options where one is a one-time inconvenience and the other is a frequently-recurring problem with an infinite lifespan, it's nearly always better to just bite the bullet, fix the actual problem, and move on. Like technical debt and credit card debt, the false economy of not doing so is massively more expensive in the long run.

Unrelated, but very useful to know: I discovered last week that it's actually possible to recover a broken (as in "damaged, non-booting, and not just from the typical GRUB problems") single-partition Ubuntu desktop install with no loss of even user-level configuration etc just by reinstalling over the existing partition and using a throwaway account for the installation. You still have to reinstall any "custom" packages afterwards, but if you're doing it remotely for non-technical friends and family that's a massive win.

[arQon]

The problem is that for such devices, storage also tends to be on the low end.

Right - though I'm not sure how much of a problem that really is any more. Even in the SBC space, almost everything is either booting off SD cards or from what (compared to my embedded days) is very generous amounts of eMMC: generally 32GB even at the low end. Even "only" 8GB is more than enough for a full Ubuntu *desktop* install, and if you've got less storage than that available for your embedded device *any* off the shelf distro is going to be a bad decision: you need to be rolling your own.

Which I think in turn suggests that although I agree with your sentiment that this whole exercise is a waste of time, I disagree with your conclusion that xz is the answer: in fact, it's close to the worst possible option overall. When storage is effectively infinite but time is not, it's the use of xz that is "moronic" - especially since we're now well into the second decade of Ubuntu et al running initramfs THREE times every time there's a kernel update instead of ONCE. If Canonical actually put some effort into fixing THAT instead of dicking around with this worthless argument, they could use a compressor that was twice as slow and still come out ahead on both time AND disk space. Go figure...

[creative]

I may be the only brave one here that dedicated a mere 300MB to my boot partition hahahahah! Only two partitions for my system one is super huge and the other really tiny. Been doing it forever. Well only that much for my boot loader.

I'm strange and picky about odd things though, I make grub display at my monitors native resolution. Gotta have that sharp and clear boot menu.