Results 1 to 10 of 29

Thread: Re-master your flash installation

Hybrid View

  1. #1
    Senior Member
    Join Date
    Jan 2011
    Posts
    242
    Quote Originally Posted by kl522 View Post
    In any case, the steps above involved will be somewhat tricky to the Linux newbies. I wish there
    is a cheatcode called "upgrade=/dev/sda4:/master/KNOPPIX/KNOPPIX" which will automatically
    perform the upgrade. I will leave this as an exercise for those interested to do so by modifying minirt.gz.
    If you organise thing right, you can use cheat codes that are already there (assuming Knoppix 6.4.3 or equivalent).

    Suppose the Knoppix you have just remastered is on filesystem /dev/sdb1 under the directory KNOPPIX. Suppose further that you arranged for the new remastered Knoppix to be on device /dev/sda1 under the directory /home/yourself/remaster. This directory contains both the new KNOPPIX file and the cleaned-up knoppix-data.img (or aes) file. I don't think it has to contain all the other little files normally found in the KNOPPIX directory but it wouldn't hurt.

    You can now reboot to the remastered knoppix for test purposes with the cheat codes:

    Code:
    fromhd=/dev/sda1 knoppix_dir=home/yourself/remaster
    The directory /home/yourself/remaster has to be a real directory (avoid symbolic links and mount points). A nice feature of this approach is that /dev/sda1 doesn't have to be a vfat file system so long as it is a) visible at boot time and b) of a type the init script understands. This means it could (you didn't get this from me) be your ntfs Windows 7 main disk.

    If the new remastered Knoppix seems to be working OK you can use it to copy the new KNOPPIX file over the old one:

    Code:
    mount /dev/sdb1 /media/sdb1
    cp -pf /mnt-system/home/yourself/remaster/KNOPPIX /media/sdb1/KNOPPIX/
    Then clean up the old knoppix-data.img:

    Code:
    mkdir knoppix_tmp
    sudo mount -o loop=/dev/loop1 /media/sdb1/KNOPPIX/knoppix-data.img knoppix_tmp/
    cd knoppix_tmp
    sudo rm -fr $(ls --ignore=home --ignore=var);
    Finally, reboot Knoppix from your USB stick 'as normal'.

  2. #2
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802

    Isn't ext3 working partitions safer? Updating 6.4.4 packages forces remaster

    Quote Originally Posted by Forester View Post
    If you organise thing right, you can use cheat codes that are already there (assuming Knoppix 6.4.3 or equivalent).
    ....
    Code:
    fromhd=/dev/sda1 knoppix_dir=home/yourself/remaster
    The directory /home/yourself/remaster has to be a real directory (avoid symbolic links and mount points). A nice feature of this approach is that /dev/sda1 doesn't have to be a vfat file system so long as it is a) visible at boot time and b) of a type the init script understands. This means it could (you didn't get this from me) be your ntfs Windows 7 main disk.
    I wouldn't recommend newbies experimenting with remastering on Win7 NTFS partitions. I think it is much safer to shrink the Win partition on a disk, set up an ext3 partition there, and do everything on "native Linux".

    Apart from that, I think the method looks very promising. I will try out something like this myself now, as I feel forced to do it: Upgrading all packages on Knoppix 6.4.4 DVD today, filled up about 2.6 of total 4 GB persistent store. Therefore, people should not attempt it without really in need of it. OR, as a first step in remastering.

    I'll start out using internal hard disk, then I may try with USB-sticks - but I think a better external storage for remastering would be an external SSD drive with USB3 connection.

  3. #3
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802

    Expanding the persistent store to 8+ GB as a first step

    To follow up, I think it may be an advantage to do as much as possible before starting the remastering process. That implies doing package installs, upgrades etc the "ordinary" way as much as possible. But how to, within 4GB space? No way there, but we don't have to confine ourselves to FAT32 and DVD limitations.

    I just tried out expanding knoppix-data.img to 8.5 GB, and that works well on ext3. I place the Knoppix package on an ext3 partition and run from there, starting from USB with the fromhd= cheatcode. I'm not sure if there will be some kind of performance problems with large loop-mounted images, but I haven't seen any so far. So I will try with an even larger persistent store, allowing me to do more comprehensive installs and compile large programs.

    If we, after cleaning up and remastering, get outside the 4GB limits, there are several ways to still use USB sticks as basis. The simplest is to format the stick to ext2/ext3, install (for example) GRUB on it and just dump the Knoppix files to it. Somewhat more elaborate would be to split the compressed packages on two volumes, or work with several uncompressed volumes - that has worked just fine for me.

    I think using Linux file systems on sticks is very practical. For exchange of data with other platforms, we can set up a smaller FAT (or even NTFS) partition on the stick, and have that partition automatically mounted on boot-up. Typically, a 16 GB stick could be partitioned into 15 GB ext2 and 1 GB FAT32, the ext2 volume: 4 GB compressed, 10 persistent and 1 spare.

  4. #4
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by Capricorny View Post
    I just tried out expanding knoppix-data.img to 8.5 GB, and that works well on ext3. I place the Knoppix package on an ext3 partition and run from there, starting from USB with the fromhd= cheatcode. I'm not sure if there will be some kind of performance problems with large loop-mounted images, but I haven't seen any so far. So I will try with an even larger persistent store, allowing me to do more comprehensive installs and compile large programs.
    I have used ext3 persistent store for quite sometime now. The only performance problem with large ext3 and ext2 file system ( not specifically to loop-mounted ones ) is when you have to do file system check. The file system check time is really slow when compared to ext4.

  5. #5
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802

    Package purging

    Quote Originally Posted by kl522 View Post
    ... The file system check time is really slow when compared to ext4.
    I use a 16.5 GB ext2 persistent store, for testing now, seems like checking takes some time.. But, it seems to work. Full system upgrade went well. Which is not obvious, as, for example, I found that dpkg halts in updates on one missing newline in one file list - regardless of dependencies. Now is the time for purging/pruning. Is there any available hinting for this? The packages list, like in http://ftp.knoppix.nl/os/Linux/distr...ckages-dvd.txt doesn't give too much clue, it seems. Is there any way to pick out the games here? Here are some deletion candidates among the 40+ MB packages. Are any of these strictly necessary or very useful?

    Code:
    dpkg-query -W --showformat='${Installed-Size} ${Package}\n' | sort -n ...... 
    ....
    42884  context 
    44452  wireshark-common   
    45644  lmodern 
    46912 kdewallpapers  
    49972 gnome-games-data  
    51448 scribus-ng  
    52616 kde-l10n-es  
    59692 evolution-common  
    60760 pinyin-database  
    62844 openvas-plugins-dfsg  
    65260 tuxpaint-stamps-default  
    68852 kdebase-workspace-data  
    85476 mingw32  
    85972 inkscape  
    86044 neverball-data  
    98064 gcompris-data  
    101889 linux-image-2.6.37-64  
    120892 wesnoth-1.8-data  
    136684 wesnoth-1.8-music  
    203404 crossfire-maps
    In particular, identifying game packages in a simple way would be nice.

  6. #6
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by Capricorny View Post
    I use a 16.5 GB ext2 persistent store, for testing now, seems like checking takes some time.. But, it seems to work. Full system upgrade went well.
    16.5 GB persistent store is considered a huge persistent store but it is still probably not near to a point where file system check is unbearably slow. I used to have a 130 G ext3 file system which file system check takes unbearably long time to complete. I have since migrated to ext4. I am glad that I did. 130 GB is already slow, I can't imagine having a 1 TB ext3 file system !

    As I am writing, I did a small mod to my minirt.gz to support ext4. I think it is about time it should do that.

    Cheers.

  7. #7
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802
    Quote Originally Posted by kl522 View Post
    130 GB is already slow, I can't imagine having a 1 TB ext3 file system !

    As I am writing, I did a small mod to my minirt.gz to support ext4. I think it is about time it should do that.
    Very interesting if we could use ext4 - but I found that time-wise, 8GB persistent is quite OK. And I really don't think we need more when remastering. We definitely need more than 4 for upgrades and new installs, but using 8GB after remastering, we can do an awful lot of things.

    Very much to my surprise, DVD remastering, mostly following Forester's procedure, succeeded at the first try. Of course not perfectly, as I tried out alternatives and got a few things somewhat wrong. And the compressed KNOPPIX image was only 3.2 GB, with Oracle XE 10g and a lot of R packages installed. Removed a few games etc - there seems to be ample room for things like vmware workstation and a couple of servers - in fact, the USB VFAT stick concept could be enough for most uses.

    I had 4GB RAM and 10 GB swap - clearly enough. And, according to top, the I5-430M ran at 370% CPU during compression, indicating that create_compressed_fs parallelized nicely.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


ORICO Multi Bay RAID Hard Drive Enclosure USB 3.0/ Type-C For 2.5/3.5'' HDD SSDs picture

ORICO Multi Bay RAID Hard Drive Enclosure USB 3.0/ Type-C For 2.5/3.5'' HDD SSDs

$179.99



Dell EMC 092GD6 Broadcom 9305-16i LSI Quad Port 4 Port SAS RAID Controller picture

Dell EMC 092GD6 Broadcom 9305-16i LSI Quad Port 4 Port SAS RAID Controller

$84.99



ORICO 5 Bay Raid Hard Drive Enclosure USB C, 3.5” SATA HDD, Up To 80TB, NS500RC3 picture

ORICO 5 Bay Raid Hard Drive Enclosure USB C, 3.5” SATA HDD, Up To 80TB, NS500RC3

$139.99



G-TECHNOLOGY G-RAID GR4 2000 2TB EXTERNAL HARD DRIVE USBFIREWIREeSATA *LOW USE* picture

G-TECHNOLOGY G-RAID GR4 2000 2TB EXTERNAL HARD DRIVE USBFIREWIREeSATA *LOW USE*

$37.99



Inspur LSI 9300-8i Raid Card 12Gbps HBA HDD Controller High Profile IT MODE picture

Inspur LSI 9300-8i Raid Card 12Gbps HBA HDD Controller High Profile IT MODE

$15.98



Dell PERC H330 PCIe 3.0 x8 RAID Storage Controller 4Y5H1 High Profile picture

Dell PERC H330 PCIe 3.0 x8 RAID Storage Controller 4Y5H1 High Profile

$15.99



LSI MegaRAID 9361-8i 12Gbps PCIe 3 x8 SATA SAS 3 8 Port RAID + BBU & CacheVault picture

LSI MegaRAID 9361-8i 12Gbps PCIe 3 x8 SATA SAS 3 8 Port RAID + BBU & CacheVault

$39.00



9207-8i PCIE3.0 6Gbps HBA LSI FW:P20 IT Mode ZFS FreeNAS unRAID 2* SFF-8087 US picture

9207-8i PCIE3.0 6Gbps HBA LSI FW:P20 IT Mode ZFS FreeNAS unRAID 2* SFF-8087 US

$32.88



ACASIS 2.5/3.5 inch 2 Bay SATA USB 3.0 Hard Drive Disk HDD SSD Enclosure 4 RAID picture

ACASIS 2.5/3.5 inch 2 Bay SATA USB 3.0 Hard Drive Disk HDD SSD Enclosure 4 RAID

$55.45



Yottamaster 5 Bay RAID Hard Drive Enclosure Type-C B For 2.5

Yottamaster 5 Bay RAID Hard Drive Enclosure Type-C B For 2.5" 3.5" SATA HDD SSDs

$140.99