Unfortunately I don't still have that SD card loaded. But I doubt it since at least 98% of the time I'd do a setenforce 0 when I logged in. It's a step in the right direction and if nobody else is having the same problem then mine was a unique screwy case.
I was getting random reboots and other problems so I haven't tried running Linux at all lately, now I've got an uptime of 15 days running just Android. I physically lost one of my micro SD cards and had reformatted this one to run NetBSD on my Raspberry Pi with. I'm still not sure the card itself is OK even though it's a Sandisk 128 gig that's only a couple months old. Trying to load NetBSD has crashed my laptop at least twice with the card plugged into a USB card reader in it. On 3/16/16, Guillem Jover <guil...@debian.org> wrote: > Hi! > > On Tue, 2016-03-08 at 02:03:29 +0100, Guillem Jover wrote: >> On Thu, 2016-01-14 at 23:57:28 -0500, Alan Corey wrote: >> > Package: dpkg >> > Version: 1.18.1 >> > Severity: normal >> >> > I'm using armhf Debian on a phone, NOT in a chroot, by using basically >> > an >> > adapted Debian Kit to get Jessie instead of somethiing old. Almost >> > everything I install gives the error message "security labeling handle: >> > no >> > such file or directory". I found on the web a workaround of sorts by >> > remounting /sys/fs/selinux readonly during the installation, but this >> > causes >> > Android to panic and lock up after about 1 minute. Normally this works >> > in a >> > terminal emulator or over a VNC or SSH connection concurently with >> > Android >> > apps. Old versions of Debian from a year ago didn't have this problem, >> > and >> > it may be compunded by the fact that Android shipped with selinux in >> > permissive mode until 5.0. Going to permissive mode has little affect >> > on >> > the problem. >> > >> > It seems to come from src/selinux.c which is where the error message can >> > be >> > found. It seems like at least if you set selinux to permissive this >> > should >> > only be a warning, not stop the install. Or maybe it could be a new >> > --force >> > option to dpkg. >> >> Right, that makes sense, and I wrote a patch to add such --force >> option when you filed the bug report, but one problem is that >> dpkg-statoverride also sets SE labels, and dpkg would need a way to >> pass the force option somehow to the child program. Which means >> programs might still fail. :/ >> >> But I could certainly try to make it non-fatal on non-enforcing mode. > > Does the attached patch fix the issue for you? > > Thanks, > Guillem > -- Credit is the root of all evil. - AB1JX
