Beginners Guide: Migrating to SSD

[alicjusz]

Welcome. I installed the debian on the hdd disk and run the SPI Flash method. Everything works properly except for system restart. The "Sudo shutdown -r now" switches off the system. Please help me - how can I restart the system correctly? Thank you.

[svyt22]

Welcome. I installed the debian on the hdd disk and run the SPI Flash method. Everything works properly except for system restart. The "Sudo shutdown -r now" switches off the system. Please help me - how can I restart the system correctly? Thank you.

"sudo reboot" ?

[alicjusz]

Unfortunately Sudo reboot, sudo shutdown -r now, sudo init 6", none of these commands work properly. LEDs are off and the system does not stand up. If it installs on the eMMC card everything works properly. Maybe a delay is needed for the system to start from hdd? Can anyone check it at home or suggest how to do it?
Greetings

[Rustproof]

The commands "sudo reboot and sudo shutdown -r now" quit restarting the system after migrating to an SSD.

The only way to start the system after either command is to kill the power for a few seconds.

Rock64
Xenial minimal community build(All Packages up to date)
100GB SSD with PINE64 HD cable.

rustproof@rock64:~$ sudo apt update
Hit:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease
Hit:2 http://ppa.launchpad.net/ayufan/rock64-ppa/ubuntu xenial InRelease
Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-security InRelease [102 kB]
Get:4 http://deb.ayufan.eu/orgs/ayufan-rock64/releases  InRelease [1249 B]
Get:5 http://ports.ubuntu.com/ubuntu-ports xenial-updates InRelease [102 kB]
Fetched 206 kB in 1s (103 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.

[dmitrymyadzelets]

The commands "sudo reboot and sudo shutdown -r now" quit restarting the system after migrating to an SSD. The only way to start the system after either command is to kill the power for a few seconds.

Confirm. After migrating to SPI booting not always, but most of the time the software reboot fails. Moreover, event hardware reset and power buttons don't work.
rock64 images from 0.6.25: jenkins-linux-build-rock-64-193

[rdevarajan]

4. Tell Linux where to find the root file system by editing the configuration file  /boot/efi/extlinux/extlinux.conf

sudo nano  /boot/efi/extlinux/extlinux.conf

In the editor, you will see the text as follows:

label kernel-4.4
    kernel /Image
    initrd /initrd.img
    fdt /dtb
    append earlycon=uart8250,mmio32,0xff130000 rw root=LABEL=linux-root rootwait rootfstype=ext4 init=/sbin/init coherent_pool=1M

Change LABEL=linux-root to LABEL=rootfs  or whatever label you used on step 1.

Save the change and exit the editor.

5. Reboot

After reboot and login back, you can verify with lsblk -f command.

sudo lsblk -f 

Have fun.

Hi, 

Before we reboot (step 5) , should we also add the entry for  /dev/sda1 to the fstab so that this drive is mounted when the system reboots?

[SirRyanTheGeek]

Sadly none of these methods are 100% stable (yet)

I'm having issues after having tried everything in this thread, as well as using the latest SPI flash to allow for USB boot (no microSD or eMMC card). The problem is, depending on WHAT you're plugging in to the USB port, there isn't enough of a delay between startup and waiting for whatever is attached to "spin up" and be ready to boot.

I can get it to boot on USB alone on average only 1 out of every 7 to 10 attempts. And on one of these attempts it corrupted the filesystem to where I had to re-image it from scratch onto the SSD. 

What I'd like to see is if it is possible is to do one of three things:

• Use a new SPI flash that allows a programmatic timeout/delay that is somehow configurable that says something like "wait 20 seconds for anything attached to spin up - then attempt a boot if you find a bootable partition. Then it won't matter if you plug in a slow HD, fast SSD or a USB key with an OS - it should still find it and fire up and not hang
  

• Clear instructions on how to use something like what we have for the Pi - a microSD card that has nothing on it all except "bootcode.bin" bootloader and an empty file called "TIMEOUT" that forces a delay I think of 20 seconds - more than ample time to get anything USB attached to power up and be recognized
  

• Or failing any of the above - using a low-size un-important SD card, if I put the same Bionic or Stretch image on it that I do on the SSD that I plug in, what changes do i need to make to the SD card before I boot it up to just point to whatever it finds first that is attached to USB again, with a delay. Same thing as the second option listed except using the whole image as nothing but a bootloader. 
   
  

With either the second or third options, I am perfectly okay with "wasting" a cheap microSD for the purpose of knowing I will always get a reliable bootup after running a reboot or power-cycling the board.

[thatchunkylad1989]

Thank you so much for this!
I have just ordered an SSD for my Rock64 so this will definitely come in handy!

You're a legend.

[Ellesar Dragon]

hi rontant, does this just directly change the file system at boot similar to how you would do it with fstab, but than by directly doing so at the most early stages of boot?
and do I need to add a automaounting script or will this automount it. further I wondered if I need to manually unmout the micro sd card after boot by adding a command to some init script, or is there a more easy way to tell this config to auto unmount the micro sd, or to mount it as read only? this is because the micro sd cards tend to fry themselves whenever there is a power outage if they are mounted in read mode, in a ssd this tends to just result in some corrupted data which often is fixable, but I preffer to not constantly replace the micro sd, it was fast enough for my case, but not durable which is why I wanted to switch it to ssd.

also why cp instead of dd? is it just a preference or does it have a technical reason such as a speed difference or such?

and thanks for this post. on the Pine a64+ there doesn't seem to be any normal way of booting from USB/ssd. otherwise I would likely have dd'd the os to the ssd and then after boot mounted everything to the USB to unmount the ssd after that.

---

on the pine a64+ with armbian(latest stable releas as of now),
sudo nano  /boot/efi/extlinux/extlinux.conf
is
sudo nano /boot/armbianEnv.txt
for anyone seeking how to do it there. it is most easy and secure to use
sudo lsblk -f
to find the uuid of your drive this way you can just copy paste it.
The rest is just the same, you reboot and the drive you set the UUID of will be used to boot.

as extension on my question above this it: I didn't see a mountpoint for the microsd, neither was anything mounted in /mnt or /media, so it seems like I won't need to manually unmount it. it did however show 2 zmem drives, so I have to check if the micro sd is not secretly still being used for swap memory, have to figure out how to check and potentially fix that it it actually still uses it as swap. but if it doesn't  and the micro sd is really not mounted or used anywhere except for at boot, then I won't need to do anything anymore and this was a much simpler tourney than expected.