[HOW-TO] Installing XBIAN directly on RASPBIAN IMG

[mk01]

@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.