It's booting the kernel but the init script is not able to mount the squashfs SYSTEM file from the /flash (boot) partition. The normal reason is the filesystem being marked 'dirty' and it needs cleaning to boot normally. The less normal reason is corruption to the SYSTEM file which could be an early indicator of issues with the underlying storage media, e.g. the good thing about LE is the entire OS is contained in two files, but the bad thing about LE is the entire OS is contained in two files; corrupt either file and the OS doesn't boot (whereas a normal distro spread over several thousand files is more tolerant towards single-file failures). USB boot a desktop OS like Ubuntu and fsck the filesystems. If that's not the issue try dumping the 512MB boot partition using dd as that will attempt to read the data areas where the SYSTEM file is stored. The other reason this error shows up is the partition labels not being set, but if the box was already working that's rather unlikely (although discovering new stupidity with NUC firmware stopped being a surprise a long time ago).
Posts by chewitt
-
-
I'd go for the (s)lower grade of Crucial SSD's or whatever is on clearance sale because there is zero need for ultimate performance from fast SSD models on an HTPC box. Anything better than spinning rust is already awesome
-
LE uses connmand to manage network things, and connman supports configuration of DNS servers through dbus or the connmanctl local console interface which is scriptable but less sophisticated. Have a look at the LE settings addon for an example of a connman/dbus agent in python.
-
Correct, we don't build systemd with resolved support so it's not present. I guess the main reason is partly 'legacy' because when we first started to use systemd 'resolved' didn't exist, and since we have minimalist tendencies and the current arrangement works, there's never been a major reason to use/need it. I've always seen VPN services run up/down scripts, although that normally requires the VPN service conf to be modified to include those instructions. I'm not sure how you do connections, but I would always treat the user provided conf (or something from a known list) as a starting template that's copied to a working location and then parsed/modified to add features like up/down scripts before being 'executed' to start the connection.
-
Do you own/use an Xbox One DVB2 stick? .. if 'no' you can drop the patch from your branch and continue.
-
Using systemd to mount NFS shares instead of an autostart.sh hack will avoid numerous timing/sequencing issues. Looks at the sample .mount files in /storage/.config/system.d
-
Thanks for testing and confirming.
-
Official LE 7.0.3 releases have GUI support for manual updating to something newer (it was added in 7.0.3). The two reasons you won't be able to see something to update to (e.g. an 8.2.5 release) is either a) you're running an unofficial image and there's no equivalent project.arch version on our download server, or b) a network issue that stops you reading the JSON data file that lists all the available versions.
There are no partition size issues coming from an original LE 7.0.3 install to LE 8.2.5 as all our releases were 512MB. You might see them coming from a much older OE install where the partition sizes were as low as 160MB. That said, older installs will have accumulated enough cruft over time that spring cleaning by taking a backup and selectively restoring the bare essentials (the DB files that track watched status and sources.xml) to a fresh install is never a bad move.
-
I have searched the entire internet and only found it here on the subject "dtb".
You didn't look hard then, and this irrelevant (and old) thread is for support on our Linux distro not whatever Android thing you're hacking.
-
Would this work without typing in any commands? Only put my own cacert.pem in /storage/.config/ ?
That's the idea.
-
From our perspective TinkerOS has a large 'SEP' field around it
-
Go into Kodi settings (from home screen) not via the OSD and change default preferences there. Any different?
-
If you don't care about your problem enough to provide a log file when asked, we don't care enough about your problem either
-
Some people are stuck in the past and don't realise we abandoned OE in February 2016
-
No log = no problem in the pre-alpha unreleased software image that you found somewhere on the internet.
-
If restoring from within LE to a new card you need approx 2.5 times the backup file size in free space to perform the restore; because you have to copy the backup file to /storage first before the settings addon uncompresses the backup file during the restore process, and the OS requires some working buffer space during the archive extraction process. The backup file is just a standard .tar archive so there's no magic involved.
-
You can expect the occasional screen freeze or things can hang after using PVR functions for a while or when doing large jump backs on a media file as there are known (and not going to be resolved in K17) bugs and the underlying Linux kernel used in the 8.2 release has ugly moments.
The screen turning white with vertical lines and audio pops .. sounds more like a hardware problem. If you also see problems in Android it would point to something. How hot does it run? .. a heatsink is never a bad idea.
-
Yes/No depending on how you took the backup.
If you backed-up using our backup function you only copied the data within the filesystem (which is less than 16GB, usually not much more than 3-4GB even for a large media collection) so it should be quite simple to restore 3-4GB of data to a 16GB card. If you were inappropriately obsessed with "backing up the whole card" like most Pi users and you image dumped the full 32GB SD card, then no, you cannot restore the 32GB image to the smaller 16GB card without breaking the filesystem. It's still technically possible to break and then repair the filesystem, but that requires expert knowledge of filesystems and some software tools, and you need to hope all the data was within the first 16GB (likely, but not guaranteed).
If making backups, focus on the small amount of data on /storage, not the entire SD card. It's faster and easier to backup the ~4GB of data on the card than the full 16GB or 32GB of SD card which is mostly empty.
