[PROBLEM] XBian Transfer to larger card

[palswim]

Software
XBian version: 1.0 Beta 2
XBMC version: default
Overclock settings: default

Hardware
Power supply rating: 500mA
RPi model (model A/B 256mb/512mb): Model B
SD card size and make/type: 2 GB (and 4 GB) MicroSD with adapter
Network (wireless or LAN): LAN
Connected devices (TV, USB, network storage, etc.): USB hub with USB hard drive

I tried to use the XBian copier tool to create an image file (to "file:/a/path") to write to a new SD card, but it seemed to fail after creating 1 GiB of data. Perhaps I will open a thread for that, but I mention this just to explain my reasons for using the alternate methods I will describe.

Since I couldn't create an image of my currently running XBian system, I eventually caved in and powered off the system, and extracted the current SD card image with Win32 Disk Imager. Then, I wrote this image to the new SD card. I had already seen the notification in the Resize SD option saying "Resize is automatically provided by initramfs helpers.", so I figured that my Pi would resize the partitions in the new SD card at boot. But, it didn't resize the image at all.

After a bit of research, I thought that the swap partition (/dev/mmcblkp3) after the main partition (/dev/mmcblk0p2) was causing the resize to fail, so I deleted that partition and rebooted. Unfortunately, things started to get screwy here. I noticed that not only was the Pi not resizing the SD card, the space in the main partition was vanishing, as if XBian was trying to use the main partition for swap space, too. Using df -h, I started to see things like

Code:

Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  1.7G  1.4G   73M  96% /

The "available" space would steadily decrease until I would see

Code:

Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  1.7G  1.4G    0M 100% /

Every time I would reboot, I would again see a small amount of free space that was diminishing slowly to none.

At this time, running XBian on the larger card, but seeing these issues, I tried to resize the partition from within XBian, with both parted and xbian-resize, but neither would successfully resize the partition. Tab completion stopped working, but I was able to create a new swap partition and run mkswap and reboot, and that left my installation with something stable along the lines of:

Code:

Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  1.7G  1.1G  345M  77% /

I would like to know how to resize my partition to fill the extra space I have, and also how to reconcile the discrepancy between my used and available space.

[belese]

Problem is with df and btrfs file system used by xbian.
more info here as i can't explain much more :

https://btrfs.wiki.kernel.org/index.php/FAQ#Why_are_there_so_many_ways_to_check_the_amount_of_free_space.3F

belese

[palswim]

(26th Feb, 2014 10:57 AM)belese Wrote:  Problem is with df and btrfs file system used by xbian.

I don't much mind the inaccurate reporting in the df command, but I was encountering actual out-of-space errors (couldn't tab-complete, sudo wouldn't remember my user, etc.) after my free space shrank to zero. So, I would like to identify what is eating my actual space and fix the problem.

I am running some extra daemons, like transmission and rsync (via inetd), but those are referencing data on my external drive, so they shouldn't be eating space like crazy on my XBian card.

[belese]

i know it's happen to me also with some downloader, i don't find what is doing that,
and didn't find real solution.

a temporary solution that work for me, is to reduce/move swap partition and enlarge root partition in gparted under ubuntu,
remove some snapshot if any (by default yes). you could do that in xbmc xbian config (under backup, with advanced settings activate), it's not really smart now, there are also command line, but don't remember syntax, it is standard btrfs command, you could find it on google

but few times later, i had same problem and finish to reinstall

[palswim]

My main question still is how can I resize the partition to fill the free space I have on my card, or why didn't XBian auto-resize the partition (with or without the swap) in the first place?

[IriDium]

You shouldn't need to resize the partition - this should be automatic on first boot.

Also df -h is "suspect" on btrfs file systems - use the btrfs command.

Also I notice your PS is 500ma - that is not enough for a Model B 512mb model. 1 amp is required.

[mk01]

(28th Feb, 2014 08:42 AM)palswim Wrote:  My main question still is how can I resize the partition to fill the free space I have on my card, or why didn't XBian auto-resize the partition (with or without the swap) in the first place?

check if initramfs.gz is loaded and started. resize magic is done in this stage.
xbian is commenting out initramfs.gz in /boot/config.txt if it things it makes no use of it. this logic has it's limits, but saves cca 5-8 second from boot.

to be sure initramfs.gz is used, edit /etc/default/xbian-initramfs and set FORCEINITRAM=yes

reboot. check the resize process. the only condition which stops xbian from resizing is additional partition exists AFTER xbian's rootfs. so for instance 1st = boot, 2nd = root xbian, 3rd = user partition -> this will report error on resize.
but free space is ok. so fdisk -> "d", "3" -> "w", reboot should allow resize again.

(by default "partswap" parameter is specified to kernel boot in cmdline.txt which makes XBian to create swap partition during initramfs stage if not exists as last partition on device which holds XBian's root filesystem). so if your card has ~2G, this is shrinked to ~1.7G +256MB swap. to disable swappart creation (so shrinking of your root) remove "swappart" from cmdline.txt).

but you removed the swap part completely, right ?

so this way it should resize.

you was also completely right about the "swap" filing free space. after swap part was deleted and initramfs.gz not used, new swap (after resize rootfs) could not be created and XBian assumed /var/swapfile as the option if all other methods fail.

change /etc/default/zram-swap and "SWAPFILE=/var/swapfile" to "SWAPFILE=/dev/null" for disabling this. last but not least, "unvisible" snapshots are taking some space (if they are created on your system). in older BTRFS releases (kernel prior 3.12) this could lead to only real BTRFS issue we had for history - zero free space and rebalance failing, forced rebalance failed the FS completely.

for this there is check on snapshot creation for free space below 1/3 of capacity. in that case only most recent snapshot is kept regardless of user setting.
since 3.12 this was completely rewritten on BTRFS and I have not seen / heard of this problem since.

so this is in short all about XBians resize&swap logic. I hope it helps.

[timoleon]

Hello,

Assuming the underlying partition has been extended, you just need to run (as root):
btrfs filesystem resize max /home

Regards,

[IriDium]

@timoleon It should not be necessary as Xbian will resize on first boot.

[IriDium]

If you are on Windoze, you can use win32diskimager to read the SD card, and then use that image to restore to the larger SD card.

From experience, it DOES NOT work for same to same or smaller SD cards.