I am attempting to update the Wiki with as much basic information as possible, and would welcome any suggestions on priorities. So far I hope to accomplish the following:
- Upgrading to RC1
- Moving / to USB
- Backups and Images
- Troubleshooting common issues
- Setting up and using SSH
- FAQ
- cleaning up and adding to the existing info
- Switching to devel/staging repos
It will take some time to do this as I want all info to be as accurate as possible, and I need to compile a lot of info scattered through the forums. Please add anything you think of importance, and maybe rank it on a scale of 1-5 (with 1 being most urgent).
Thank you for your suggestions, and I will try to get moving on this ASAP!
dbum
ext disk auto mounting and all related functions/settings
sync/async mount parameter
ownership/access rights of existing/newly formatted drive
SAMBA autoshare / RO, fullRW, limitedRW
(24th Mar, 2014 06:38 PM)mk01 Wrote: [ -> ]ext disk auto mounting and all related functions/settings
sync/async mount parameter
ownership/access rights of existing/newly formatted drive
SAMBA autoshare / RO, fullRW, limitedRW
noted, however i think it is best (for now at least) to focus on what the average (noob) user needs to install and maintain a basic, functioning system. most new users will not even know what you just wrote means, and if they do they are resourceful enough to know how to work and search the forums.
for me, a wiki should give you everything you need to know to perform all basic (supported) out-of-the-box functions on a system without any modifications or hacks, and hacking and troubleshooting is left for the forum.
i'll still put it on the todo list though
Let me know if you need help writing the wikis, I would like to volunteer.
@
dharmabm
you would be surprised how often we answer question
- why i'm not allowed to write to my shared usb hdd ?
and answer is "there is a button in xbian-config XBMC"
(this just reminded me that I wanted to follow-up enable/disable checkbox in xbian-config XBMC to allow auto-resolution change on start/stop vnc-server. user's idea & most work done and result is amazing. normally RPI is too slow to manage resolution above 720x480 with xbmc and vnc. with this "feature" as soon as vnc is started, resolution is changed. on vnc stop, resolution is changed back!)
((so no restart, config.txt updates etc))
@
dharmabm
as I see topic upgrading to RC1.
I have the feeling I didn't post this but generally I would recommend installing xbian\* updates first, then the rest (upstream) packages.
the reason for this is that on most upstream issues (problems with startup scripts / debian helper scripts / or even conflicts like lately the python2.7 stuff) there are fixes implemented in xbian-update (or relevant packages). having them deployed BEFORE the other broken packages are installed will simply provide seamless non interrupted install like the bug would not be existing.
for instance the autofs package problem. autofs package installation was starting the service at the end of dpkg install. starting the service was dependent on present "autofs4" filesystem support. but because xbian-kernel with autofs4 support wasn't yet installed, autofs installation never finished apt-get was blocked. in case kernel would be updated first (among other xbian packages) at the time of autofs post install configuration autofs4 support would be already present and "stuck" would be avoided.
so maybe it would be worth provide this info in one sentence under the "updating xbian" paragraph.
(25th Mar, 2014 07:51 AM)mk01 Wrote: [ -> ]@dharmabm
as I see topic upgrading to RC1.
I have the feeling I didn't post this but generally I would recommend installing xbian\* updates first, then the rest (upstream) packages.
the reason for this is that on most upstream issues (problems with startup scripts / debian helper scripts / or even conflicts like lately the python2.7 stuff) there are fixes implemented in xbian-update (or relevant packages). having them deployed BEFORE the other broken packages are installed will simply provide seamless non interrupted install like the bug would not be existing.
for instance the autofs package problem. autofs package installation was starting the service at the end of dpkg install. starting the service was dependent on present "autofs4" filesystem support. but because xbian-kernel with autofs4 support wasn't yet installed, autofs installation never finished apt-get was blocked. in case kernel would be updated first (among other xbian packages) at the time of autofs post install configuration autofs4 support would be already present and "stuck" would be avoided.
so maybe it would be worth provide this info in one sentence under the "updating xbian" paragraph.
i'm glad you mentioned this, as i was going to suggest the opposite as referenced in
THIS post which seemed to work for me when i had trouble as few weeks ago. i will use what you write above instead (as soon as i test it 3 or 4 times
)
but we have to ask IriDium if this workflow "tried like this and just works" or there is any scientific/bug/fix/problem/error background.
ok, i've been doing some extensive testing the last few days since i picked up a spare pi on monday (hurray!), and i just made a few minor additions to the 'updating xbian' page. i haven't written wikicode in awhile, and am still struggling to find a consistent format to use, it will take some time to sort that out. i love the way the arch wiki is done, and would hope to do something similar.
i am going to start working on the backups/imaging page next, although i can't seem to get it to work myself as of yet, but i'll get there. also, i saw the post about the proper repos being documented, and will add that to the todo list.
let me know if anyone has any issues with the changes i made.
i know i said i was working on backups next, but i just added
Using the correct repos to the wiki... that was a lot simpler to complete, as i still cannot get imaging with xbian-copy to work correctly on RC1 (although it works fine on B2)
back to testing!
i just made a quick tutorial on using btrfs snapshots but have not added it to the index yet as i have not tested it myself to confirm it is as easy as it sounds, can someone with experience please have a look at
THIS PAGE to confirm its accuracy before i publish it?
thanks,
k
Yes this easy. Can you also explain how to create and restore snapshots from within xbian config xbmc? Also, depending on the changes made, you don't always have to reboot.
Keep up the good work!
(31st Mar, 2014 05:24 AM)CurlyMo Wrote: [ -> ]Yes this easy. Can you also explain how to create and restore snapshots from within xbian comic xbmc? Also, depending on the changes made, you don't always have to reboot.
Keep up the good work!
excellent, thanks - added to the index. not sure i fully understand your question (is 'comic' a typo) but i assume you mean doing it from within xbmc xbian-config addon? i will add that to the list.
k
Yes, i meant xbian-config.
(30th Mar, 2014 09:13 PM)dharmabm Wrote: [ -> ]i just made a quick tutorial on using btrfs snapshots but have not added it to the index yet as i have not tested it myself to confirm it is as easy as it sounds, can someone with experience please have a look at THIS PAGE to confirm its accuracy before i publish it?
peanut, ... isn't it ?
Just don't call it "restore" as it is not it. because snapshot is more like putting literally a sticker on state of your system (which you can go back to and live it again and again).
As you "rollbacks" to a different point, your actual state is preserved under name of rolled-back point with suffix _rollback (to which you can roll over again - with restore you rewrite all with the restored backup).
((and with snapshots and rollbacks there are actually zero data transfers))
Second point goes to "root" as in the example. "root" is limited to system files/applications/settings. it won't affect XBMC settings/library data/addons/addon settings. This is on "home". At the end not important for user so much until "higher functions" like xbianclone/backuphome is working as for user this is not visible.
But the split allows to restore system without touching XBMC and vice versa. "Backuphome" will take just /home/..... and restore just /home again on request. So for instance you want to do a "clean" upgrade from B2 to RC1. You will backup home in B2 (20-xxxMB file). After clean .img flash of RC1 you drop this file to XBian over network and after seconds/minutes XBMC restarts and you have back your XBMC (theoretically regardless of base system).
Again the tech is not so much relevant for the user. Until he is aware that "root" is not all-saver.
(3rd Apr, 2014 07:25 PM)mk01 Wrote: [ -> ] (30th Mar, 2014 09:13 PM)dharmabm Wrote: [ -> ]i just made a quick tutorial on using btrfs snapshots but have not added it to the index yet as i have not tested it myself to confirm it is as easy as it sounds, can someone with experience please have a look at THIS PAGE to confirm its accuracy before i publish it?
peanut, ... isn't it ?
Second point goes to "root" as in the example. "root" is limited to system files/applications/settings. it won't affect XBMC settings/library data/addons/addon settings. This is on "home".
@
mk01
Sure it's peanut
But why don't you call it "system" instead of root and "userdata" instead of home?
It seems that "root" doesn't means "/" but "/" minus "/home". A bit confusing.......
KB