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?
Printable View
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...Quote:
Originally Posted by exylum
Cheers!
Krishna :)
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.img
Remember 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...Quote:
Originally Posted by klaus2008
Krishna :)
This is a very old thread, I thought I just want to post a follow up to this :-Quote:
Originally Posted by klaus2008
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
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
# [email protected]
#
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.Quote:
Originally Posted by kl522
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.
Ok, new information for me then.
Then the only issue I see is space. Because effectively you are making a backup copy it, and then also you make an increased sized copy of it. It will be hard to fulfill this requirement on a true flash installation with space constraint.
If the whole thing is worked on based on a offline method, then the actual knoppix-data can be worked on directly. The space requirement is minimum.
Yes, I meant that script as reference for future HD/USB installs. It's common to size based on current popular sizes and as you upgrade your USB devices, usually about twice the previous popular/critical mass size, would make the script usable for 75% of the people out there. I mainly posted it here for future reference for more advanced users (and as an offsite-backup).
I added in your aes stuff in case i ever decide to encrypt my home filesys. Complete and configurable with reasonable defaults (including knowing how to uncomment lines for beginners).
Cheers.
Your stuff is definitely useful.
But I am hopeful that someone will take up the challenge of integrating the resizing into minirt.gz to provide resizing as a cheat code. The cheat code maybe is :-
knoppix increment=100
It then will increase the persistent store by 100MB, if only the space is available ( can use the same method which knoppix does to determine free space available). Since it works on the persistent store before it is mounted, the persistent store itself is directly worked on, without needing to make a copy, and so has the smallest space requirement.
I resized the knoppix-data.img but the size of loop0 remained the same - I need more space in loop0 in order to apt-get update and then apt-get install adobe or apt-get install flashplugin-nonfree. What do I do?
Hi,
Wot, no reply yet ?
It sounds like you didn't quite follow the instructions. How ? Since only you were there, only you would know.Quote:
Originally Posted by rbrayer
Hmm ... I think everyone resizes their persistent store at least once but Knoppix does not come with a convenient way to do this.Quote:
Originally Posted by rbrayer
This simplest way (in that it requires least knowledge of Linux) is to start again. You could backup important stuff somewhere else first and restore it afterwards but you'd have to reinstall new software all over again so you might find it a bit of a pain.
A cheat code would be nice. There is now a pair of cheat codes that would serve http://www.knoppix.net/forum/threads...ersistent-data but you would have to install these yourself and I would not recommend that if you are not Linux capable and have not made becoming so one of this year's resolutions.
The instructions in this post seem clear and simple enough even though they don't use everyday commands. I have never done this myself. I can't see anything dodgy in the procedure but like kl522, I rather do it while the persistent store isn't mount.
There is another possibility that you may find easier to follow: http://www.knoppix.net/forum/threads...update*.tar.gz. I would not use this myself because there are a couple of cases it does not handle but, for you, that might not be important and it may be less hassle that starting from scratch. I think the method is sound provided you do it immediately after remastering. Since the chap who devised this was trying to avoid remastering in the first place ...
I keep getting this message no matter what I am doing:
You need to have a /media/sdb1 mounted
Of course, it is mounted :P
Still getting the same message:
You need to have a /media/sdb1 mounted
Please tell us, what you are doing and step by step how you did it. What error messages you've got and in which situation?
In this forum there are no clairvoyants.
Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD (Knoppix V6.7.1 remaster)
It happens when you try to resize a mounted cloop knoppix-data.img. Size of cloop remains the same, but size of file increase.
You need to do using a live session of Knoppix, for example, so the cloop persistent data will not mounted and you can safe use it.
It 's happened to me the first time
Bye