-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v1.3.1 release doesn't boot from microSD if encryption option is selected #261
Comments
Does this occur when encryption is not chosen? gru-bob support is still quite underdeveloped so I wouldn't be surprised if it just has issues booting from sd. |
It does actually boot when not using encryption, though I was still having some weird visual artifacts and lsusb and lspci weren't working so I didn't have much luck checking if a newer package made things better. |
hm, then something went wrong during installation. depthcharge beeping indicates the kernel isn't present at all, which encryption shouldn't effect. I ask because my best guess is a bug in the script that installs from USB to sd |
Your suspicions are correct, I used the Chrome Recovery tool to write the img (renamed .bin so it sees it) to a USB and then booted from the USB and did the encrypted installation to the microSD. Oddly enough the same process but without encryption works so it's maybe just a missed conditional on the encrypted installation block. |
I need to test this again with the image that has the USB fixes, I'm wondering if there was another kernel config option that changed between arm64 and armhf for bob/gru that would have caused issues with the encrypted installation option. |
Shouldn't be, I boot head of master PrawnOS on gru-kevin encrypted on emmc. I'll have to pour some time into this when I get some. |
Device: C101P gru-bob
I extracted v1.3.1 to a USB to install to a microSD and while the installation completes, upon rebooting without the USB inserted, I get the loud beeps/no bootable kernel error from depthcharge when trying to Ctrl+U boot, presumably because the /boot partition is encrypted or the signed kernel it looks for isn't readable?
The text was updated successfully, but these errors were encountered: