11-07-2020, 05:27 PM
@kuleszdl
Just an update, now that I got to test this. Sorry for the late reply, for some reason I can't post the links I'd like.
Unfortunately, the SD-card i prepared with your instructions on your blog post didn't work, although not because of anything wrong in your post. U-boot worked as expected, but the kernel didn't boot. There's already a Debian bug post on this. Apparently setting FAT as the working environment for u-boot works, but I didn't try that.
I ended up following the approach outlined by @foresto in his post recently. I chose to put /boot as the 2nd partiton on the SD-card prepared using the debian unstable installer image. Like foresto, I defined preseed to debian stable and then installed the unstable kernel through chroot before completing the installer. I got around the potential pitfalls with the installer by zcat'ing the last working firmware.rockpro64-rk3399.img.gz from "20201006" and partition.img.gz from "daily", as mentioned by @MSteam did in foresto's post.
I set up encrypted root on a USB 3.0 SSD while installing. Because quite a few people seem to have issues with booting MMC-modules, and SD-card having limited performance, this seemed like a good compromise without requiring the PCIe-SATA adapter and a large NAS-case to house it. I'm merely using the aluminium case for the RockPro64. Using the SD card for u-boot and the /boot partition gives me the flexibility to experiment with future u-boot versions etc without using the serial adapter and messing around with the SPI all the time. Like a lot of others, I couldn't get u-boot on SPI to detect my disk when connected to the USB 3.0 port. So this is a decent workaround for the problems @idontgetit experienced recently. I'm sure USB 3.0 support in u-boot will mature eventually.
Also, as I wanted to use dropbear-initramfs to unlock the encrypted root through SSD as outlined in the blog post, I had to make a small adjustment to @kuleszdl instructions. I ran into a race condition where eth0 wasn't ready before reaching the luks unlock-prompt. There's a Debian bug report for this too. The workaround for me was to add "sleep 10" before "configure_networking ()" is called in "/usr/share/initramfs-tools/scripts/init-premount/dropbear".
So now I have Debian stable with the unstable kernel, and my USB 3.0 SSD works great! After flashing stock JMS578 firmware from here to my $8 Orico enclosure and adding udev-rule for it, I have working UASP with TRIM-support too!
Best of all, "reboot" from commandline works without issue.
Performance seems to be really great! The disk is snappy, and I can easily saturate my 500/500 fiber connection. No issues or any other problems so far. Nice to finally run a fully open source system without binary blobs.
I'm hoping support will be more end-user friendly by the time Debian 11 is released
Just an update, now that I got to test this. Sorry for the late reply, for some reason I can't post the links I'd like.
Unfortunately, the SD-card i prepared with your instructions on your blog post didn't work, although not because of anything wrong in your post. U-boot worked as expected, but the kernel didn't boot. There's already a Debian bug post on this. Apparently setting FAT as the working environment for u-boot works, but I didn't try that.
I ended up following the approach outlined by @foresto in his post recently. I chose to put /boot as the 2nd partiton on the SD-card prepared using the debian unstable installer image. Like foresto, I defined preseed to debian stable and then installed the unstable kernel through chroot before completing the installer. I got around the potential pitfalls with the installer by zcat'ing the last working firmware.rockpro64-rk3399.img.gz from "20201006" and partition.img.gz from "daily", as mentioned by @MSteam did in foresto's post.
I set up encrypted root on a USB 3.0 SSD while installing. Because quite a few people seem to have issues with booting MMC-modules, and SD-card having limited performance, this seemed like a good compromise without requiring the PCIe-SATA adapter and a large NAS-case to house it. I'm merely using the aluminium case for the RockPro64. Using the SD card for u-boot and the /boot partition gives me the flexibility to experiment with future u-boot versions etc without using the serial adapter and messing around with the SPI all the time. Like a lot of others, I couldn't get u-boot on SPI to detect my disk when connected to the USB 3.0 port. So this is a decent workaround for the problems @idontgetit experienced recently. I'm sure USB 3.0 support in u-boot will mature eventually.
Also, as I wanted to use dropbear-initramfs to unlock the encrypted root through SSD as outlined in the blog post, I had to make a small adjustment to @kuleszdl instructions. I ran into a race condition where eth0 wasn't ready before reaching the luks unlock-prompt. There's a Debian bug report for this too. The workaround for me was to add "sleep 10" before "configure_networking ()" is called in "/usr/share/initramfs-tools/scripts/init-premount/dropbear".
So now I have Debian stable with the unstable kernel, and my USB 3.0 SSD works great! After flashing stock JMS578 firmware from here to my $8 Orico enclosure and adding udev-rule for it, I have working UASP with TRIM-support too!
Best of all, "reboot" from commandline works without issue.
Performance seems to be really great! The disk is snappy, and I can easily saturate my 500/500 fiber connection. No issues or any other problems so far. Nice to finally run a fully open source system without binary blobs.
I'm hoping support will be more end-user friendly by the time Debian 11 is released