Forum

The instructions at the 1st post, returned an error whether to my /tmp in Ubuntu 12.04 or on the sd card under media - anybody got a clue?

root@Lexington:/media/d58e060b-06f5-4fec-a006-4ea1a48dde71# cd /tmp
root@Lexington:/tmp# wget http://xbian.brantje.com/pool/stable/main/x/xbian-package-repo/xbian-package-repo_1.0.0_armhf.deb
--2013-12-26 12:31:18-- http://xbian.brantje.com/pool/stable/main/x/xbian-package-repo/xbian-package-repo_1.0.0_armhf.deb
Resolving xbian.brantje.com (xbian.brantje.com)... 188.142.48.93
Connecting to xbian.brantje.com (xbian.brantje.com)|188.142.48.93|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3186 (3.1K) [application/octet-stream]
Saving to: `xbian-package-repo_1.0.0_armhf.deb.1'

100%[==========================>] 3,186 --.-K/s in 0.002s

2013-12-26 12:31:19 (1.57 MB/s) - `xbian-package-repo_1.0.0_armhf.deb.1' saved [3186/3186]

root@Lexington:/tmp# dpkg -i xbian-package-repo_1.0.0_armhf.deb
dpkg: error processing xbian-package-repo_1.0.0_armhf.deb (--install):
package architecture (armhf) does not match system (i386)
Errors were encountered while processing:
xbian-package-repo_1.0.0_armhf.deb

(6th Dec, 2013 05:59 AM)mk01 Wrote: [ -> ]INSTALLATION STEPS ONE BY ONE:

Came here just to say thanks.

(27th Dec, 2013 06:34 AM)Mark2013 Wrote: [ -> ]root@Lexington:/tmp# dpkg -i xbian-package-repo_1.0.0_armhf.deb
dpkg: error processing xbian-package-repo_1.0.0_armhf.deb (--install):
package architecture (armhf) does not match system (i386)
Errors were encountered while processing:
xbian-package-repo_1.0.0_armhf.deb

Hello

You have to download the xbian-package-repo_1.0.0_armhf.deb file on your raspberry pi and install it on your raspberry pi.

KB

On what drive or "device" is the directory "/tmp" you start your How-To with? I tried this on my sd-card and it failed and then I tried it on my Ubuntu 12.04 computer and it failed.

INSTALLATION STEPS ONE BY ONE:

1)

You can't run it on Ubuntu. Install raspbian on pi, ssh to it and run commands.

@Mark2013 As @belese said. Your Ubuntu is i386 (Intel) Xbian is Arm

(28th Dec, 2013 05:48 AM)IriDium Wrote: [ -> ]@Mark2013 As @belese said. Your Ubuntu is i386 (Intel) Xbian is Arm

OK, so the arch won't work, but:

Does Xbian have a tvheadend?

(6th Dec, 2013 11:17 AM)mk01 Wrote: [ -> ]Next days we plan to put updates containing boot manager with maybe some easy to use clever helper tools to make consultation to one card for more systems they like as easy as for instance the cloner function. Looks like the popular NOOBS or BerryBoot in use and working but are limiting the user experience like for instance no updates etc, or making the system installation a nightmare for non experienced users (for unsupported systems). Definitely during first release but I expect this to work as easy and without limitations as FULL BOOT LOADERS used on PC or better nothing. Because then a hardly enjoyable experience is becoming bad experience and frustration.

In any case if you check this one anytime soon, report instantly back. I going to make the first post more stricture to better focus on the technical steps. After we get a clear picture, we can prepare an installer.

Hello,

I really appreciate the work you have done giving xbian the possibility to be installed on raspbian. I will be glad to hear about any progress with the boot system because I have a problem when I was doing some tests.

I want to have another OS in the same SD card, so I installed 2 raspbian images using NOOBS and everything was fine with both installations. I could easiliy switch between them at startup time.

However, I tried to install xbian using the steps provided but I failed. The pi does not start after the first reboot (the next step after installing xbian-package-kernel).

I suppose it is because the changes made by xbian-package-kernel are not applied considering that NOOBS use a little bit different partition schema. While a clean raspbian installation it is supposed to have the boot and the root partition where all files are placed and located, my SD card has now this partition schema:

1. RECOVERY (FAT) -> the "boot" which provide the possibility to switch OSes
2. An Extended partition with:
BOOT Raspbian 1 (FAT)
ROOT Raspbian 1 (EXT)
BOOT Raspbian 2 (FAT)
ROOT Raspbian 2 (EXT)

I am trying to install Xbian in Raspbian 2. After Xbian installation, I expect to mantain the same a little difference in the ROOT Raspbian 2 file system (which is supposed to change to BTRFS)

As it was stated on previous threads, xbian-package-kernel changes cmdline.txt and config.txt in the boot partition and copy initramfs (as well as other files), but in this case this two files are not really in the real boot partition (RECOVERY) but in the "BOOT Raspbian 2" partition.

What I could see is that the installer removed some files from the BOOT Raspbian 2 partition.
(bootcode.bin fixup.dat fixup_cd.dat fixup_x.dat kernel.img kernel_emergency.img start.elf start_cd.elf start_x.elf). Then, instead of changing files in the same partition, it mounts the RECOVERY partition as the BOOT partition and create some new files into it as config.txt fixup.dat initramfs.gz kernel.img start.elf System.map System.map-3.10.23+ (just to mention, bootcode.bin seems to be different also).

At the end, the pi does not boot anymore, and it has mixed files in the wrong partitions. To mention what happened with the most important ones:
- initgramfs.gz ends in the RECOVERY partition
- config.txt is a new file in the recovery partition instead of changing the file in the BOOT Raspbian 2 partition.
- cmdline.txt is not touched and remains in the BOOT Raspbian 2 partition.

What do you suggest to do in my case? Is there any chance someone could fix this or it will be not supported definitely? It will be greeat if this can work with NOOBS but the real final goal is to have the possibility to install more than one OS using the same SD card installing xbian in one of them.

@mzs

it is exactly as you posted. "normal" workflow for updating /boot (for Rasp2 it is part nr 8) would be following existing mount on /boot or trust /etc/fstab.

I have never seen NOOBS running so maybe you have to tell me how it works - does it edit /etc/fstab putting /dev/mmcblk0p8 /boot instead of /dev/mmcblk0p1 /boot ?

All kernel / firmware / boot updating processes within XBian were accepting /etc/fstab values - until Beta2 release. The problem was that with B1 users started with USB installs while doing it any way they found all over on internet or by dd or win32image tools. This was most of the time ending with copy of /boot from SD on USB device - what is not problem alone, but then while manually editing /etc/fstab and changing mmcblk0 into sdX values they changed also /boot entry.

But this had terrible consequences as real /boot was never updated - "dumb" /boot partition on another media was updated instead. So you can ping&pong all of this "issues" out as users error or consider some bullet proof solution - finally we implemented check with each /boot update to check if /dev/mmcblk0p1 is mounted /boot - if not, we remounted and all was fine.

Ugly hack I don't like very much but for that time it was taking significant "complications" for the user. With B2 there is own cloning tool so user has just to choose destination and this need is no more there.

And we need to implement /boot updating workflow for XBians native multiboot - to be honest I have not come with a better idea as ~ this one you described from NOOBS.

I suppose we can agree on that XBian's relevant packages (as initramfs-tools, kernel, config-shell and firmware) will be made dumb again (accepting existing /boot or just doing "mount /boot" thus accepting /etc/fstab setting.

One point needs to be solved though and that is manipulating /boot from within initramfs.gz operations (there is no fstab, …). But I will find a way.

I posted today new updates containing "bootmenu" functionality. It is definitely not so nice as beryboot or noobs, but has some advantages. For instance it doesn't need another FAT partitions to boot other systems from. It can scan all attached partitions and search them for possible boot configurations. You don't need to prepare special media before - you can take any existing SD / usb device and just put small .cfg file on the root partition (describing where is kernel.img, initramfs.gz (if any) and cmdline.txt. During next days search across btrfs filesystem sub volumes will be added which would allow you to store unlimited nr of systems - or states of them - with possibility to boot for instance yesterdays state of raspbian.

If we consider all systems polite (accepting /eetc/fstab /boot entry), /boot can be just directory withing system's own rootfs, mounted through "mount -o bind …".

I will let you know when the forced /boot remount will be removed - or ready for retest.

@mzs

updated initramfs, kernel and update package. /dev/mmcblk0p1 should not be forced anymore.

---

(all on devel repo)

Used 2014-01-07 release

1) Needed mkdir tmp
2) No problems
3) No problems
4) Resizing certainly took a while on an 8G SD card.
After reboot showed INIT Id “T0” respawning to fast: disabled for 5 minutes. This kept on going. <Enter> stopped this. Went to login.
dmesg showed swapon: swapfile has holes
5) What happened to 5) ?
6) WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
sysvinit
0 upgraded, 84 newly installed, 3 to remove and 1 not upgraded.
Need to get 60.0 MB of archives.
After this operation, 151 MB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
?]
Yes, do as I say!

a) After install. Xbian password not accepted. Logged in as pi. su –i xbian. Passwd
This seemed to have the effect of disabling default login – you now have to put in a password when swapping from lxde to Xbmc. Doh

b) Changed overclocking to Xbian standard. Added gpu_mem_512=256
c) Restored backup. (didn’t seem to work) Went from gz to working but nothing seems to have changed
Worked the second time around.
d) rebooted.

All looks good!!

IriDium,

password was planned to be 'raspberry' .

if you install "xbian-package-rasp-switching" password gets removed and switching to XBMC is through password-less logout / login. but we have then allow no password for ssh - or don't use xbian as logging user. but at the end why, raspbian users are used to use pi.

I will put the swap-file service as conflict to remove it.

the resizing was converting to btrfs - that's why it took time.

---

and missing 5 is … if nothing else then definitely optimizations. 1 of 6 is nearly 20%

Noticed in final install

status: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused

I also think that a restore of a backup erases the pi home directory!! Just double checked - it does!!

After that xbian user just takes you to a blank lxde screen not XBMC.

Wierd, I tried a few times to install, by following the instructions, on both raspberian (official image) and darkbasics minimal image, but both give me the folowing error after doing apt-get install xbian-package-kernel:


And indeed, the filesystem isn't btrfs so the error isn't that strange, but why isn't anybody else seing this? Am I missing something? I should be able to go through the script on a fresh installed raspbian installation shouldn't I?

Regards,
Rolf Deenen

@roelofpieter I've run the commands three times now without any problem. Make sure you're not missing something in the process. If problems persist enclose full dmesg via pastebin - it might be something else.