A while ago (previous forum version?) there was an article here about resizing the knoppix-data.img filesystem. Could someone repost again how it was done?
A while ago (previous forum version?) there was an article here about resizing the knoppix-data.img filesystem. Could someone repost again how it was done?
I seem to recall it involved re-naming knoppix-data.aes then booting without it and creating a new knoppix-data.aes file, mounting the renamed (old) partition with a "-o loop" option and copying everything to the new one. Not as easy as resizing a partition with GParted, for instance, and possibly something worth doing as a "project" if someone has the inclination and time. I want it for myself (I'm putting off doing the procedure I described right now), but no time to do the work...
Cheers!
Krishna
Last edited by krishna.murphy; 04-05-2010 at 01:13 AM. Reason: OOPS!
I do not know that article and the forum's search functions does not seem to work.
If the persistent image file is unencrypted then one can make use of the e2fs utilities. My method is to boot the live CD since a filesystem to be resized may not be mounted, to find the persistent image knoppix-data.img, to check the filesystem inside the container, to enlarge the container by adding some bytes to it and to resize the filesystem.
1. Open a root terminal.
2. Mount the drive with the persistent image
3. Change to the directory with that persistent image
4. Make a backup of the persistent image.
5. Check the ext2 filesystem and allow corrections6. Add 100 MB to the containerCode:e2fsck -fy knoppix-data.imgRemember that the maximum filesize of the FAT32 filesystem is 4 GB. Therefore the filesize of the persistent image may not be made larger than the maximum filesize of the underlying filesystem. Be careful, use ">>" instead of ">"!Code:dd if=/dev/zero bs=1M count=100 >> knoppix-data.img
7. Resize the filesystem.8. Shutdown the system and boot Knoppix the usual way.Code:resize2fs knoppix-data.img
But if the persistent image is encrypted I think the only way to get a larger persistent image is to create a new persistent image and copy the data from the old filesystem to the new one.
Yes, I think that's so. Unfortunately, that requires space for an extra copy of the data, in addition to what's being added - not such a big deal on a lot of hard drives, but if I want 3GB instead of 2GB for my knoppix-data.img file on a USB-flash that was 8GB to start with and got a 4GB KNOPPIX directory copied onto it when I ran the flash-install utility, I'd run out of room. Guess I'll be using a hard drive when I do it...
Krishna
This is a very old thread, I thought I just want to post a follow up to this :-
To increase the size of an encrypted image, the following can be done :-
# dd if=/dev/zero bs=1M count=100 >> knoppix-data.aes
( same as the non-encrypted one )
# echo 'password' | losetup -e aes -p 0 /dev/loop6 knoppix-data.aes
( Now you can use /dev/loop6 for your resizing purposes )
# e2fsck -fy /dev/loop6
# resize2fs /dev/loop6
Once you are done, destroy the loop device association of knoppix-data.aes :-
# losetup -d /dev/loop6
Cheers
Last edited by kl522; 05-24-2010 at 07:22 AM.
Code:#!/bin/bash # # Description # Add specified MBs to the size of your knoppix-data.img partition. # Haven't tested the LIBEXT=aes version. You are liable if you uncomment # the operational lines below. It worked for me. # Usage # sudo ./resizeImg # add default 100 MB to your current img # sudo ./resizeImg 1000 # add 1000 MB (1GB) to your current img # Author # koolb@hotmail.com # MYDATA=/mnt/sda2 # make this an area on any HD set -e # exit on any errors..and do some checking [ $(id -u) -eq 0 ] || exec echo "You prolly need to be root. You are $(id -nu)" du | fgrep $(basename $MYDATA) || exec echo "You need to have a $MYDATA mounted" # review these to see if they need to change for your dist or prefs ADDMB=${1:-100} # append specified/default 100 Megabytes... PWD=aes-password # only set this if LIVEXT=aes #This should be the same for recent knoppix releases LIVEXT=img # img or aes # Active img extension BUIMG=$MYDATA/knoppix-data.$LIVEXT # BackUp IMaGe LIVEDIR=/mnt-system/KNOPPIX # Active img location LIVEIMG=$LIVEDIR/knoppix-data.$LIVEXT TMPIMG="$LIVEDIR/$(basename $LIVEIMG .$LIVEXT).bak" LOOP=$(losetup -f) # get an available loop device echo "Syncing buffers..." time sync # optional flush all data/buffers to disk echo "Copying live to backup..." time cp -p $LIVEIMG $MYDATA # backup/copy echo "Adding..." time dd if=/dev/zero bs=1M count=$ADDMB >> $BUIMG FS=$BUIMG [ $LIVEXT = aes ] && echo $PWD | losetup -e $LIVEXT -p 0 -s $LOOP $FS && FS=$LOOP set +e # bound to have some fixups from live echo "Cleaning fs..." time e2fsck -fy $FS # clean the backup set -e # resize will force exit on error(s) echo "Resizing..." time resize2fs $FS echo "Checking FS again..." time e2fsck -y $FS # clean after resize [ $LIVEXT = aes ] && losetup -d $LOOP # ideally do this in a transaction with rollback upon error echo "Moving into place..." #mv $LIVEIMG $TMPIMG # I was able to do this on a live system #time mv $BUIMG $LIVEIMG # which is one reason why i love Linux!
There are two issues with respect to your script :-
1. You make a copy of it. That will require a huge space somewhere.
2. Do you propose to replace it while it is in active use, or you put it offline first ?
The ideal place to have a script written for it is in minirt.gz, when one can specify a cheat code to increase the persistent file size. The script shall determine if there is enough room for the size increase. If yes, it shall expand it without making a copy, while it has not been mounted yet.
But this very risky without making a copy of it. The script has to be absolutely robust to handle all possible errors.
Yes, true. The last two commands are the critical part. Probably should ensure there's enough space on the destination(s) before uncommenting the last two lines. This script is non-destructive otherwise. Either way you will have a backup in $BUIMG (assuming you follow the directions and use a 2nd form of media for $MYDATA with enough space there).
I now boot my HD like a USB drive using grub4dos so I can still boot WinXP in a pinch (even tho I have a Win7 and XP VirtualBox) so there''s plenty of space. Note the following wont work for grub2....
Code:Installing a USB compatible install non-invasively(sp?) to the HD - Do all this from usb booted knoppix - get grub4dos and extract the zip somewhere, then cd to that extraction area unzip grub4dos-0.* cd grub4dos-0.* - mkdir /mnt-system/boot/grub - ensure the /mnt-system/boot/grub dir has grub's menu.lst: cp menu.lst /mnt-system/boot/grub - create the MBR if and ONLY if it doesnt exist: sudo bootlace.com /dev/sda # trashes existing MBR careful! - copy grub.exe to the /mnt-system/boot/grub area for DOS/98/XP/NT/W7/VISTA cp grub.exe /mnt-system/boot/grub - cp the grldr to the root of the hard drive: cp grldr /mnt/sda1 - add the following lines from the boot/syslinux/syslinux.cfg: Note: the kernel line contains everything from the syslinux.cfg append statement except the initrd=stuff (even tho it can be left in place) # this is a long cmd so be careful! # this will /insert lines before the first title in menu.lst - and the kernel line will ignore the initrd=... sed -p '/title/i\ title knoppix # any name to describe this boot root (hd0,0) # /dev/sda1 - note the kernel line is from a knoppix 6.23 cfg kernel /boot/syslinux/linux ramdisk_size=100000 lang=en vt.default_utf8=0 apm=power-off vga=0x311 initrd=minirt.gz nomce quiet loglevel=0 tz=localtime initrd /boot/syslinux/minirt.gz /' /mnt-sytem/boot/grub/menu.lst - now the boot/ and KNOPPIX/ dirs need to be copied to the /mnt/sda1 destination - copy /mnt-system/{KNOPPIX,boot} to the hd partition: cd /mnt-system; for dir in KNOPPIX boot; do cp -av $dir /mnt/sda1; done
Actually you did not answer my question (2) directly, but from the flow of the sentences, it appears to me you are overwritting knoppix-data while you are having it mounted. Since the whole operation is surrounded on increasing the size of knoppix-data, it might be safe to perform it while having knoppix-data mounted, but personally I am not sure it will be 100% safe.
and actively using the file. Just like you can mv a running exectutable to another file of the same name, you can do this with files tied to a loopback. I think the mv will create a hard link to the new file then remove the old file. All open file descriptors will still point to the correct data blocks.
I ran this script as knoppix on my system and had no issues. Until I rebooted, the kernel still sees knoppix-data.bak content exactly as it was when it was before the mv.
HP ProLiant MicroServer Gen8 G8 G2020T 8GB RAM 4x 1TB HDD 4x 3.5" 712318-421
$269.99
$198.00
1U Supermicro Server 10 Bay 2x Intel Xeon 3.3Ghz 8C 128GB RAM 480GB SSD 2x 10GBE
$273.00
1U BareMetal pfsense opnsense Router Firewall DNS Server 6x 10GB Ethernet Ports
$149.00
HP ProLiant MicroServer Gen8 | Intel XEON E3-1220L V2 | 8GB RAM | NO HDD | 4 BAY
$249.99
HPE ProLiant MicroServer Gen10 AMD Opteron X3216 8GB RAM No HDDs
$325.00
SuperMicro Server 505-2 Intel Atom 2.4GHz 8GB RAM SYS-5018A-FTN4 1U Rackmount
$202.49
HP HPE Microserver Gen 7 8 9 iLO 2/3/4/5Advanced License Lifetime Key| FAST SHIP
$10.00
Supermicro 1U Server X9DRW-3LN4F+ 2x E5-2680 2.7ghz / 128gb / 8xTrays / 2x 700w
$229.99
1U 20" Short Depth Server Firewall PFSense X11SSH-F Xeon 3.5Ghz 32GB RAM NVME
$247.00