Installation fails: Error in prepare_sysroot

Jake_UK · November 16, 2018 at 4:44 PM

Hi all,

I'm having difficulty installing LE on my HTPC. I'm using the LE USB creator and have tried Generic AMD/Intel/NVIDIA (x86_64) v8.2.5 and v8.90.007 images.

It's a HTPC I built a few years back built around an AMD A-10 5700 currently running OpenElec installed on an SSD. I'm trying to replace OpenElec with LibreELEC.

I boot from USB on the HTPC and I wait for the installer to run, I get the LibreELEC splash screen and after a few seconds over the top of the splash screen I get the following error messages:

Code

*** Error in prepare_sysroot: mount_common: Could not mount /dev/SYSTEM ***
### Starting debugging shell for boot step: prepare_sysroot... type exit to quit ###

# exit

mount: mounting /flash on /sysroot/flash failed: No such file or directory
mount: mounting /storage on sysroot/storage failed: No such file or directory
*** Error in prepare_sysroot: final_check: Could not find systemd! ***
** Starting debugging shell for boot step: prepare_sysroot... type exit to quit ###

# exit

Display More

After that 'exit' I get pages of stuff dumped to the screen!

Any ideas what the issue is?

TIA

**Iridium** · November 16, 2018 at 5:47 PM Official Post

Are you trying to install on the same SSD as openELEC? as this might be the issue.

Depending on your version of OE you should be able to just upgrade to LE from your OE system.

**Klojum** · November 16, 2018 at 5:51 PM Official Post

OpenELEC has a smaller system partition than LibreELEC has these days. So a simple cross-upgrade won't work.

A fresh install of LibreELEC will create the properly sized partitions.

Jake_UK · November 16, 2018 at 9:20 PM

Yes, I want to do a clean install onto the SSD that currently has OE on it. I'd rather do a clean install than an OE to LE upgrade if possible anyway.

However, I can't see how I can do a fresh install if the installation process fails before I get any kind options presented to me...?

**Klojum** · November 16, 2018 at 9:38 PM Official Post

You could also do a manual resize of the partitions using a tool like Gparted. BTW, I use 1GB sized system partitions for years now.

**chewitt** · November 17, 2018 at 3:22 AM Official Post

The original error is caused by the kernel boot= param being wrong or (more likely confused) so it fails to mount the partition with the SYSTEM file and dumps you into the initramfs debug shell (which is pretty limited). If you're installing this doesn't make sense because the entire install process runs within the initramfs environment (in the KERNEL file) and you never reach the point in the boot process where SYSTEM would be required.

So I think the USB bootloader is finding boot params on the SSD (for normal boot) but then you have some kind of disk label clash that results in it failing to find the SYSTEM file and boot fails. If you already made a backup of the existing system and exported that off-box for safe keeping, boot from an Ubuntu LiveUSB and reformat the SSD (any format is okay) then try to reinstall.

Jake_UK · November 18, 2018 at 3:10 PM

I erased the partitions on the SSD by booting a Mint XFCE Live USB and GParted.

LibreELEC still produces the same error though. I tried this booting the USB in both EUFI and BIOS modes, same result for each.

Any ideas?

**chewitt** · November 18, 2018 at 3:24 PM Official Post

Once it fails and dumps you into the initramfs, mount a USB drive and dump "dmesg" and other content like "blkid" to text files, then share them via pastebin so we can see a bit more info on filesystems visible and the boot process.

Jake_UK · November 19, 2018 at 9:03 AM

dmesg isn't recognised/not found!

"ls /dev/sd*" finds the three drives - the USB stick, the HDD that holds my media and the (now blank) SSD:

Code

# ls /dev/sd*
/dev/sdc2 /dev/sdc1 /dev/sdc /dev/sdb1 /dev/sdb /dev/sda

"blkid" returns the USB stick and the HDD:

Code

/dev/sdc1: LABEL="LIBREELEC" UUID="0710-1617" TYPE=vfat
/dev/sdb1: UUID="8b8eefd4-e5ed-4aa1-a73a-1c5d84070b65" TYPE="ext4"

**chewitt** · November 19, 2018 at 12:40 PM Official Post

You might need to run ./usr/bin/dmesg instead of typing dmesg, but it's present in the environment.

Jake_UK · November 19, 2018 at 2:25 PM

I was in /usr/bin when attempting to run dmesg. The command "./usr/bin/dmesg" is not found either though.

"ls" in /usr/bin finds only :

busybox

ply-image

sh

**chewitt** · November 19, 2018 at 2:53 PM Official Post

run "./usr/bin/busybox dmesg" then and it should output something

Jake_UK · November 19, 2018 at 9:48 PM

Code

./usr/bin/busybox dmesg
dmesg: applet not found

**HiassofT** · November 20, 2018 at 10:20 AM

It seems we hadn't enabled the dmesg applet in the initramfs busybox binary.

I opened a PR to fix that, when it's merged busybox dmesg will work (this should hopefully be included in the next LE alpha version)

busybox: enable dmesg and less in init by HiassofT · Pull Request #3113 · LibreELEC/LibreELEC.tv · GitHub

so long,

Hias

**chewitt** · November 20, 2018 at 10:53 AM Official Post

merged

**mglae** · November 20, 2018 at 4:08 PM

You can use cat /proc/kmsg. The command must be terminated with <Ctrl>-C

Jake_UK · December 2, 2018 at 6:09 PM

Hi folks,

dmesg is indeed fixed in the latest release - thanks!

Here's the output of dmesg

**chewitt** · December 3, 2018 at 3:40 PM Official Post

Code

<3>[   13.496949] squashfs: SQUASHFS error: unable to read id index table
<6>[   13.497211] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0xc71e53f1)
<3>[   13.497214] F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
<6>[   13.497254] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x41e10784)
<3>[   13.497256] F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
<6>[   13.497265] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0xc71e53f1)
<3>[   13.497268] F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
<6>[   13.497270] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x41e10784)
<3>[   13.497273] F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
<3>[   14.533541] squashfs: SQUASHFS error: unable to read id index table

The good thing about packaging the entire OS into two files is you only have two files (not thousands). The bad thing is you have one byte of corruption in the image and the entire OS doesn't boot. The lines above indicate something is bad with the SYSTEM file - which matches the error message you're seeing.

I'd guess it's time for a new USB stick?