chrooting to the USB keyI wrote and booted a debian install CD and installed to my USB key at /dev/sdc.
Then I was able to boot back to Fedora 11 and chroot to debian as follows:
# mkdir -p /debian # mount /dev/sdc1 /debian # cp /etc/resolv.conf /debian/etc # chroot /debian # mount /proc # mount /home #shared with Fedora # su - padraig $ . /etc/environment && export LANGFrom there one can interact with the debian command line as normal, including installing any required packages off the network using apt.
Creating a debian loopback imageSo rather than dedicating the USB key to debian I decided to shrink the 16GB partition to a more appropriate size and then copy it to my /home partition for easy access in future. One can see here that 1GB is big enough for my requirements of debian:
# mount /dev/sdc1 /debian/ # df -h /dev/sdc1 15G 642M 13G 5% /debian # umount /dev/sdc1
I first looked at the parted command but was surprised to note in the man page that it doesn't support resizing the default linux filesystem type, ext3? I also notice that there is no mention of resizing tools for ext4 at all? Anyway taking the advice from the parted man page I used resize2fs and cfdisk to manually resize the partition as follows.
My bad partition shrink and recovery
# resize2fs /dev/sdc1 990M # takes a few mins # cfdisk /dev/sdc # delete all partitions # create new 1000MB partition at startNote how I selected a smaller filesystem size than the partition to ensure it would fit. Then I wrote zeros to the free space as follows, to ensure the image will compress well. This step is much better done on the mounted loopback image as I'll reveal.
# mount /dev/sdc1 /debian # dd bs=1M if=/dev/zero of=/debian/zeros # 4.8MB/s # rm /debian/zeros # umount /debian/So now to chroot to my new smaller partition on the key to verify it's OK:
# mount /dev/sdc1 /debian # chroot /debian Bus error (core dumped)Bum. I then realized that 990M for resize2fs is bigger than 1000MB for cfdisk!
$ echo $((990*(1024**2))) 1038090240 # e2fsck /dev/sdc1 e2fsck 1.41.4 (27-Jan-2009) The filesystem size (according to the superblock) is 253440 blocks The physical size of the device is 244983 blocks Either the superblock or the partition table is likely to be corrupt!So lets try to fix it, as hopefully writing zeros to the free space won't have messed up any of the file data.
# cfdisk /dev/sdc # delete all partitions # create new 1050MB partition at start # e2fsck /dev/sdc1 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -(245564--245759) -(245832--247807) -(247824--249855) -(251136--251903) -(252592--252744) Fix<y>? yes Free blocks count wrong for group #7 (3272, counted=8397). Fix<y>? yes Free blocks count wrong (84580, counted=89705). Fix<y>? yes /dev/sdc1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdc1: 26936/130048 files (0.8% non-contiguous), 163735/253440 blocks
The correct method to shrink a partitionWhat I should have done (taking some additional advice from comment 1):
# resize2fs -Mp /dev/sdc1 # shrink the file system to min size # cfdisk /dev/sdc # delete all partitions # create new 1000MB partition at start # resize2fs -p /dev/sdc1 # expand the file system to partition size
Finalising the loopback imageNow we can copy off the 1GB image and loopback mount it like:
# dd bs=1M if=/dev/sdc1 of=/debian.img # 24.7MB/s # mount -o loop /debian.img /debianFrom here I wrote the zeros as detailed above to make sure it compresses well, and used xz which is now packaged for Fedora 11 to compress the image to around 33% of its original size as I will only use it intermittently.