Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: Re-master your flash installation

  1. #21
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    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.

  2. #22
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by Capricorny View Post
    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.
    True and fully agree.

    However there is another subtle need to have minirt.gz supporting ext4, ie when the persistent store itself is a file sitting on an ext4 filesystem. Right now this configuration is not supported, one cannot have a poor-man install on an ext4 file system.

  3. #23
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    Quote Originally Posted by kl522 View Post
    However there is another subtle need to have minirt.gz supporting ext4, ie when the persistent store itself is a file sitting on an ext4 filesystem. Right now this configuration is not supported, one cannot have a poor-man install on an ext4 file system.
    That is a rather serious limitation for me. The hardware and file system agnosticism of Knoppix is one of the great advantages, making many system details mostly an efficiency issue.

    And the need for efficient 100+ GB volumes is clear - for many, if not most, users.

    Would it really be enough to tweak minirt.gz for Knoppix - because support is integrated otherwise?

    I have a couple more questions. First, I noticed that the ISO9660 standard was frequently violated when creating the iso file system. Some file names got changed too - what is the expected effect of this? Anything to do about it?

    Second, I come back to the cloop issue. Is there anything new on this front? Seems to me that for our special purpose, we don't need the particular features of cloop (being file system agnostic maybe the most important contrast to squashfs, which is a file system?). I am going to make some comments on this in the squashfs thread.

  4. #24
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by Capricorny View Post
    I am going to make some comments on this in the squashfs thread.
    By all means please go ahead to do it. However I will not be joining you there. I better keep my mouth shut on this topic. Everything I want to say about squashfs is already said. I have no rights whatsoever to comment on the choice of it, only the author can decide on the choice. Wow, this is indeed like trying to meddle into people's choice of religion. No way a third person can make any comments on your choice of religion, don't you think so ?

  5. #25
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    Quote Originally Posted by kl522 View Post
    By all means please go ahead to do it. However I will not be joining you there. I better keep my mouth shut on this topic. Everything I want to say about squashfs is already said. I have no rights whatsoever to comment on the choice of it, only the author can decide on the choice. Wow, this is indeed like trying to meddle into people's choice of religion. No way a third person can make any comments on your choice of religion, don't you think so ?
    Exactly!

    But luckily, the assumptions and assertions are to a large degree testable here.
    And if all the steps necessary for remastering are gathered into a two-step routine, with deletion/pruning and (eventually) upgrading is the first step, I don't think many will care if squashfs is being used, as long as everything works and the process can be iterated. With expanded persistent store, no program installations need to be part of the remastering process, and this is also better practice - everything that gets compressed should be well tested first.

    One feature that might come in handy in this respect, is an option to make a backup of persistent store upon system shutdown. It is much more natural to do this after running the system, and, eventually, before using the system files for upgrading, than at bootup time.

    Another feature, could be union-mounting the system to remaster as a separate file system from the running Knoppix - then any risk of open files or inconsistencies can be avoided. With squashfs at least, this should be possible.

  6. #26
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by Capricorny View Post
    That is a rather serious limitation for me. The hardware and file system agnosticism of Knoppix is one of the great advantages, making many system details mostly an efficiency issue.

    And the need for efficient 100+ GB volumes is clear - for many, if not most, users.

    Would it really be enough to tweak minirt.gz for Knoppix - because support is integrated otherwise?
    Since I am not the author I could only ***SPECULATE*** why this is not supported. For the author, it is trial to change minirt.gz to support ext4 and yet it is not supported probably :-

    1. The author does not believe in ext4, thinking it might be unsafe.
    ( Well, this is unlikely to be true because even the much more dangerous configuration of poor-man install on NTFS is at the least "installable" ).

    2. The code for support for various file system has long been written and nobody has provided the feedback for the need for ext4 or rather, the author is distant enough to be able to hear about the need for ext4 from anyone yet.
    ( This is highly likely because of the way KNOPPIX development has been taking it's course all the years - a solo project ).

  7. #27
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    Quote Originally Posted by kl522 View Post
    2. The code for support for various file system has long been written and nobody has provided the feedback for the need for ext4 or rather, the author is distant enough to be able to hear about the need for ext4 from anyone yet.
    ( This is highly likely because of the way KNOPPIX development has been taking it's course all the years - a solo project ).
    I think there may be a couple of more reasons for ext4 support somewhat lagging. First, out-of-the-box support for it has not been universal until recently. For instance, Red Hat Enterprise Linux only added it in the last release a couple of months ago. Second, it is just in line with the add-in philosophy of Knoppix that the no-alternatives situations are handled first: People using ext4 today, mostly know how to create partitions, and they are, mostly, in position to do it for their KNOPPIX interests. The same does not apply to most NTFS users. And the highest priority for any general purpose distro can not be to cater for the highly interested with skills to do the modifications themselves. A "standard remastering" based on the work presented in this forum could make such issues less personal, I think. Any name for such a Knoppix derivative? Geek-knoppix maybe?

  8. #28
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by Capricorny View Post
    I think there may be a couple of more reasons for ext4 support somewhat lagging. First, out-of-the-box support for it has not been universal until recently. For instance, Red Hat Enterprise Linux only added it in the last release a couple of months ago.
    I would like to agree with you but I can't. Knoppix has a lot of chance to include new changes recently. Just watch how many new releases have taken place recently ? If it is something in the to-do list, it would have been included. And this particular ext4 thingie, it's simply trivial. Takes only 2 minutes. It ***WAS*** not on the to-do list. I am not sure about it now.

  9. #29
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    Quote Originally Posted by kl522 View Post
    And this particular ext4 thingie, it's simply trivial. Takes only 2 minutes. It ***WAS*** not on the to-do list. I am not sure about it now.
    Well, rather than speculating, we can proceed to produce that geek-knoppix. Then Klaus K is free to include or drop any changes in his next upstream release. And, if you look at his communication with Ryumbeke, he can be very positive towards suggestions and modifications. Also, I think the direction of development in 6.X is the opposite of secteric.

    My take on some of the main features:
    * ext4-support plus, eventually, other non-suppeorted fs in general use.
    * Thorough purging of non-essentials, like space-consuming games. Users can install them themselves.
    * Addition of a series of packages that are important for some users. My own standard examples: R and some Java packages.
    * Maybe addition of some packages/libraries to facilitate the installation of some programs/extensions that are not included.
    * Use of squashfs, at least as one version, keeping the cloop tools.
    * Tools for setting up for GRUB-booting.
    * Backup of persistent store + safe system transfer. (Copying mounted and constantly modified persistent store is not entirely safe, it seems.)
    * Remastering tools.
    * If possible, some tool for collecting package use statistics - to aid in inclusion/exclusion of packages.

Page 3 of 3 FirstFirst 123

Posting Permissions

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