Forum

Full Version: Xbian - Shrinking Partitions
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hello.

This is my first posting, so be forgiving. =)

I have Xbian running on my Raspberry PI and setup just right, so I want to backup this guy. I'm no Linux newbie, as I've been using Ubuntu for years, so I went ahead and enabled root, changed the PW, and setup a simple script to run in cron to backup xbian using dd:

dd bs=4M if=/mnt/150GB/pi-os/backup/xbian-xbmc.img of=/dev/mmcblk0p2

My problem is xbian automatically resizes the partition to use the entire card. I don't want this, because then I end up with a 16GB dd image! I want to shrink the working xbian/xbmc portion to say a 4GB partition, so the dd image is around 4GB.

If I turn off my PI, and boot my laptop up with a gparted boot cd, and try to resize the xbian partition it fails. I've tried on multiple cards, so I don't think it's a card issue. Is there a way to disable re-sizing of the entire card in Xbian?
Add noresizesd to the cmdline.txt.

Because there was yet no documentation what so ever on the XBian specific cmdline options, i made a (hopefully complete) wiki page on them: https://github.com/xbianonpi/xbian-package-initramfs/wiki/XBian-specific-cmdline.txt-options
(10th Jul, 2013 09:28 AM)kgoerbig Wrote: [ -> ]My problem is xbian automatically resizes the partition to use the entire card.

as already curly said "noresizesd". or, if rootfs (startup) partition in cmdline.txt is not the last one on sdcard, xbian will not resize as well.

(free space is not a partition and will be taken by resizing).

mk
But, what if you already had your first boot, so now the partition is already resized to max. I think that is the case for kgoerbig.
(15th Jul, 2013 06:58 PM)zilexa Wrote: [ -> ]But, what if you already had your first boot, so now the partition is already resized to max. I think that is the case for kgoerbig.

I'm repeating again and again in many threads, dd looks like easy solution, but has few caveats.

one of them is nonsense to copy even 4gb, when only maybe 500 are needed.

if one wants "system" backup, use rsync. or tar | gz to .tar.gz

best option is to backup /home only. why the system ?

but if one wants dd, ok, here are the steps to shrink:

1) put "noresizesd" to cmdline.txt
2) on booted system, "btrfs fi res 4G /"
3) check "dmesg | tail" for reported fs size in bytes
4) do "fs size / 512"
5) "fdisk /dev/mmcblk0"
6) "d" and "2"
7) "n" and primary and as second
8) for start just enter, for size, put 4), enter
9) "w" enter

reboot
I also use rsync sometimes for backups. I was just wondering if in the case of kgoerbig, there would be a way to create an image of your current setup, small enough to deploy on other (new) RPis/sd cards. Thanks for the info!
(16th Jul, 2013 01:11 AM)zilexa Wrote: [ -> ]I also use rsync sometimes for backups. I was just wondering if in the case of kgoerbig, there would be a way to create an image of your current setup, small enough to deploy on other (new) RPis/sd cards. Thanks for the info!

already used filesystem (and it's datablock copy) will never provide small image.

smallest image you do by creating clean fs, rsync, shrink to minimum, update partition size.

and specially valid for CoW filesystems. when btrfs finally makes SEND and RECV functions ready, then it will provide easy of use as dd, but also with correct data and atomic state. dd image from LIVE filesystem is corrupted with the dding itself. so even the first copied image is not correct.
Reference URL's