Yes....it will be simples.....I just need an m.2 SSD to USB adapter. Thanks for the help.

Ah... this is what I did... I already had a USB SSD with Astroberry installed:



In any case, you don't need an M.2 adapter, the bottom half of the argon one m.2. is the adapter, you just need a USB cable from the bottom half to your Windows machine.

Why....
Just connect the USB port on the bottom of the Argon case to your windows PC, and flash it that way....

Thanks guys for the info. It'll be easier than I thought. Thanks again.

Hi all! I'm new to all this, and can use all the help I can get! Argon M.2 & RasPi4 was delivered today, and the WD Blue SSD would get delivered tomorrow.
Reading the above comments, I gather I can directly flash my SSD with Astroberry while it sits in the M.2 via usb cable to laptop. It is also recommended above that I fully upgrade the firmware of the RasPi before trying this.
My question is, can I upgrade the firmware without the SD Card? I'd like to have everything on the SSD.

Sent from my ONEPLUS A6000 using Tapatalk

How to upgrade the firmware without the SD Card?

Sent from my ONEPLUS A6000 using Tapatalk

You need to boot by a method that your current firmware supports in order to update to a firmware that supports a native SSD boot.
This means that you need and SD card, although you might possibly be able to Network PXE boot from a DHCP / NFS server. (The SD card is the method that would be cheapest and least technically challenging).

Thanks for taking the time to reply! I was able to set it up on my SD Card. Then, moved everything to SSD using the copier. It boots and runs on SSD just fine now.

Sent from my ONEPLUS A6000 using Tapatalk

Hi Giles - watched your v detailed and useful video with interest. I was booting from SSD successfully until i did a full apt-upgrade a couple of nights ago. Then chaos. I have been through my blkid, /etc/fstab and /boot/cmdline.txt and can see no errors. But when I boot from SSD I get a failed to find target message (after a systemctl rfkill message) then I can't proceed. No way of TTY-ing in. When I alter fstab to point to the SD card for /boot nothing happens at all.

I have quite a bit of material on the SSD which is not backed up for reasons in next para. Can I check and update the firmware on the SSD without booting from it? I can insert the SSD into a linux machine and work off the console.

Reason the SSD was not backed up is that it is larger than my SD. I have a NTFS data partition on the SSD which is not on the SD, even if I offload all the data. The RPi card copier will not image part of a device. I tried a simple dd fi /dev/sda1 fo /dev/sdb1 (and same for the /root partition) to a 32Gb USB, but this didn't appear to work - at any rate i failed to boot from the SSD afterwards.

Any advice you may have will be helpful - atm my only course of action seems to be to reinstall to the SSD from scratch using a fully updated and fw upgraded image, then install gparted to add my data partition again. However, I would be wary of dd'ing the first two partitions again - there must be a better way!

Thanks for any useful words ..

Best
R

Just wondering if you need to use BerryBoot? Astroberry runs beautifully from my SSDs copied on the RPi from the microSD card. Recent updates to the RaspberryPiOS have caused a lot of issues, and if you did a typical sudo apt update && sudo apt upgrade, you will have had a lot of these changes introduced into your software. I am sticking with the recently downloaded Astroberry 2.0.4 image, copied over to my SSD, and it seems wise to stay off-line and away from any updates until the ‘mess’ is sorted!

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!

Best
R

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