Boot from the installer USB and the syslinux boot prompt type "run" .. and instead of running the installer it will convert itself into a "LiveUSB" with persistent storage. Then configure the laptop boot order to prefer USB .. job done. We do not recommend repartitioning the HDD, although that's mostly selfish and because if/when users screw something up we have no interest in walking them through the process of fixing things.
Posts by chewitt
-
-
It uses an Allwinner H3 chipset that we don't currently support. It has a physically different board layout and other different technical features (it is not a clone of the Raspberry Pi despite their claims). It runs an unofficial aka community created version of LibreELEC (or OE) that we have zero knowledge or experience with; but it will be running the ancient (and crap) BSP kernel which is known to have a ton of problems. The best place to ask your question would be the OPi forum or the forum/place you downloaded the image from.
-
The Generic image should run on those boxes. The one caveat is that some BayTrail/CherryTrail devices require a 32-bit EFI bootloader and since ours is 64-bit the normal installer USB fails to boot. There is an image here Sendspace.com Mobile File that someone created with a different 32-bit bootloader (GRUB probably). If our installer doesn't work, use the alternative one to make the initial install, then update to the latest releases afterwards. The bootloader is only installed once, updates don't change it once installed.
-
infoalter do you have normal user account in Windows, or a "Microsoft ID" account, e.g. [email protected]?
-
But personally I don't see why those two should not be implemented:
That's because your Intel hardware works. Other Intel hardware has issues that were not previously present and that's not acceptable in a beta or final release build. This needs to be tested properly, and when it's ready we'll work it into an appropriate release.
-
If Samba does not start you have a v3 config file that needs to be removed or updated to the v4 template. Please read the release notes.
-
All recent LE versions have checking in the update process to detect current project/arch and if the update file doesn't match it refuses update. Did you update from OE (which doesn't have that)?
-
I'm confident there are plenty of unknown and unresolved bugs lurking in our codebase .. life isn't perfect
Comparing 8.1.1...libreelec-8.2 · LibreELEC/LibreELEC.tv · GitHub is all the stuff we added since 8.1.1, there will be an 8.1.2 release.
-
Just wondering if there will be an update to Libreelec 8.1.0 so we can get Krypton 17.4.
how about 8.1.1 that was released nearly three weeks ago?
-
8GB is a sensible minimum for the /storage partition if media stored elsewhere
-
It probably won't happen often, but it will eventually happen if you pull the power all the time. Just implement a backup scheme so it's a mild inconvenience when it does.
-
That URL contains source packages that need to be self-compiled into an OS image: compile [LibreELEC] - Neither LE or previously OE has ever supported ISO install - only USB. Our USB/SD creator app can make the USB from the self-compiled image.
In case it's not obvious, we have no desire to support i386 hardware so without intending to sound rude; this is either something you figure out for yourself or quit the idea of recycling ancient hardware and invest in a cheap Raspberry Pi kit that will be 20x better to use.
-
There's method to our release management approach but people have busy day jobs. We've accumulated quite a few changes since 8.1.1 so there's likely to be an 8.1.2 beta before 8.2.0 .. but that makes zero difference to inputstream.adaptive which is already at the current latest version in the 8.2 repo (used by 8.1.0/8.1.1 releases).
-
Just to comment: Testing shows issues with the current iteration of patches so this probably isn't resolved until an 8.2.x maintenance update. We aren't going to rush the fix, it needs to be complete and stable before we include it.
-
It works on some hardware and not others and appears to play nicer with our 9.0 codebase than 8.2. There is already a second iteration of patches in circulation and I'd expect further ones until a stable set are figured out. We have provided detailed feedback to the Intel driver team and will be tracking this (as we have been for months already). It is unlikely to be fixed in the initial 8.2.0 release, but hopefully things get resolved and we can add patches in a maintenance update.
-
Failing that, I wonder if it would cut down the number of potential builds if you were to build at "half-way" points each time. That is an approach I've used for solving similar problems before. Then we would know whether to go higher or lower than the current commit - again picking a half way point and checking the build. It's only an idea and I'm certainly no expert in this area - just thinking aloud.
^ that's what git bisect does; you mark a good and bad commit and it starts halving the list of commits until you find the problem one
-
could not mount LABEL-LIBREELEC'
disk=LABEL=LIBREELEC not disk=LABEL-LIBREELEC .. ^ typo?
-
You can grab the driver, create a new driver package for our build-system, then include it (fixing any compile issues found) and self-build yourself a new LE image. Or.. you can go swap it for something with a supported chipset. And before you ask, there is no list of supported chipsets.
