newspaint

Documenting Problems That Were Difficult To Find The Answer To

Monthly Archives: May 2016

Xubuntu and System Freeze/Hang After Entering Password On Wake From Suspend

On an Asus S400C running Xubuntu 14.04 Trusty Tahr I was having a problem after waking from suspend. The computer would wake up, I would tap a key to bring up the display from blank, and it would offer me to type in my session password.

If I typed a session password wrong it would tell me, but if I typed the session password right the system would freeze (the fan would turn on indicating maybe heavy CPU use) and no key combination would do anything (including ctrl-alt-F2 to switch to another terminal).

Well, I don’t know why this was happening, but it seems to have been down to the light-locker package. So I removed it.

$ sudo apt-get remove light-locker light-locker-settings
$ sudo apt-get install gnome-screensaver

The computer now allows me to log in after suspend but I have to type in the session password twice.

Cloned My Drive, Now Grub Cannot Find LS Command

You’re sitting looking at a basic grub prompt. You type in “ls” in the hope you see something:

grub> ls

Error 27: Unrecognized command

grub>

Well, I don’t know how you can fix this (get the ls command back). But I did figure out how to boot my cloned drive. And the tab key is your friend. If you type “root” you can find out information about your current drive, but the key is to hit tab twice after entering slash after a command such as “kernel”.

You hit the following commands:

grub> kernel /vm[tab]linuz-3.13.0-[tab][tab]
vmlinuz-3.13.0-55-generic  vmlinuz-3.13.0-86-generic
grub> kernel /vmlinuz-3.13.0-86-generic
grub> initrd /initrd.img-3.13.0-86-generic
grub> boot

Now if the boot seems to go successfully enough but you’re using crypto/encryption/dm-crypt/LUKS – then you might get a BusyBox prompt after you successfully enter your crypt partition password:

(initramfs)

If this happens then you need to specify, to grub, on the kernel command line, where your root is. In my case root is found on the /dev/mapper/crypt device after decryption which must be subsequently mounted by Linux.

So to boot successfully I reboot and enter the following into grub:

grub> kernel /vmlinuz-3.13.0-86-generic root=/dev/mapper/crypt
grub> initrd /initrd.img-3.13.0-86-generic
grub> boot

Restoring SELinux Labels After Restoring From Data Backup To Android

So I made a major error of judgement and tried to put Marshmallow CyanogenMod 13 onto my LG G3 (d855). Sure, for a while it raced along nice and fast, but in the end turned into an utter disaster when, overnight, it decided to go into an endless CPU loop resulting in rebooting every 10 minutes or so back into another CPU loop. Making the phone very hot and essentially useless. Well enough of that long story. I tried to downgrade using a backup I made earlier back into Lollypop CyanogenMod 12.1.

But K-9 mail was not starting.

I ran:

# adb root
# adb shell
root@d855:/ # logcat |grep com.fsck.k9
W/com.fsck.k9(13997): type=1400 audit(0.0:2058): avc: denied { write } for name="preferences_storage" dev="mmcblk0p43" ino=530653 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
E/SQLiteDatabase(13997): Failed to open database '/data/data/com.fsck.k9/databases/preferences_storage'.
E/SQLiteDatabase(13997): 	at com.fsck.k9.preferences.Storage.openDB(Storage.java:47)
E/SQLiteDatabase(13997): 	at com.fsck.k9.preferences.Storage.loadValues(Storage.java:180)
E/SQLiteDatabase(13997): 	at com.fsck.k9.preferences.Storage.(Storage.java:203)
E/SQLiteDatabase(13997): 	at com.fsck.k9.preferences.Storage.getStorage(Storage.java:158)
E/SQLiteDatabase(13997): 	at com.fsck.k9.Preferences.(Preferences.java:40)
E/SQLiteDatabase(13997): 	at com.fsck.k9.Preferences.getPreferences(Preferences.java:27)
E/SQLiteDatabase(13997): 	at com.fsck.k9.K9.onCreate(K9.java:578)
E/AndroidRuntime(13997): Process: com.fsck.k9, PID: 13997
E/AndroidRuntime(13997): java.lang.RuntimeException: Unable to create application com.fsck.k9.K9: android.database.sqlite.SQLiteException: not an error (code 0): Could not open the database in read/write mode.

Turns out that first line from the log there is SELinux denying write access to the file.

I discovered I needed to run the restorecon command which would apply the necessary labellings for the files in /data/data using the rules in /file_contexts.

# adb root
# adb shell
root@d855:/ # restorecon -Rv /data/data/com.fsck.k9

But there is another reason why an application may be unable to access its database. Wrong user. What user does an application run as? That is found in /data/system/packages.list:

root@d855:/ # grep com.fsck.k9 /data/system/packages.list
com.fsck.k9 10076 0 /data/data/com.fsck.k9 default 3003,1028,1015

So with that information I could set the owner of the data files to that required by the application:

root@d855:/ # chown -R 10076 /data/data/com.fsck.k9