You are not logged in.
Pages: 1
This HOWTO is for power users. I am writing this HOWTO because I want to invite other forum members to join this project as I am expecting this to grow beyond my limited scripting capability.
For Linux newbies and ordinary users, for the moment, you can use the scripts I have written and announced in my blog: 9 Steps to Uninstall Programs from the Read-only Partition.
==================
Introduction
The EeePC comes with a union filesystem where the SYSTEM partition sda1 containing all factory installed programs is mounted ro and all user data are overlaid to the USER partition sda2 which is mounted rw. So normally, you can't uninstall programs from the ro sda1 partition. To be able to uninstall programs from sda1, we need to mount the union filesystem with both sda1 and sda2 rw with a custom boot initramfs image.
I have tested this some time ago as per my blog: Testing read/write union filesystem in my EeePC 4G which was successful. However, at that time, I have not been able to find a ways to make use of the free disk space gained in sda1 after uninstalling factory installed softwares. Until recently, with the sucess of my Restore from USB to minimal EeePC Linux project, I have found the way to shrink down and resize sda1, so making this practical.
So far, I have been working on this booting from a modified Asus EeePC Recovery USB disk. This is because I am familiar with it working long time with it on my other projects: Boot Xandros from USB for Dummies, Restore EeePC from Recovery DVD without unionfs, Restore from USB to minimal EeePC Linux, etc. Actually, this can be done from any Linux on USB that has the following commands available: mount, fdisk, e2label, mke2fs, resize2fs, tune2fs, tar, gzip (gunzip), dd, chroot, ... We only need to have an way (preferably GUI) users can easily create this USB utility disk.
Build a Read-write Initramfs Image
Pls refer to this wiki for detailed steps: Rebuilding initramfs. The changes we need to make to the "init" are:
#change this line from ro to rw mount -t ext2 -o rw $ROOT /mnt-system #Add mount options=rw to this line mount -t aufs -o br:/mnt-user=rw:/mnt-system=rw+nolwh none /mnt
For 701 4G which uses unionfs instead of aufs, the last line should be:
mount -t unionfs -o dirs=/mnt-user=rw:/mnt-system=rw unionfs /mnt
You can also download the initramfs-rw-eeepc.img I have compiled which supports both unionfs and aufs. [EDIT 2009/8/16: Changed download link to www.mediafire.com.]
Install the Read-write Initramfs Image
To be able to boot from this rw initramfs image, we need to install the new initramfs-rw-eeepc.img to /boot of sda1 in rescue mode or booting from USB. Also need to modify /boot/grub/menu.lst to add this new entry:
title Boot Read-Write Union Filesystem
root (0x80,0)
kernel /boot/vmlinuz-2.6.21.1-eeepc quiet rw irqpoll root=/dev/sda1
initrd /boot/initramfs-rw-eeepc.imgThen when you reboot, you can press F9 and select to boot into the read-write union filesystem. You can verify this by entering "mount" in a terminal. The line on union filesystem should be all (rw).
Uninstall Programs under read-write union filesystem
Programs can be uninstalled as usual with synaptic or apt-get.
Case 1: For factory installed programs, i.e. files in sda1, if you uninstall them under this rw union filesystem, the files will be deleted from sda1. Also, if you force re-install a factory installed program, you are effectively moving the files from sda1 to sda2.
Case 2: For factory installed programs which you have already upgraded, the new files from the upgraded new version will be in sda2, the files of the old version are still in sda1, but there will be some .wh.xxx files in sda2 which are written by the union filesystem driver to mask these old files as "deleted" (or whited-out).
If you just deleted the old files in sda1, the .wh.xxx files in sda2 will not present a problem. However, if you want to move the new version files (with the same filename) from sda2 to sda1, the existence of the .wh.xxx files will mask the new version files (with the same filename) which you have moved to sda1. So it is necessary to get ride of them.
Case 3: For user installed programs, their files will all be in sda2. So they will be deleted when you uninstall them in either ro or rw union filesystem.
Defrag sda1
After you have uninstalled programs from sda1, there will be free disk space in it. But you can not normally make use of it because sda1 is normally mounted read-only. So we need to shrink down sda1 and enlarge sda2 to make available this free disk space. But before that, we need to defrag the filesystem of sda1.
Currently there is no defrag program available for ext2 filesystem in Linux. The only way I can work out is to mv the files from sda1 to sda2 (in groups of about 300 MBs) and then back. This works out alright except for some symbolic links. I don't quite understand why this happens but I have worked out a way to correct this by logging error messages to a file, then "ls -l" to extract the link name and link target name, chroot to delete the links and re-create them. This seems to work out alright.
For EeePC with 2 SSDs, it may be even better to move files from sda1 to sdb1. Then we don't need to touch sda2. I have also tested moving the files from sda1 to a ramdisk and back. But there were strange errors during that trial. Since I found that it took almost the same time, so I didn't look at this again.
Resize sda1
To resize sda1, you can refer to this tutorial: How To Resize ext3 Partitions without Losing Data.
Basically, we need to "df" to check filesystem size used, and add 5% extra. But be careful sometimes "1K-blocks" (total block size) is not equal to "Used" + "Available". So you should check which one is larger, i.e if "Total" - "Available" is larger than "Used", you should use this as the size required for the new sda1 partition.
Please note that resize2fs normally use 4k for block sizes, but df is telling 1K block sizes. So, if you have calculated 1534320 to be the required size, you should tell resize2fs to resize the partition to 1534320K instead of just 1534320.
cat /proc/mounts > /etc/mtab e2fsck -fy /dev/sda1 resize2fs /dev/sda1 1534320K e2fsck -fy /dev/sda1
Both e2fsck and resize2fs need to check if the filesystem is mounted (from /etc/mtab or /etc/fstab) before they run. You should first umount the device before running these commands.
Also, to resize a partition, if you are shrinking it, you should first shrink the filesystem with resize2fs, then fdisk to shrink the partition. On the contrary, if you are enlarging a partition, you should fdisk to enlarge the partition, then enlarge the filesystem with resize2fs.
To calculate the new end cylinder for sda1 from the filesystem size (e.g. 1534320K), you can run the command "fdisk -l /dev/sda":
Disk /dev/sda: 4001 MB, 4001292288 bytes 255 heads, 63 sectors/track, 486 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 1 300 2409718+ 83 Linux /dev/sda2 301 484 1477980 83 Linux
From the 3rd line, we can see that 1 cylinder is 16065 / 2 kbytes, so the new end cylinder should be 1534320 / 16065 x 2 + 1 = 192 cylinders.
Sometimes depending on how fragmented the files are, this end cylinder no. may not work. What I have worked out is to run e2fsck after fdisk. If e2fsck reports an error, then I run fdisk again increasing the end cylinder no. by 1. So far, this method works out alright.
Now, there is still a small discrepancy between the partition size and the filesystem size. This can be corrected by running resize2fs again with no size specified. [NB. When size parameter is not specified, it will default to the size of the partition.]
Backup and Restore sda2
During this process, we also need to backup and restore sda2. Up to now, I have only worked out how to do this with dd:
dd if=/dev/sda2 | gzip > [Path to]/eeepc-sda2.img.gz gzip -dc [Path to]/eeepc-sda2.img.gz | dd of=/dev/sda2
I won't go into this as this is quite standard. You can refer to this wiki: How to Backup and Restore your system.
This method however is not ideal because if the partition sda2 become smaller as a result of moving programs from sda2 to sda1, restoring the dd backup image may not work. For just uninstalling factory installed programs from sda1, it still works (because sda2 will become larger but not smaller).
So ideally, we should use tar and gzip to backup all files from sda2. But I 've found that the version of the tar command in the EeePC does not support filename with whitespaces but some packages, e.g. xlex, have filename with whitespaces. This is something we need to work out if we want to make changes permanent, i.e. move packages from sda2 to sda1.
Grow sda2 to fill up the new free space
This involves running fdisk to enlarge the partition (delete sda2 and re-create it utilizing all available free disk space) , and then resize2fs to enlarge the filesystem.
cat /proc/mounts > /etc/mtab e2fsck -fy /dev/sda2 resize2fs /dev/sda2 e2fsck -fy /dev/sda2
And since I have been backing up with dd, I need to resize sda2 after restoring because the backup image contains the original filesystem.
Move Programs from sda2 to sda1
I have not yet worked this out, but I think this should be achievable like this:
1. Boot into read-write union filesystem and force re-install a program you have previously upgraded. [NB. You can skip this step if the newly installed program has nothing to do with files in the read-only partition.] This step is for to remove those .wh.xxxxx white-out files previously written to sda2 by the union filesystem to mask files in sda1 as "deleted" (or whited-out).
2. Then boot from USB.
3. Extract a list of files for packages to be moved with the "dpkg -L [package]" command.
4. Copy all files listed (probably with tar) to an USB disk, delete the original in sda2.
5. Then backup all files in sda2. [NB. Do not use dd as the partition sda2 may become smaller when you restore.]
6. Check free disk space available in sda1, enlarge partition and resize filesystem if necessary.
7. Now copy all files saved for the packages to sda1.
8. Shrink sda1 to minimum.
9. Recreate sda2, format it and restore all files from backup.
So there is still some work to ultimately get this working. Any one is welcomed to give input and/or join this project.
Also, I have compiled the kernel modules unionfs.ko and aufs.ko, so it should be possible to mount the rw union filesystem from the busybox environment of the USB utility disk. Then it should be possible to completely automate the whole process.
Last edited by albkwan (2009-08-16 11:14:16 am)
Offline
Pages: 1