[IDEA] Boot XBian from USB

[mk01]

tty is virtual screen, ... on windows keyboard it's the famous alt+f1, f2, f3. by default, xbian uses console=tty2, so you don't see the boot process.... and even some fsck interaction (what you see on your active tty1 as freeze).

at least that's my perception of the story.

---

so you can edit cmdline.txt in boot and change tty2 to tty1 or if you again run into this, just try to switch to tty2 (alt+f2).

[Fred]

Okay thanks, I changed tty2 to tty1 in cmdline.txt and now I got a little bit more information. It says, 'Root partition /dev/sda2 missing' like shown in the attachment.

   

[mk01]

if the disc if filesystem known to the system and you are normally using it other time, it's just late initialization.

you have been dropped to a shell. check, if the /dev/sda2 is really missing.

"ls -la /dev/sda2"

if it's there, mount it

"mount -t ext4 -o rw /dev/sda2 /rootfs"

type exit to continue booting. if it this case, check cmdline.txt again if you have rootwait option specified. if not, add it.

[Fred]

I can't mount /dev/sda2 because it can't be found, but when I do a fdisk -l it is listed as you can see in the attachment.

   

rootwait is already in my cmdline.txt

Code:

dwc_otg.fiq_fix_enable=1 sdhci-bcm2708.sync_after_dma=0 dwc_otg.lpm_enable=0 console=tty1 root=/dev/sda2 rootfstype=ext4 rootwait

Also, the boot always fails on a sudo reboot, but almost never on a power cycle.

[mk01]

ok, isn't it just the /rootfs dir missing ??? you have not posted the "ls -la /dev/sda2"

[Fred]

/rootfs is there. "ls -la /dev/sda2" returns there is no such directory

[mk01]

try to run /bin/busybox mdev -s

and then recheck for /dev/sda2

[Fred]

Okay after I run /bin/busybox mdev -s, /dev/sda2 exists and I can also mount it to /rootfs.
When I exit then I get a

Code:

"Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000"

(I got this same message also when I exited without changing anything).

[mk01]

yes yes, the ptompt is run with exec. you can't exit that. do you know how to unpack initramfs.gz file, edit file and then pack back ?

[Fred]

Uhm no I don't know.. But I can try.

---

Sir you are awesome, thank you very much. I found on google how to edit the initramfs and I saw that init waits 10 seconds for the drive to come up, which seems to be to short (literally 1 second to short) for my external harddisk to come up after a reboot. I have changed this to 20 seconds and now it reboots every time.
I'll add this info to the issues on github and write a small guide here tomorrow.

[mk01]

you are faster than light. anyhow I changed the init that way, that rootwait (as cmdline parameter) can be extended with number (rootwait=50) and this will be taken dynamically.

it will be in beta1.

[Fred]

Okay that's cool. For people with the same problem and want to solve this now, here is how I fixed it. Like I already said I changed the time the init script waits for the root partition to come up, I did this by modifying the initramfs.gz that is located in /boot.

First make sure you are root:

Code:

sudo su

Create a temporarily folder where ever you want and unpack initramfs.gz into this new folder.

Code:

mkdir temp
cd temp
gunzip -c /boot/initramfs.gz | cpio -i

Now your folder should contain this;

Terminal

bin dev etc init init.save lib media proc rootfs sbin sys tmp

Now edit the init file

Code:

nano init

Search for this piece of code and change the value 10 in the while statement (the amount of seconds to wait for the root device to come up) to a value that is sufficient. For me changing it to 11 did the trick already but I changed it to 20 just to make sure (the while loop stops when the device is found so it will not affect boot performance).

Code:

# check if new root partition exists
X=0;
while [ ! -b "${ROOTDEV}" ] && [ ${X} -lt 10 ]; do   #change this value
        X=$(($X+1));
        mdev -s
        sleep 1;
done;

Now do the same for the init.save file (I honestly don't know what the difference is between these two but init.save also contains this piece of code).

After this is done we have to repack the files, you can overwrite the original initramfs.gz or create a new one to keep the old file as a backup.

Code:

find . | cpio -H newc -o | gzip -9 > /boot/initramfs-new.gz

If you have chosen to make a new initramfs file you have to change your /boot/config.txt file to point to this new file.

Code:

Old line:
initramfs initramfs.gz 0x00a00000

New line:
initramfs initramfs-new.gz 0x00a00000

This fixed the problem for me and I hope also for other people. If it does not fix your problem then I doubt your problem has the same cause, you could go back in this thread to follow the instructions of mk01 and see if your problem has the same cause. If it does you could try changing the time to wait to a even higher number.

I got the procedure of how to unpack and repack the initramfs from this site: http://backreference.org/2010/07/04/modifying-initrdinitramfs-files/

[xbmcnut]

For those that want a guide on How To move the boot partition to an external drive, I wrote one tonight based on two working experiences both with a USB2 thumb drive and an external HDD.

http://xbmcnut.blogspot.co.nz/2013/05/how-to-move-your-boot-partition-to-usb.html

[mk01]

just few remarks to the copy process.

- with the dd, new partition will take the same UUID and LABEL as original. this should be avoided.
- but bigger potential problem is the dd from RW mounted partition, even mounted as rootfs. the blocks are constantly changing as you are linearly proceeding - I would be very very surprised, if the ext4 fs would be still ok. more rw operations will then only create more and more errors until it collapse completely. proper way would be have it unmounted. if not, then at least remounted as ro. and this will only work if you boot into single user mode by changing cmdline, or by "telinit S" from running system.
- also keep in mind, that the size of destination needs to be at least exact on block-count level. even 4096 bytes (one block) of oversize could be enough to make filesystem on the next partition unmountable. it's possible to check with "blockdev --getsz" or "fdisk -s /dev/disk-partition"

but IMHO still the best way for this kind of duplications would be rsync. you just create the dest partition and filesystem (UUID will be properly generated), rsync will copy just the kB stored, not kB of partition size. You can't damage other partitions... it will be faster and content verified.

"rsync -av -x --delete --progress / /mnt/destination/" will do the job, after one run, run it one more time to copy changes from time during the copy and you are ready.

[Fred]

I use this command

Code:

rsync -aAX /* /mnt/destination --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found,/home/*/.gvfs} --progress

Got this from here (including explanation): https://wiki.archlinux.org/index.php/Full_System_Backup_with_rsync

I think you should at least exclude the place where your destination is mounted (normally /media or /mnt) to avoid a loop.