XBian DEVEL and STAGING repositories
|
20th Jan, 2014, 12:03 AM
Post: #46
|
|||
|
|||
RE: XBian DEVEL and STAGING repositories
thank for confirming.
that means also cifs mounts are ready when needed? I'm aiming to completely remove the dependency to network for other services - but still make 100% sure, that no service / program will fail because of not available network share. so xbian-net will be no service just task, trying to bring up eth0 and lo for cca 30s. then regardless of result will stop. this stop is still as dependency - but it can no longer happen that it will be stuck in started state and trying to mount shares (but failing due to typo in config, unavailability of share or upstream lib changes (the nfs4 vs nfs story) - ((or other bugs as for instance not considering CIFS by myself)). when more feedback will be ok, I will move to staging and will write documentation as the packages there have many new functions implemented: 1. "bootloader" (bootmenu) 2. "telnet" kernel command line argument which makes RPI available via telnet starting immediately in INITRAMFS stage, then going through rootfs mount, pivot root during whole upstart phase until ssh and others are loaded. then it is stopped.so you never ever have to come to RPI personally (systems console is available too - so you actually see the real screen) 3. removed dependency on FSTYPE and on other (/etc configurations) entries which are relevant to boot media etc. simply system boots and runs from any media you copy it onto without need TO ADAPT OTHER PARTS 4. xbiancloner is now supporting creation of NFS ROOT including NFS tests (whether proper no_squash is used) and including automatic change in cmdline.txt. so you just click & reboot. 4a. supported (means tested) is also ext4 or f2fs. 1a. also booting from snapshots is supported - although this was tested only minimally (this applies for whole bootmenu). 5. new 3.12.x kernels with manually merged patches from BTRFS developers as I realized that Linus is months after official tree considered stable. Quite difference in locks and transaction management resulting in almost NO IOWAIT utilization - having amazing impact on perceived responsiveness. solved should be also years wrong "df" reporting and the absurd "filesystem full" problems. 6. support for such small details as for instance turn TV off during shutdown of RPI, run user script on shutdown 7. XBMC signals - I found a way how to solve the signal problems (XBMC QUIT, SHUTDOWN, REBOOT) - as result of internal python engine and addons with running blocked io ops and other unstoppable tasks - i'm fetching this states directly from XBMC and handed over to upstart directly. and many more for sure. Please read rules and do a search before you post! . FAQs . How to post log file? . Looking for answers? Please start here |
|||
« Next Oldest | Next Newest »
|
Possibly Related Threads... | |||||
Thread: | Author | Replies | Views: | Last Post | |
[RPi] Staging xbian-package-xbmc (14.1~RC1) (Kodi) | CurlyMo | 17 | 41,222 |
19th Feb, 2015 06:31 AM Last Post: CurlyMo |
|
[RPi] Staging xbian-package-kernel (3.17.7-ck2+) | CurlyMo | 5 | 13,843 |
13th Feb, 2015 12:33 AM Last Post: f1vefour |
|
[RPi] Staging xbian-package-firmware (1.5.1) | CurlyMo | 3 | 11,874 |
7th Feb, 2015 08:23 PM Last Post: CurlyMo |