But it is a nice solution as the updating to Buster is possible and many people do of course do it, generally as it works ok.HawaiianPi wrote: ↑Wed Oct 09, 2019 7:31 amIt seems to me the solution is for people to follow recommendations and not upgrade from an older OS. As far as I know, that was never a supported procedure (Debian/Raspbian stable is not a rolling release), so I'm not sure why effort is being devoted to supporting it now?
Especially when it will likely just lead to further trouble (limiting what gets installed in the smaller /boot partition will cause problems when someone tries to swap the card to another model). So you're just trading one problem for another.
Although it is very nice of you to try.
many thanks it work perfectlyMilliways wrote: ↑Sat Oct 12, 2019 11:45 pmIf you make a backup using the code in https://raspberrypi.stackexchange.com/a/103991/8697 then restore the new Image will have a 256MB boot partition. (This also fixes the problem with Buster images which actually have 256MB + 1 sector boot partition and a 4MB gap before the root partition).
NOTE Upgrading is still risky.
Code: Select all
Adding 'diversion of /boot/start.elf to /usr/share/rpikernelhack/start.elf by rpikernelhack'
Code: Select all
Unpacking raspberrypi-kernel-headers (1.20190925+1-1) over (1.20190925-2) ... Setting up raspberrypi-kernel (1.20190925+1-1) ... You do not have enough space in /boot to install this package. Skipping Pi 4 support Removing 'diversion of /boot/kernel.img to /usr/share/rpikernelhack/kernel.img by rpikernelhack'
That's fine. That the part of the install that makes sure that files don't get installed directly to /boot. Files only actually get moved to /boot when the divert is removed.fru1tl00p wrote: So during the upgrade apt-get does all these diversions like this:
Good, that looks like it's working as expected. If there was a problem the divert would fail to get removed.fru1tl00p wrote: The exact error message I got from apt-get before my rpi being bricked was this:
Then it's an unrelated issue. If your ssh session drops during an install like that for whatever reason, it won't end well. tmux or gnu screen are a good idea when doing things like this.fru1tl00p wrote: Then it just hung for ages, I opened another ssh session and rebooted and it was bricked.
No the ssh session was fine, I could still do carriage returns etc... but the install just wouldn't complete, I waited long enough.ShiftPlusOne wrote:Then it's an unrelated issue. If your ssh session drops during an install like that for whatever reason, it won't end well. tmux or gnu screen are a good idea when doing things like this.
Code: Select all
Cannot open access to console. The root account is locked see sulogin(8) man page for more details.
No - at least not on a running system - you can't move an active root filesystem.
What about if I "mount" the disk in Debian on another machine?Milliways wrote: ↑Wed Oct 16, 2019 2:30 amNo - at least not on a running system - you can't move an active root filesystem.
It is possible to resize/move partitions on a mounted filesystem. This can be done with gparted (or manually).
The easiest is to make a modified image. The answer I posted above shows a tool to do this. It can also be done manually, but is rather tedious (and error-prone)