[BUG] LibreELEC corrupts ChromeOS installed on a different drive

[yds]

Describe the bug

When LibreELEC is installed on one drive and ChromeOS is installed on a different drive of the same system using BIOS to select the boot device, i.e. the two OSes are not aware of one another, not even on the bootloader level, ChromeOS will get corrupted and goes into a bootloop after LibreELEC boots up at least once. Prior to booting LibreELEC, ChromeOS on the other drive works as expected.

All it takes is booting into LibreELEC just once to render ChromeOS on the other drive unbootable.

To Reproduce

Steps to reproduce the behavior:
Install LibreELEC on one drive of an x86 system
Install ChromeOS on the second drive of the same system
Boot into ChromeOS -- all good
Boot into LibreELEC -- all good
Boot into ChromeOS -- all fubar -- goes into a bootloop

Informations

• LE Version: 9.2.6
• Hardware Platform: Generic x86

Additional context

tried this on a LivaX2 box, doesn't matter if I install ChromeOS or LibreELEC to the internal eMMC or the M.2 SSD -- LibreELEC finds the ChromeOS partitions on the other drive and does something to corrupt them. If all I do is install LibreELEC on the other drive but never boot into it then ChromeOS keeps working fine, therefore it is not an issue with the LibreELEC installer. Actually booting into LibreELEC is what triggers the corruption on the drive LibreELEC is not installed to.

[chewitt]

@MrChromebox any ideas? .. I'm wondering if the fsck in init touches anything? but then if it did, I'm sure we'd have seen lots more issues reported as Chromebox devices are fairly common.

see https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/sysutils/busybox/scripts/init#L36

[chewitt]

nb: if you add nofsck to boot params, it will prevent this check

see https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/sysutils/busybox/scripts/init#L1018

[MrChromebox]

@yds what do you mean "Install ChromeOS on the second drive of the same system." If you're using some hack to run ChromeOS on an unsupported device, all bets are off.

[yds]

@yds what do you mean "Install ChromeOS on the second drive of the same system."
If you're using some hack to run ChromeOS on an unsupported device, all bets are off.

I'm using the NeverWare CloudReady USB installer to install ChromeOS
https://www.NeverWare.com/freedownload#home-edition-overview

it seems to me that LibreELEC finds random FAT32 partitions on the ChromeOS drive and mounts them and after that ChromeOS will no longer boot.

one of the partitions LibreELEC auto-magically mounts is the ChromeOS EFI partition.. not saying that the EFI partition is getting corrupted, but the reproducible part is if I install both NeverWare's ChromeOS and LibreELEC on two different drives on the same box ChromeOS will work like a charm so long as I never boot LibreELEC -- if I boot LibreELEC and allow it to auto-mount whatever it finds then ChromeOS will reboot loop until I stop it.

[MrChromebox]

CloudReady is not ChromeOS, it's just derived from the same OSS project (ChromiumOS) but there are a ton of differences.

[yds]

CloudReady is not ChromeOS, it's just derived from the same OSS project (ChromiumOS) but there are a ton of differences.

understood. However it is clearly LibreELEC causing corruption of another OS on another drive. The corruption happens while LibreELEC is running. installing and never running LibreELEC does not cause any corruption.

when I open the File Manager in LibreELEC I can see a bunch of drive partitions mounted which belong to the CloudReady drive.

I suspect that if LibreELEC did not auto-mount all those partitions then CloudReady would continue to function problem free.

[MrChromebox]

I suspect that if LibreELEC did not auto-mount all those partitions then CloudReady would continue to function problem free.

probably, and I'm sure there's a way to blacklist the drive, or disable auto-mounting, just not sure what it is. Nor why simply mounting the partition would cause an issue.

[yds]

I figure the auto-mounting is there to make it easier for users to get to their media on whatever they happen to plug into a LibreELEC box.

Seems like in this edge use case, LibreELEC is a little over zealous in the quest to make things easier for users.

If LibreELEC had a knob somewhere to exclude a drive from auto-mounting that would very likely solve the problem.

[HiassofT]

We use udevil to auto-mount drives, the 95-udevil-mount.rules udev rules controls which drives/partition get auto-mounted.

You can either create an empty 95-udevil-mount.rules file in /storage/.config/udev-rules.d (that will disable auto-mounting completely) or copy the existing one from /usr/lib/udev/rules.d/ there and tweak it.

We already exclude some partitions from being auto-mounted, see here: https://github.com/LibreELEC/LibreELEC.tv/blob/libreelec-9.2/packages/sysutils/udevil/udev.d/95-udevil-mount.rules#L8-L10

# check for special partitions we dont want mount
IMPORT{builtin}="blkid"
ENV{ID_FS_LABEL}=="EFI|BOOT|Recovery|RECOVERY|SETTINGS|boot|root0|share0", GOTO="exit"

If you find out which partition / label is the problematic one we can probably extend that rule.

[yds]

If you find out which partition / label is the problematic one we can probably extend that rule.

@HiassofT thx.. that's perfect. lemme see what I can figure out and I'll report back.

[yds]

@HiassofT SOLVED! adding the labels in the diff below keeps LibreELEC from auto-mounting and corrupting any of the CloudReady ChromeOS partitions on the other drive.

--- /usr/lib/udev/rules.d/95-udevil-mount.rules 2020-10-25 10:59:44.000000000 -0400
+++ /storage/.config/udev.rules.d/95-udevil-mount.rules       2020-11-19 18:00:15.000000000 -0500
@@ -7,7 +7,7 @@

 # check for special partitions we dont want mount
 IMPORT{builtin}="blkid"
-ENV{ID_FS_LABEL}=="EFI|BOOT|Recovery|RECOVERY|SETTINGS|boot|root0|share0", GOTO="exit"
+ENV{ID_FS_LABEL}=="BOOT|EFI|EFI-SYSTEM|OEM|ROOT-A|H-STATE|STATE|Recovery|RECOVERY|SETTINGS|boot|root0|share0", GOTO="exit"

 # /dev/sd* and /dev/mmc* ith partitions/disk and filesystems only and /dev/sr* disks only
 KERNEL=="sd*|mmc*", ENV{DEVTYPE}=="partition|disk", ENV{ID_FS_USAGE}=="filesystem", GOTO="harddisk"

thx for pointing out where to fiddle with the settings.

[HiassofT]

Thanks a lot for reporting back!

"EFI-SYSTEM" sounds like it could be safe to add to the default list, but the other labels not so much - we have to keep that list as short as possible, otherwise users will complain that their drives don't mount.

I'm wondering a bit if this NeverWare CloudReady OS is maybe hibernating instead of doing a full shutdown, in that case mounting the partitions from LibreELEC (or any other OS) could have catastrophic effects.

[yds]

I'm wondering a bit if this NeverWare CloudReady OS is maybe hibernating instead of doing a full shutdown,
in that case mounting the partitions from LibreELEC (or any other OS) could have catastrophic effects.

I doubt that's the case.. NeverWare CloudReady ChromeOS gets corrupted if LebreELEC auto-mounts any of the partitions when:

1. CloudReady is installed first and the box shuts down.
2. LibreELEC is installed on the other drive and booted after install.
3. CloudReady will not boot even tho it was never booted in the first place and never had a chance to hibernate.

donno what it is, but now that I know the workaround, this is not a showstopper for this install on the LivaX2 box.

might be worth putting https://GitHub.com/LibreELEC/LibreELEC.tv/issues/4668#issuecomment-730495693 in the docs -- woulda taken me much longer to figure this out without getting clued in like that. thx again!