Thanks for the heads up! I haven't heard of this but I've downloaded the most recent astroberry image to SD, done a full upgrade and firmware update, copied the whole thing to a USB and booted successfully from that. So I'm hoping that it may stay that way when I transfer to SSD!
What I intend to do for the mo is update the SD by installing gparted, zip and the NTFS drivers at the least and install my INDI profles, possibly update ASTAP, and then use gparted to include a small 4Gb data partition at the end of the SD, which may allow me to clone the whole thing to a 32Gb USB as a backup, Then periodically I could empty the SSD NTFS partition, which is only there really to transfer FITS and SER files to PIPP and Registax, shrink the NTFS partition to fit inside 32Gb, then I can clone the whole thing to the SD again for updating., clone the SD to the USB for backup, then clone to the SSD and re-expand the data partition on fhe SSD. I platesolve on my linux machine so I don't need the astrometry database on the pi (and ASTAP does not need large files anyway).
The wild card in this plan is whether the apt-update apt-upgrade process will fall over if there is another partition on the SD. I'm hoping not. If that is toing to be a problem I can't currently think of a way around it ;(
Any thoughts on this would be helpful - fools rush in!
I would suggest that you get a RaspberryOS image on a SD card and boot off that, once booted up attach the SSD drive.
The logs should indicate what partitions are detected when the SSD drive is attached, or you can enumerate them with a tool like fdisk (don't modify the partition table, just use it to view the partitions).
Then I would try and manually mount any partitions on the SSD drive, just create a folder and use the mount command to mount them at that folder. You can then inspect the contents of the SSD, and also use any file transfer method to back up your files to another system.
Once you have backed up, I would just suggest that you start the image process again.
Due to the weather I have not booted up my astroberry for quite a while, but might tinker around at the weekend and do some updates etc... So will let you know if I see any significant updates that might have caused this issue for you.
Good lessons here -
1. Backup your data, or just store it off the Pi - it is, after all, being used outside, where it could get rained on, be exposed to adverse conditions etc...
2. Sparingly update only when necessary
Thanks for this. I have now found many threads on boot loader failures
Have decided to reinstall Astroberry and rebuild the installation. This time I will indeed be more careful! So far - just about to create 4Gb NTFS partition on the SD ready for cloning - so good. The USB backup boots fine.
I am used to backing up frequently as my normal distribution is Manjaro - constantly updated. Will be sparing with the Pi!
I had forgotten that any partition can be mounted to a folder - that will be hugely helpful in extracting the data from the data partition in the future.
Sorry for my confusion but I was assuming that update and upgrade would involve the shift from debian buster to debian bullseye. This doesn't happen (thank goodness!) I just made a copy of my backup Astroberry 2.0.4 microSD card (fully loaded with platesolving files and equipment data etc) and performed sudo apt update and sudo apt upgrade on the copy. There were 56 packages upgraded but all the revisions of main OS packages were labeled 'oldstable' and the OS stayed with debian buster rather than moving on to bullseye. The upgraded version appears to be fully working.
Currently running KStars/Ekos/Indi on two Raspberry Pi 4Bs 4GByte under Raspberry Pi OS thanks to Astroberry
Two mounts, two Fracs, a Newt and a Mak and a couple of OSC cameras.
This is just a quick thanks for your help. I have reloaded the astroberry server, which includes the latest firmware allowing the pi SD copier to copy my new SD card image (/boot, /root and a new 2GB NTFS data partition) to SSD. On copying the data partition was automatically expanded to fill the unallocated space on the SSD.
Now I have a backup / dev image on the SD which I can update as required and deploy when wanted. The only limitation is that I can't fill the SD beyond about 22Gb - plenty room left atm.