I am using SD card only for boot, and USB card for disk (storage).
I am experience strange things during hot restarts and starting suspecting the actual SD+USB combination.
Could I ask, how its recommended approach to install that setup?
In times, when .tar was used for installation, I just prepared SD+USB by partition tool, primary FAT32 (1GB) to the SD card, primary EXT4 (XGB) to the USB stick. Find out UUID’s, fill them into cmdline.txt@Rpi and it works.
Now, I install .gz by Rufus, start C2, go through annoying resize process, then
then just edit boot.ini (
disk=UUID=<UUID USB Flashdisc ext4 partition>) and plug USB. But Ive run into issues linked above (just when restarting, cold boot seems to be OK).
Did something changes nowadays, when only .gz images are created? Is there any additional checks? Maybe also C2 related issues, things to solve? Anyone running SD+USB combination to preserve SD card failures / improve speeds, when SD card is small cheap class 4 card?
I can extract fat partition from .gz image, thats not a problem, for skip resize proces on device. It just seems that there is something around that, what I missed and wasnt required before…
Anyone? I did also LABEL corrections (although boot.ini uses UUID in my understanding):
/dev/mmcblk0: PTUUID="7d92d6b8" PTTYPE="dos"
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="COREELEC" UUID="FD4E-CF00" TYPE="vfat" PARTUUID="7d92d6b8-01"
/dev/mmcblk0p2: LABEL="SD_DATA" UUID="f0b7b6ca-22a8-d401-d0b1-b2ca22a8d401" TYPE="ext4" PARTUUID="7d92d6b8-02"
/dev/sda1: LABEL="STORAGE" UUID="f4eb8747-1463-d101-f088-86471463d101" TYPE="ext4"
but this is still happening
You should be using a class 10 SD card
I bought couple of new UHS1 / 10 sd cards (Kingston, Sandisk), but it happens with them also. Now I am testing another thing, I set USB Storage partition as Active (and have PARTUUID). Couple of first reboots went well, but its needed to test more… Its always worst, when someone doesnt have 100% metod, how to reproduce the problem and it pops out “randomly”
I don’t know how things work with the C2 but, when I was booting from SD and using USB for data, I simply created the install on the USB drive, copied the contents of the dos partition to a FAT formatted, correctly labelled, SDcard (with only 1 single DOS partition) and then deleted the 1st partition on the USB stick.
It worked without a problem for me, no idea if the C2’s layout would allow it to work for you.
Thanks for the tip. I saved it to my “knowledge base” and I think, it deserves place in your Installation guide
So far, still all “hot reboots” went fine I will try this (USB–>SD, instead SD–>USB way), if the problems gets back (hopefully not) - which would means Active partition didnt do the trick.
I have to ask, If you are going to try booting from USB what would be the advantage of using SD for data? If booting from USB why not just sue USB for data as well?
I am not booting from USB (I am not sure, if Odroid C2 is capable of it, I am used that Rpi cant boot from USB and I assume it will be similiar on C2), I boot from SD Card, and just using USB for the data (storage), because I have bad history with SD Card corruptions @Rpi, which never happens, when I using USB stick for storage instead.
(USB–>SD, instead SD–>USB way)
this I meant just for description of "preparation partitions manually vs by img.gz resizing… meaning, for which (SD/USB) I use Rufus, and for which I copy/prepaer data manually.
Ahh, OK, I see what you mean.
Well - good luck, as I said, it worked for me. It actually worked, in my case, if I prepared both USB and SD, deleted the second partition from the SD and left the USB intact.
Since the boot process searches the SD first, the system booted from there and not finding a data partion on the SD, used the one found on the USB.
So far still good on two installations. I would call that as Active Partition (boot) flag missing (apaprently needs to be set on both USB & SD partition, without it behaves strange only on hot boots). Will do more installation in future so it will be proved then also (hopefully)
Looking good, fingers crossed!
Interesting. I decide to try the “official” update method to latest CoreELEC. I backuped SD+USB content. And I was surprised, that the same kind of “hot boot” error follows immediatelly, after files was updated and C2 rebooted.
I did cold boot, and see, what files was changed. And I found, that
boot.ini was edited, it keeps my custom
disk=UUID= (fortunatelly!! I was afraid about this change), but the
coreelec variable was changed from my “
quiet rootwait” into default “
I put back rootwait, do a few hot boots, and C2 boots fine. So maybe this parameter could matter also. Is it possible to add rootwait as default coreelec boot.ini parameter, together with quiet? I dont think it could harm anything, I am using it since beginning (it was default on Rpi2 *ELECs I think).
For the record, I know about config.ini, which should handle “user” definition, but anyway, there is section which missing rootwait in description:
# CoreELEC variables
# Setup the CoreELEC options
# valid values are: textmode debugging progress nofsck nosplash noram overlay quiet ssh
are you running your setup still with or without issues?
Iam looking for some solution how to boot C2 from SD and then everything else having on USB but there is not really good post about how-to.
What I have done: Etched SB and USB with same image, inserted sd and usb into odroid and booted up. After partition resize i’ve checked blkid which shown usb and sd card uid the same -> shutdown, mounted sd and usb in another linux system. Then removed STORAGE partition from SD and removed CORELEC partition from USB (+ resized by empty space).
Then inserted all back and it just works. No issues so far.
Are you doing USB->SD approach or SD->USB?
I didnt do this longer period, but as far I remember, it doesnt matter, both should work. Things which I take care when I doing initial install (and check after every update) are:
-Name of storage partition: STORAGE
-uuid of storage partition: to match the one on USB
-boot flag (parted -l)
On installations outside of my home I still include HW switch to power, just in case, it would freeze in some hot boot.
If you tested and have running system, you should be allright (I didnt notice any runtime error due to USB based storage).