I have done this test with a 900 iso restored from USB. For testing purpose, I upgraded a few programs with "Add/Remove Software" so as to create something in the USER partition (sda2). Then I proceeded to modify the script package from my Restore from USB to minimal EeePC Linux approach, breaking down the main script into scripts for installing the read-write initramfs image, defrag and shrink down sda1, and grow sda2 to fill up free space resulted, together with another script offering a task menu for the user to easily run the scripts:
XXXXXXXXXXXXXXXXXXXXXXXXXXI have not yet worked out the scripts [1] and [4] for backup and restore sda2. Originally I intended to use the tar and gzip command to backup all files, but was not successful because I couldn't figure out what options the tar command in busybox environment supports. So I ended up doing this semi-automatically with the backup and restore process done manually with the dd and gzip command.
Select Menu for run tasks:
XXXXXXXXXXXXXXXXXXXXXXXXXX
"0" = Installing read-write boot initramfs image
"1" = Backup USER partition /dev/sda2 to image sda2.img.gz
"2" = Defrag and shrink SYSTEM partition /dev/sda1 to minimum
"3" = Grow USER partition /dev/sda2 to fill up free disk space
"4" = Restore USER partition /dev/sda2 from image sda2.img.gz
"5" = Grow filesystem in USER partition /dev/sda2 to fill up partition
"b" = Reboot System
"e" = Run extra scripts
"q" = Quit to shell prompt
Please select operation to run and press [Enter]:
Once again, except for "Part II: Uninstall programs under read-write union filesystem", all the other steps were done booting up from a custom Asus EeePC System Recovery USB disk which I have modified with support of e2fsprogs commands including e2fsck, e2label, mke2fs, resize2fs, tune2fs, and also additional commands like tar, gzip.
Part I: Install read-write boot initramfs image
I have written a simple script "rw_initramfs.sh" for easy installation of the read-write boot initramfs image initramfs-rw-eeepc.img into the read-only partition sda1 booting up from USB, just choose [0] at the task menu and press [Enter].On reboot, I pressed [ESC] and then [Enter] at the 1st boot device selection menu, immediately followed by [F9] [NB. This offers a better chance to catch the 1 sec timing after the BIOS splash screen than pressing F9 repeatedly]. This led me to the hidden grub boot menu, where I selected the last entry: "Boot Read-Write Union Filesystem". to boot into a read-write union filesystem.
When the system got booted up, I verified this with the "mount" command. Here were mounted filesystems:
rootfs on / type rootfs (rw)
/dev/sda1 on / type ext2 (rw)
none on / type aufs (rw,xino=/.aufs.xino,br:/=rw:/=rw+nolwh)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)
tmpfs on /tmp type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
See / is mounted rw, and the union filesystem aufs is also rw for every branch.Part II: Uninstall programs under read-write union filesystem
In this read-write union filesystem, the SYSTEM partition sda1 is not mounted read-only. So when you uninstall factory installed programs, instead of just whited-out (in sda2) as in default Xandros, it will be deleted from sda1. So if you have some factory installed programs you never use in your EeePC, you can uninstall them in this read-write union filesystem and reclaim some extra disk space.In this test, I uninstalled all games, all educational programs, skype, pidgin which I seldom use. Once in a while, I will play a game, but it is easy enough to just re-install the particular game when I need it.
Be careful when you uninstall programs with either synaptic or apt-get, always carefully look at the "To be removed" list to make sure you do not accidentally remove some other important dependent packages.
I also upgraded firefox, and xlex. The behaviour of a read-write union filesystem is that if you upgraded a program, the old version files in sda1 will be deleted and the new version files will be installed to sda2. So effectively you are moving the package files from the read-only sda1 to the read-write sda2 if you upgrade a program. So you should not use this method to upgrade system libraries or you will lose the F9 restore function.
Eventually I will also work on moving packages from sda2 to sda1. This will probably involve booting up from USB and generating a list of files for the package to be moved with "dpkg -L [package]". Then according to this list, move the files from sda2 to sda1 (probably first into the USB disk because there may not be enough disk space in sda1). For the moment, let's stay with just removing factory installed programs.
After I was done uninstalling programs I don't need, I booted from USB again to reclaim the free disk space in sda1 then.
Part III: Shrink down the read-only partition and reclaim the free disk space
Step 1: Backup USER partition /dev/sda2 to image sda2.img.gzAs currently it is not possible to resize and move the beginning of a Linux partition, after we have shrunk down sda1, the only way to reclaim the free disk space is to delete partition sda2 and re-create it. So we need to backup files in sda2 first.
The ideal method is to use the tar and gzip command. The advantage of this over dd is speed, especially if you have a USER partition not so full. But since I can't get the busybox tar command working, I worked with the dd command this time.
The draw back of backing up with dd is that if you have a target partition smaller than the original, you may end up with errors restoring the image. However, if the target partition is bigger than the original, you can easily resize it to fit afterwards with the resize2fs command. So if we were to eventually work out a way to move packages from sda2 to sda1, we may come up with a situation where sda2 will become smaller. Then we would definitely need to backup with tar or other means instead of dd.
The dd Backup Process
Here are the commands and terminal output how I use the dd command to backup the USER partition sda2. Before I dumped the drive image, I also mounted it and zeroed it so as to reduce the size of the gzipped image.
#mount /dev/sda2 /mnt-userPlease note that I had difficulty to umount it, and has tried to force umount it with the lazy umount option. It was successful only when I specified the mounting point instead of the device name in the force umount command.
#cd /mnt-user
#dd if=/dev/zero of=delete.me bs=8M; rm delete.me
dd: delete.me: No space left on device
#cd /
#umount /dev/sda2
umount: Couldn't umount /dev/sda2: Inappropriate ioctl for device
#umount -l /dev/sda2
umount: forced umount of /dev/sda2 failed!
#umount -l /mnt-user
#mount /dev/sda2 /mnt-user
#umount /mnt-user
#dd if=/dev/sda2 | /sbin/gzip > /xan/sda2.img.gz
2955960+0 records in
2955960+0 records out
#
As I am saving sda2.img.gz to the USB Recovery Disk, you will need enough free disk space there. Since the USER partition sda2 is normally of size 1.3 GB, you will probably need an USB Recovery disk of size 2 GB to play safe. This also means you would probably need to delete the P701L.gz Linux system image from the USB Recovery Disk.
Step 2: Defrag and shrink the SYSTEM partition sda1 to a minimum
I already have this script "shrink_ro.sh" done. It is basically part of the main script in my Restore from USB to minimal EeePC Linux approach, so it is well tested. So I just ran "taskmenu.sh" and select [2] from the task menu.
#sh /xan/taskmenu.shHowever, please note that the current script is defragmenting sda1 by moving files in groups of maximum 300 MB. So you need at least 300 MB disk space in sda2 to do this. If the script found less than 300 MB free disk space in sda2, it will ask if you want to delete all files in sda2 to make necessary space.
Step 3: Grow USER partition sda2 to fill up the free disk space
On completion of step 2, I have freed up something like 600 MBs. Actually part of this is the original 27% free disk space in the factory sda1. By selecting [3] in the task menu, the script "grow_user.sh" was run which run the fdisk command to delete existing partition sda2 and re-create it, filling up available free disk space. Then format and label it.
Step 4: Restore USER partition /dev/sda2 from image sda2.img.gz
Again, I have not yet worked out the script for this. I just enter [q] to quit to the shell prompt and enter these commands manually:
#cd /Step 5: Grow filesystem in sda2 to fill up partition
#/sbin/gzip -dc /xan/sda2.img.gz | dd of=/dev/sda2
2955960+0 records in
2955960+0 records out
#/sbin/e2fsck -fy /dev/sda2
USER: clean, 2611/185088 files, 63833/369495 blocks
#/sbin/resize2fs /dev/sda2
#
Now that sda2 has been restored from the image, its filesystem however is still of the same size as the previous partition, and is smaller than the enlarged partition. So we need to run resize2fs to enlarge it.
The script for this has already been done. Just run taskmenu.sh again and select [5].
Now that everything was done, I rebooted into normal union filesystem to check the result.
Package installation and removal record can be read from /var/log/dpkg.log (as root only). I verified that all the changes had been properly noted.
sudo kwrite /var/log/dpkg.logI also fired up synaptic and verified the packages I have removed were gone, and tried to re-installed a few packages.
The available disk space as reported by "Disk Utility" is now 1.7G. So this approach is all over successful. What remains for me to do is to complete the 2 missing backup and restore scripts, then run another test probably uninstalling openoffice (because I will probably upgrade to openoffice3 which has no deb available for Debian etch yet). Then I will pack the scripts and upload to my server.
(To be cont'd: 9 Steps to Uninstall Programs from the Read-only Partition)
No comments:
Post a Comment