1) the tv off function with screensaver - if working ok, resuming working ok etc
2) configurations with wifi only (so eth0 not used)
i've no hdmi, and no wifi adpater, have to search for it, but it is in some (which one???) box since my last move.
will look your commit.
(2nd Aug, 2013 08:28 AM)f1vefour Wrote: [ -> ]My initramfs got borked during the last update, I believe it may have been because I ran the upgrade as root instead of sudo.
I need a pointer on how to get xbian to boot back up?
just rename /boot/initramfs.gz.old to /boot/initramfs.gz. backup is always created. also check whether config.txt is not empty.
at least "initramfs initramfs.gz 0x00a00000" must be there. the /boot will readable under any os you put the card into.
sudo is root, there is no difference. sudo spawns new process with uid and gid =0. it was not your action causing this.
(2nd Aug, 2013 08:28 AM)belese Wrote: [ -> ]no hdmi, and no wifi adpater, have to search for it, but it is in some (which one???) box since my last move.
will look your commit.
never mind.
someone hopefully will have hdmi at last
.
Thanks mk01, is there an upgrade log so I can see what happened?
(2nd Aug, 2013 09:45 AM)f1vefour Wrote: [ -> ]Thanks mk01, is there an upgrade log so I can see what happened?
apt is logging into /var/log/apt, but system log daemon has to be started before. xbian-update is logging errors to /home/xbian/xbian-update.log, but for example triggered execution of initramfs re-create is not logged separately, if called from within dpkg, then it would be as console output at /var/log/apt, but again, rsyslog or sysklogd needs to run.
i'm running the system log, but xbians defaults is service off. so depends on your setup. I have not explicitly asked to enable it in the instructions in opening post. did I?
You did not post any logging related steps in the OP.
I tried to reproduce what happened but couldn't, I used --reinstall on the packages that were updated when initramfs broke but everything went smoothly.
What are the proper steps to rollback to a former snapshot?
Would we just change the snapshot name in cmdline.txt to one of the dated snapshot names?
the logic is as follows:
standard installation expects any volume it might need to have @ subvolume, which is considered to be standard "running" copy (so root is mounted as subvol=root/@, home is mounted as subvol=home/@ etc)
btrfs-auto-snapshot for provides for users "rollback" command, which will make from desired snapshot (specified on command line) this one "running" snapshot named @ (previous @ is renamed to be as the specified "snapshot_rollback". so this way we don't have to touch any system config files (fstab, cmdline.txt, others).
but: we are not all users, we are power users, so we can just alter cmdline.txt and boot from what ever snapshot we want
as I edited the opening post last time, quite easy process of testing is to do it like:
1) boot from /@
2) create /@_test
3) alter cmdline.txt to boot from /@_test
4) run all the updates (I already updated xbian-update to respect subvol= parameter in cmdline.txt and not overwrite it with defaults even if cmdline.txt will change - it will simply take new cmdline.txt, but subvol= parameter is migrated)
5) edit cmdline.txt to boot from /@, reboot
6) destroy /@_test
so simple answer to your question (in case YOU are asking) would be YES. just use any snapshot you prefer. for standard user answer would be "technically it will work, but use rollback command"
Thanks mk01, this is my first experience with the btrfs filesystem so I'm learning as I go. I always leaned toward reiserfs as my experimental FS of choice, I had high hopes for the planned plugin system and reiserfs4 but the developer lost his mind and you probably know the rest.
(2nd Aug, 2013 10:10 PM)f1vefour Wrote: [ -> ]choice, I had high hopes for the planned plugin system and reiserfs4 but the developer lost his mind and you probably know the rest.
raiser had very very interesting concepts. but the was crazy in writing absolutely non-readable code.
so with him "going out", there was nobody keen into push it further, even fix the known bugs.
you can compile zfs
I had even dkms packages for xbian-package-kernel headers somewhere, what I prepared and never released.
speed is at different level when working with multi vdev filesystems, btrfs is with this functionality at the stage "ok, it is working".
but there are still some memory eating issues (ARC cache not resizing effectively) on zfsonlinux causing troubles. specially on small systems like RPIs 256mb ram.
so it boots and works very well for some hours, then it starts slowing down, until some system stress situation (high memory demand, some more programs started) which will kill the system eventually.
mk
Beta 1.1 fresh install:
1) Followed first page.
2) apt-get upgrade (Packages will be excluded - wait)
3) apt-get install xbian-update xbian-package-initramfs-tools xbian-package-kernel xbian-package-splash
(About /etc/default/xbmc - accept default N).
System rebooted successfully and seems to be working... in fact better than stock Beta 1.1 :-)
K400 KB and mouse working.
USB drives hotplugable and show up in Videos and Music as the ID and not ID+UUID
Question. A lot of packages have been left behind: Is it safe to run apt-get autoremove?
(3rd Aug, 2013 11:33 PM)IriDium Wrote: [ -> ]Question. A lot of packages have been left behind: Is it safe to run apt-get autoremove?
usually yes.
i'm just curious, it seemed that beta 1.1 (beta 1) was stripped too much and additional updates added more dependencies. so one would expect adding packages, not removing
can you provide a sample ?
(3rd Aug, 2013 11:33 PM)IriDium Wrote: [ -> ]2) apt-get upgrade (Packages will be excluded - wait)
what means packages will be excluded, wait ? were all packages been upgraded? f1v4 was auto upgrading only few of them, the most important have been held back by apt-get due to not conflicts, but due to new dependencies.
mk
@
mk01
Terminal
root@xbian:~# apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
fontconfig-config libaacs0 libass-dev libass4 libbluray-dev libbluray1 libenca-dev libenca0 libexpat1-dev libfontconfig1 libfontconfig1-dev libfreetype6-dev libjasper-dev libjasper1
ttf-dejavu-core udhcpc
0 upgraded, 0 newly installed, 16 to remove and 0 not upgraded.
After this operation, 12.6 MB disk space will be freed.
I'm headed to work so I will be unable to answer any questions until this evening.
(3rd Aug, 2013 11:39 PM)mk01 Wrote: [ -> ] (3rd Aug, 2013 11:33 PM)IriDium Wrote: [ -> ]Question. A lot of packages have been left behind: Is it safe to run apt-get autoremove?
usually yes.
i'm just curious, it seemed that beta 1.1 (beta 1) was stripped too much and additional updates added more dependencies. so one would expect adding packages, not removing
can you provide a sample ?
--------------------------------------------
The following packages were automatically installed and are no longer required:
fontconfig-config libaacs0 libass-dev libass4 libbluray-dev libbluray1
libenca-dev libenca0 libexpat1-dev libfontconfig1 libfontconfig1-dev
libfreetype6-dev libjasper-dev libjasper1 ttf-dejavu-core udhcpc
Use 'apt-get autoremove' to remove them.
--------------------------------------------
(3rd Aug, 2013 11:33 PM)IriDium Wrote: [ -> ]2) apt-get upgrade (Packages will be excluded - wait)
what means packages will be excluded, wait ? were all packages been upgraded? f1v4 was auto upgrading only few of them, the most important have been held back by apt-get due to not conflicts, but due to new dependencies.
mk
That's OK. That was my way of saying "known" packages will be excluded. They were installed in the following step.
System wise it seems to be fast and stable.
Still having problems with a USB3 disk but that has ALWAYS caused an issue, not just in Xbian - Windoze and M@C. Will see if I can deduce the root cause.
Looking good so far :-)
oh yes, -dev packages are not needed and I was indeed removing them from dependencies.
do as you are allowed. I just need to be told if something again and again is not resolved or on top other issues I will introduce new one. btw: if you will report issue, just tell me number from /etc/xbian_revision file.
(2nd Aug, 2013 08:28 AM)belese Wrote: [ -> ]will look your commit.
belese, the error is in file:
/home/xbian/.xbmc/addons/skin.amber-master/1080i/View_57_58_59_Showcase.xml
line 121, <label>$INFO[ListItem.Property(Addon.Version]</label>
")" is missing.
OK. It's looks like it is in the Fred patch for amber.i dont use amber.