Forum

do it in Windows, Linux, any other system

… that's why we are booting directly to bash. to go around non-active root account.

(21st Dec, 2013 07:11 AM)mk01 Wrote: [ -> ]edit /boot/cmdline.txt and add "init=/bin/bash" at the end of line
reboot
xbian will boot directly into command prompt with root privileges
run commands:

Code:

for f in bin etc lib media mnt opt root sbin usr var xbmc-backup; do chown -R root $f; done
chown root:root /home
chown syslog /var/log/*
chown -R man /var/cache/man
chown -R xbian:xbian /usr/local/share/xbmc/addons/plugin.xbianconfig
chmod 4755 /usr/bin/sudo

then update cmdline.txt again - just revert to previous content (remove init=/bin/bash)
after restart

Code:

sudo dpkg-reconfigure -a

Good morning mk01,
the procedure was fine good and xbian is back again.
I was not able to change the owner to /usr/local/share/xbmc/addons/plugin.xbianconfig because the file was not present, but I guess is not important.

Said that, do you have any idea about the root cause?

Thank you

@Xenon

plugin.xbianconfig error (files missing) is ok: new version of package has files at /usr, older still at /home. within /home xbian:xbian ownership is desired. it was listed just in case you would have -dev version installed already.

glad to hear that it was ok. reason is clear, mistyped "sudo chown -R xbian /" instead of (./). normally I would say user error (and with this definition "user error" I also include any 3rd party addons/scripts with bug) but easily could be programmer error with such typo in official package's install/maintenance scripts.

I remember I was already checking all scripts for XBian's regular packages - all "chown" calls one by one. generaly we use chown xbian:xbian in XBian's scripts (user and also group would have been changed) and on your XBian just user as owner was changed.

what we can do is just wait if this happens again, please let me know. I will look into your XBian then or ask for some specific logs. otherwise there is not much to do now. so stay in touch !

Hi MK01,

it happens again, the only activity was system update (apt-get update && apt-get upgrade) that was ok.

If needed dpkg.log here: http://pastebin.com/fAa7iD92
source.list: http://pastebin.com/60JiSkme

Even I've again this problem XBMC and actually all system is stable and working (trasmission is working as well as playing movie) while when I had the issue before XBMC quit after few minutes of activity.

If I try to be root, I've set password after having the system working, I have this error:


Cheers

the error will be again caused by setuid bit but non-root ownership.

i will check the packages there in log. in between, can you post this more:

(22nd Dec, 2013 12:03 AM)mk01 Wrote: [ -> ]the error will be again caused by setuid bit but non-root ownership.

i will check the packages there in log. in between, can you post this more:

Code:

find /home -type l
find /media -type l

Now I had to change again the HD with NTFS one, long story.
So, using this NTFS (the previous one was extFAT) disk XBMC close (crash???) after few minutes from the boot. This behavious is the same I had when I reopen the post and also in that case I was using NTFS disk (another one). I suspect then this issue with NTFS filesystem make the entire system more unstable.

Back with you request:

I checked the two xbian packages and there is no ugly chown. -config-shell is doing chown twice on file, no directory, without -R (descent into hierarchy) and is doing xbian:xbian - so setting group as well.

will think about it

In
Why not:

because group wasn't changed by the headphone startup script.

(22nd Dec, 2013 05:44 AM)mk01 Wrote: [ -> ]because group wasn't changed by the headphone startup script.

That seems to be the case, but things still seem strange... take another look at my root perms, you can clearly see that they have the root:xbian ownership, which isn't correct - or is that correct?

if you mean there http://forum.xbian.org/thread-1922-post-19065.html#pid19065

then looks perfeclty ok for me (ok, beside the xbian uid as owner).

(22nd Dec, 2013 10:06 AM)mk01 Wrote: [ -> ](ok, beside the xbian uid as owner).

You mean "xbian gid as owner", yeah?

That's exactly what I'm talking about - xbian shouldn't own those folders, either as user or group, and the fact that that gid is the owner of those directories leads me to think maybe some other process did something similar to the headphones startup script? Otherwise, how did that happen?

@Xenon and @d4m4s74 - what about you're perms of the top level root folders? What is the gid of the owner?

no, i mean uid. the listing is

UID : GID

xbian : root is user xbian group root. that is in line with the headphones (chown -R xbian = change user only, leave group as is).

(22nd Dec, 2013 11:22 AM)mk01 Wrote: [ -> ]no, i mean uid. the listing is

UID : GID

xbian : root is user xbian group root. that is in line with the headphones (chown -R xbian = change user only, leave group as is).

Oh, duh, I should have looked more closely... I transposed those.

What do you think of using root:root when resetting the perms?

there are many services / daemons running with different groups (input / video / rsyslog) where access should be restricted - owner is in general root, but service / daemon write access is managed through group.

you would break these. and again, the headphones startup script was changing just the user.


output is there (all files with non-root uid ownership) http://pastebin.com/hmTBBwTN

---

system was Raspbian, with XBian .deb packages installed