-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[BUG] LibreELEC corrupts ChromeOS installed on a different drive #4668
Comments
@MrChromebox any ideas? .. I'm wondering if the fsck in see https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/sysutils/busybox/scripts/init#L36 |
nb: if you add see https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/sysutils/busybox/scripts/init#L1018 |
@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 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. |
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. |
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. |
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. |
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
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. |
@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. |
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. |
I doubt that's the case.. NeverWare CloudReady ChromeOS gets corrupted if LebreELEC auto-mounts any of the partitions when:
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! |
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
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.
The text was updated successfully, but these errors were encountered: