I’d like to boot coreelec directly off a hard drive. I can just extract the image onto the hard drive with balenaetecher, but it drops the data on there with an MBR partition table, which wont grow the storage partition large enough to fill up this drive. I haven’t been able to bodge together a GPT install so I’m kind of stumped. Surely someone else has already managed to do this.
well, that proves it can be done, but wit no documentation, its just some video.
Video that shows you the steps.
The only thing that you might need to know is what software they were using, which you could ask in the YT comments section.
I tried to reproduce those steps. Coreelec refuses to resize the storage partition and doing it in gnome disks does something weird to the drive that makes it unreadable after 1 use.
There is a post over at the Odroid forums from the user that created the video, so you could ask him more about the process directly there too.
This would be easier if I had a better understanding of partition mount creation. How does coreelec build the boot.ini? Where does it get that information from?
You have a person who has done exactly what you seek to achieve and has additionally provided evidence and a process for doing so.
You have some questions on areas that may be missing from the video in order that you can understand the whole process.
You have 2 direct avenues for which you can ask these questions directly from the proverbial horses mouth.
For the sake of a few minutes work, you seem to be in an ideal position to achieve your goal.
But you seem to want to go, what seems to me, in some indirect, illogical route.
I don’t know what you are talking about, my main CoreELEC or LibreELEC server has always worked with boot from an SSD hard drive. I have never had any problems. To do this I have always used Rufus (or with the LibreELEC installer) although I suppose that with Etcher you will not have any problem either. After the first boot with the hard disk I have checked the partitions with linux ‘gparted’ without modifying the structure of the COREELEC / LIBREELEC partition and resized the STORAGE partition to my liking. As the partition table is MBR, this hard drive may not be usable on some PCs to boot another operating system that requires EFI.
Things are learned by doing them.
I am the owner of the subject, let me help as much as I can.
I don’t know English at all. I am trying to express myself with the translation, there may be a loss of meaning in my expressions.
But the logic is simple.
You have to install Coreelec on the uSD card and boot with the uSD card. So you should have Coreelec working.
The CE on the uSD card consists of two parts, you have to clone both parts as I explained in the video. You should move the clone images you get to the appropriate partitions that you created on the SSD. I think I explained it in detail in the video.
No matter where you indicate where you do not understand, I will help.
Edit:
I made this video with Ubuntu-20.10 installed on HC4.
Programs I use:
gnome-disk-utility and Gparted
2 Likes
Thank you for replying. The translation is working well and I understand you clearly.
The hard drive I am using is too large to dump an image directly to. The coreelec setup fails to utilize the space of the entire drive because CE uses MBR instead of GPT. However, if I clone individual partitions like you have and dump them on to a GPT-partitioned hard drive, it does see them. I can run a command to resize. But the resize takes a long time and ultimately fails.
So instead of continuing to try to make that work, I’m trying to figure out how CE works when it is booted for the first time off an SD card.
First, I discovered there are things I can manually change and CE can still understand. First, if I ditch MBR and use GPT, that works. If I change the FAT partition to an EXT4 partition, that works. If I go into boot.ini and change UUIDs to match partitions I make manually and copied files into, CE still works.
So far, it looks like me doing this manually would be best, but there is a problem. If I went to update this later on, the update would be applied onto an environment that CE might not expect and could break things. To prevent that, I need to learn how CE first expands that partition and what it decides to put in boot.ini. Where is the step that identifies partition UUIDs and drops them into the appropriate lines of boot.ini?
Ultimately, what I want to do is a manual install that’s done cleanly enough that future upgrades will install without additional tampering.
I use the method I mentioned in the video in many SBCs.
For example, in N2P 240gb ssd, CE 2.9.7, CE 19.1, Ubuntu .20.04, ubuntu 20.10 gnome, ubuntu 20.10 kde, wayfire installed.
CEs night versions are updated daily. other ubuntu versions are also updated frequently.
I had no problem.
HC4 also has two CE versions and 3 separate Linux OS installed and constantly updated. I haven’t had any problems so far.
I’ve been using my SBCs like this for two years.
On Ubuntu, I never needed to change uuid for clones I made with gnome-disk-utility and Gparted.
This method is actually very simple plain logic and works well.
You need to understand how it works and take a few tries. I’m sure you’ll try this method often afterwards.
Edit:
Actually gnome-disk-utility does all the work. I just use gparted to expand the disk to normal sizes.
This is what CE does on first boot with an SD card image:
Basically it expects the /storage partition is #2. The process @istanbulls outlined is doing the first-boot resizing on the SD card, and then he transfers the partitions over to an SSD and resizes them additionally there.
Assuming your SSD is seen as a USB device, then I am assuming u-boot script will look for the first FAT partition on device 0, and it appears from there it uses labels to find the right partitions:
/dev/mmcblk1p1: SEC_TYPE=“msdos” LABEL_FATBOOT=“COREELEC” LABEL=“COREELEC” UUID=“0203-5727” BLOCK_SIZE=“512” TYPE=“vfat” PARTUUID=“eea5c436-01”
/dev/mmcblk1p2: LABEL=“STORAGE” UUID=“cfecea0e-9dbd-4955-b958-f99129613a5a” BLOCK_SIZE=“1024” TYPE=“ext4” PARTUUID=“eea5c436-02”
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.