Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: resizing knoppix-data.img

  1. #1
    Junior Member
    Join Date
    Oct 2006
    Posts
    9

    resizing knoppix-data.img

    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?

  2. #2
    Moderator Moderator
    Join Date
    Jan 2010
    Location
    Asheville, NC, USA
    Posts
    528
    Quote Originally Posted by exylum View Post
    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 02:13 AM. Reason: OOPS!

  3. #3
    Senior Member registered user
    Join Date
    Feb 2010
    Posts
    508

    RE: resizing knoppix-data.img

    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 corrections
    Code:
    e2fsck -fy knoppix-data.img
    6. Add 100 MB to the container
    Code:
    dd if=/dev/zero bs=1M count=100 >> 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 ">"!

    7. Resize the filesystem.
    Code:
    resize2fs knoppix-data.img
    8. Shutdown the system and boot Knoppix the usual way.

    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.

  4. #4
    Moderator Moderator
    Join Date
    Jan 2010
    Location
    Asheville, NC, USA
    Posts
    528
    Quote Originally Posted by klaus2008 View Post
    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 corrections
    Code:
    e2fsck -fy knoppix-data.img
    6. Add 100 MB to the container
    Code:
    dd if=/dev/zero bs=1M count=100 >> 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 ">"!

    7. Resize the filesystem.
    Code:
    resize2fs knoppix-data.img
    8. Shutdown the system and boot Knoppix the usual way.

    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

  5. #5
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by klaus2008 View Post
    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.
    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 08:22 AM.

  6. #6
    Junior Member registered user
    Join Date
    Aug 2007
    Posts
    16

    A script to do this (tested by me but you must uncomment some lines at bottom!)

    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!

  7. #7
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    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.

  8. #8
    Junior Member registered user
    Join Date
    Aug 2007
    Posts
    16
    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

  9. #9
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    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.

  10. #10
    Junior Member registered user
    Join Date
    Aug 2007
    Posts
    16

    2. Yes it's save to move a file tied to a local loopback while the system is live

    Quote Originally Posted by kl522 View Post
    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.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
DELL POWEREDGE R720 8B 2.5 SERVER E5-2603 1.80GHZ 48GB 7 X 600GB 10K SAS H310
$2219.0
DELL POWEREDGE R720 8B 2.5 SERVER E5-2603 1.80GHZ 48GB 7 X 600GB 10K SAS H310 pictureDELL POWEREDGE R730 8 BAY TWO E5-2620V3 2.4GHZ 192GB 8 X 1.6TB SSD H730
$9919.0
DELL POWEREDGE R730 8 BAY TWO E5-2620V3 2.4GHZ 192GB 8 X 1.6TB SSD H730 pictureDELL POWEREDGE R730 8 BAY TWO E5-2698V3 2.3GHZ 128GB 3 X 600GB 15K 12G H730
$6079.0
DELL POWEREDGE R730 8 BAY TWO E5-2698V3 2.3GHZ 128GB 3 X 600GB 15K 12G H730 pictureHPE PROLIANT DL360 G9 Gen9 SERVER E5-2699V3 2.3GHZ 64GB 8 X 800GB SAS SSD
$14429.0
HPE PROLIANT DL360 G9 Gen9 SERVER E5-2699V3 2.3GHZ 64GB 8 X 800GB SAS SSD pictureDELL POWEREDGE R730XD SERVER TWO E5-2623V4 2.6GHz 256GB 4TB SATA 16 X 800GB SSD
$10489.0
DELL POWEREDGE R730XD SERVER TWO E5-2623V4 2.6GHz 256GB 4TB SATA 16 X 800GB SSD picture