> Just to check: should tmp.mount be unmasked on the Pi 3B+? Or does it not make any difference to how it runs? (It is doing a serious job and I don't want to leave it in a less-than-ideal state.)
If your 3B+ is running fine for now, I'd leave it as it is. I'll be SRU'ing a change that will disable tmp.mount on any Pi with <8GB of RAM (which will obviously include your 3B+), but that'll take time to wend its way through the SRU process, so this change will come to it eventually via that process. You can skip ahead if you like, but personally I'd say "don't bother making changes you don't need to". Which probably begs the question: if the 1GB 3B+ is running okay, why am I pushing through the change with an 8GB threshold instead of 1GB? Mostly because 8GB is about the bare minimum on PCs these days so the tmpfs change is well tested at that level, but clearly has far less "real world" testing below that. Also because 4GB is the bare minimum we support on the Pi desktop now, and if half of that RAM disappears it'll definitely cause issues for Firefox even with swap. As 8GB is (currently) the next step up on the Pi, that seemed a reasonable cutoff. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2155094 Title: RPi 3B, Zero 2W, 4B: New boot assets in /boot/firmware/new failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2155094/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
