Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 41

Thread: Squashfs-ed knoppix

  1. #31
    Senior Member registered user
    Join Date
    May 2006
    Location
    Columbia, Maryland USA
    Posts
    1,631
    Austrian, I think.

  2. #32
    Senior Member
    Join Date
    Jan 2011
    Posts
    242
    Quote Originally Posted by utu View Post
    Austrian, I think.
    The professor, yes, the university, no.

  3. #33
    Member registered user
    Join Date
    Sep 2005
    Posts
    36
    Quote Originally Posted by kl522 View Post
    Code:
    mksquashfs /mnt/knx/source/KNOPPIX /mnt/knx/master/KNOPPIX/KNOPPIX.sq -b 262144 -noappend
    ...
    Quote Originally Posted by kl522 View Post
    Code:
    mkisofs -R -U -V "KNOPPIX.net filesystem" -publisher "KNOPPIX www.knoppix.net" \
    -hide-rr-moved -cache-inodes -pad /mnt/knx/source/KNOPPIX \
     | nice -5 /usr/bin/create_compressed_fs - 262144 > /mnt/knx/master/KNOPPIX/KNOPPIX
    Well, this already shows the fundamental difference: SquashFS is a filesystem on its own, it reads a directory structure with a bunch of files from someplace and compresses them while putting them into a container.

    Cloop, on the other hand, does not care about the underlying filesystem. It provides a sort of "compressing shell" around anything that is thrown at it. It could even be a cpio archive or a tar file.

    With cloop you could do the following:
    - Make a full bitwise backup copy of any partition, including boot sector and whatnot, using dd.
    - After compressing it with cloop, you get a rather small image that provides read access while "staying compressed" and still contains everything the original partition did, true to the bit.

    You cannot do that with sqashfs, you only get the part that is underlined above. The italic part will never be possible with sqashfs.

    It could be arguable whether the possibility to have a bit-copy of the original filesystem at hand has any value in the use case of a live-CD/DVD. Maybe not. But I believe that cloop has some value above that: It is a general compressor/decompressor and, in the special case of a mountable filesystem, provides read access to the compressed thing (plus providing write protection by design).

    Therefore, for me it would be a major pity to drop cloop altogether.

    Have fun
    Dirk
    Last edited by DirkS; 04-15-2011 at 11:10 PM.

  4. #34
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by DirkS View Post
    It could be arguable whether the possibility to have a bit-copy of the original filesystem at hand has any value in the use case of a live-CD/DVD. Maybe not. But I believe that ....
    You are not even convinced yourself and yet you are trying to convince us. And finally you use the word 'believe' .....

    You should give us an example of what you described is useful in the context of a live-CD/DVD which the purpose is to squeeze has many programs as possible into the distro.
    And that better be something cannot be done by squashfs.

    And finally I said before, if Klaus is serious about wanting to continue to use cloop, he should work on including his patch into the mainstream kernel.

  5. #35
    Member registered user
    Join Date
    Sep 2005
    Posts
    36
    Quote Originally Posted by kl522 View Post
    You are not even convinced yourself ...
    Well, I am convinced that my use case can only be satisfied by cloop, never by squashfs. That's why I don't want to loose it altogether.

    In terms of a live-CD/DVD: If space efficiency is the killer argument, squashfs is obviously the best. Maybe you can use it even without encountering problems that don't show up with cloop. Maybe there are good reasons to not use it for Knoppix, I don't know. Also I don't remember having ever remastered a Knoppix DVD, I used cloop for something else. So... *shrug*

    Quote Originally Posted by kl522 View Post
    if Klaus is serious about wanting to continue to use cloop,
    Klaus Knopper is the one who decides whether to continue to use cloop or switch to squashfs, not you.

    Quote Originally Posted by kl522 View Post
    he should work on including his patch into the mainstream kernel.
    I'm on his side about this. The patch is easily added, the so it's not worth the fuss. It works like this since years, so why put a lot of extra effort on oneself, for very little benefit?

    (Besides, things of much higher general interest than squashfs or cloop have been rejected by the kernel developers, like Con Kolivas' BFS - but meanwhile some distributions patch their default kernels with it, even though it's not in mainline and most likely never will be. (And since I use BFS myself for several years now, I can tell you it makes a noticeable difference.)
    Being in mainline is not a sign of quality whatsoever, it just means that the developer managed to win a fight of some sort. )

  6. #36
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802
    Quote Originally Posted by DirkS View Post
    Well, I am convinced that my use case can only be satisfied by cloop, never by squashfs. That's why I don't want to loose it altogether.

    In terms of a live-CD/DVD: If space efficiency is the killer argument, squashfs is obviously the best. Maybe you can use it even without encountering problems that don't show up with cloop. Maybe there are good reasons to not use it for Knoppix, I don't know. Also I don't remember having ever remastered a Knoppix DVD, I used cloop for something else. So... *shrug*

    Klaus Knopper is the one who decides whether to continue to use cloop or switch to squashfs, not you.

    I'm on his side about this. The patch is easily added, the so it's not worth the fuss. It works like this since years, so why put a lot of extra effort on oneself, for very little benefit?

    (Besides, things of much higher general interest than squashfs or cloop have been rejected by the kernel developers, like Con Kolivas' BFS - but meanwhile some distributions patch their default kernels with it, even though it's not in mainline and most likely never will be. (And since I use BFS myself for several years now, I can tell you it makes a noticeable difference.)
    Being in mainline is not a sign of quality whatsoever, it just means that the developer managed to win a fight of some sort. )
    I'd like to expand a little on this:

    1. I don't think an ordinary comparison of cloop and squashfs is very fruitful - different tools, for different, but in the case of Knoppix overlapping, sets of jobs. I also think it is a bad idea to scrap cloop altogether, it seems to be completely(?) file system agnostic, that can be extremely useful.

    2. For quite a few uses, among them the practically important remastering of USB or poor man's HD installs, squashfs may have an edge. While being in mainline is surely not a quality sign per se, in my view it offers some guarantee against being too bad for too long time. That may in fact be relevant in changing times. But the most important thing, is that using squashfs, we can use new or alternate kernel versions without having to update cloop. And while it is by no means a pure Knoppix project, cloop is a tool for special purposes, and will probably stay that way, as squashfs in many 'standard' cases will look like the natural default choice.

    3. I think Knoppix has not got the use it deserves, and one of the reasons is clearly the development model, with Klaus Knopper "The Upstream Vendor" (TUV) and very little basic development being done downstream. What we are discussing, is different alternatives for system solutions, and the existence of different alternative solutions can only be a good thing. While I think it may be true that the Knoppix project would benefit from switching to squashfs, I don't think it is necessary now or in the near future.

    4. I think Knoppix would benefit from a development process more analogous to kernel development, where Klaus Knopper is the Linus T equivalent of "benevolent dictator", free to include or reject different kinds of "patches" for inclusion in the basic Knoppix package.

    5. Creating a squashfs-based derivative with a more specialized package selection (e.g. a hybrid of standard Knoppix and Quantian) could be a good way of experimenting. It could also have some standard non-free software pre-installed, like vmware Workstation and Oracle XE, subject to activation (e.g. by license number). Non-free software is one of the facts of life in many professional uses fo Linux.

  7. #37
    Senior Member
    Join Date
    Jan 2011
    Posts
    123
    I have a litle problem:
    today I ditched up my usb with knoppix on just for fun and messed around with it.
    Don't ask me how but I ruined my minirt.gz
    I have no linux on my laptop installed so I can't patch it myself again and this is needed as my usb install uses squashfs

    Can someone share his?

  8. #38
    Moderator Moderator
    Join Date
    Nov 2010
    Location
    Germany/ Dietzenbach
    Posts
    1,124
    ... please contact me; I can send you minirt.gz from 6.4.4

    listings@wp-schulz.de

  9. #39
    Senior Member
    Join Date
    Jan 2011
    Posts
    123
    thanks a lot werner.
    for the people who want squashfs without problems(or with the same issue as me ) go here : http://dl.dropbox.com/u/15024434/initrd.gz

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

    Making squashfs an option, may be the simplest way to 64 bits version

    It seems that Klaus K prefers cloop because of versatility and well proven good properties. But that's of course "past experience", not really present. He has his good reasons, but I think testing out squashfs should be encouraged, as eventual problems and improvements will have a much broader impact than for cloop, and fixes therefore are more likely to happen.

    We should aim for a clean extension of the mounting function in minirt init, to cope with squashfs. Klaus K is of course free to reject such a patch, but if we prove it to be useful, I don't think it will be rejected for very long. (Reminiscent of Kanotix forked off because of reluctance to HD installs... not much later we had 0wn...)

    When running cloop compression without optimization, it goes almost as fast as squashfs, so compression time isn't that much of an issue. But, the resulting difference in compressed size amounts to about the last GB of programs stuffed into memory from a DVD size image, and that is practically relevant. With an ever increasing footprint of the basic system functions and utilities, it tends to get more rather than less relevant with time, too. I see this very clearly with my pure 64-bits version of 6.4.4.

    In the 64-bits context, it should be noted that there have been some adaptation problems with cloop, and I'm not quite sure they are alle honed out by now, Klaus' latest cloop patch being from July 6, and it seemed to make some difference for 64-bits remastering. Where I can still not make busybox (1.1.17, amd64, Debian package, 1.1.18 compiled from source doesn't run at all) get the mounting right, even if I can do it manually in debug mode. I should add that using a freshly compiled 2.6.39.2 64 bits kernel did not help for this bug, only a few others

    I'm going to try the squashfs alternative here, and if that goes through, it will be a strong argument pro squashfs, I think. I would also like to add that the way cloop is used in current Knoopix, it's really not file system agnostic, rather we have a (harmless at best) step via isofs, which introduces another set of potential problems. Maybe small and/or irrelevant, but most likely, not empty.

    We should, at least, know what may, eventually, be to learn from other successful live distros, in particular Debian-based. Like Ubuntu live and Kanotix. BTW, I looked at the init for the Debian 6.0.1 live CD showcasing LXDE - think Knoppix is far better, and it wasn't a very good user experience either - I just needed it as a starting point for "pure" 64-bits Knoppix.

Page 4 of 5 FirstFirst ... 2345 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
  •  


HP ProLiant MicroServer Gen8 Server Xeon E3-1220L 16GB RAM No HDD's picture

HP ProLiant MicroServer Gen8 Server Xeon E3-1220L 16GB RAM No HDD's

$299.00



HP Proliant MicroServer Gen 8 2.3GHz CPU 16GB RAM NO DRIVES/CADDIES INCLUDED picture

HP Proliant MicroServer Gen 8 2.3GHz CPU 16GB RAM NO DRIVES/CADDIES INCLUDED

$179.99



HP ProLiant HSTNS-5151 Micro Server 8GB RAM No Drives/Key/Caddies *READ* picture

HP ProLiant HSTNS-5151 Micro Server 8GB RAM No Drives/Key/Caddies *READ*

$94.99



HPE PROLIANT MICROSERVER GEN10 PLUS MICRO TOWER SERVER - USED picture

HPE PROLIANT MICROSERVER GEN10 PLUS MICRO TOWER SERVER - USED

$550.00



HPE ProLiant MicroServer Gen 10 Plus, Xeon E-2224, 16GB DDR4, 1TB M.2 NVMe SSD picture

HPE ProLiant MicroServer Gen 10 Plus, Xeon E-2224, 16GB DDR4, 1TB M.2 NVMe SSD

$750.00



HP ProLiant Microserver Micro Server HSTNS-5151 untested picture

HP ProLiant Microserver Micro Server HSTNS-5151 untested

$75.00



HP ProLiant MicroServer Gen8 Server Intel Xeon E3-1220L v2 16GB DDR3 (4) 4TB HDs picture

HP ProLiant MicroServer Gen8 Server Intel Xeon E3-1220L v2 16GB DDR3 (4) 4TB HDs

$399.00



ProLiant MicroServer Gen8 Intel Xeon E3-1220L V2 2.3GHz CPU 8GB RAM picture

ProLiant MicroServer Gen8 Intel Xeon E3-1220L V2 2.3GHz CPU 8GB RAM

$170.00



HPE ProLiant MicroServer Gen10 Plus v2 Ultra Micro Tower Server P54644001 picture

HPE ProLiant MicroServer Gen10 Plus v2 Ultra Micro Tower Server P54644001

$849.99



HPE microserver Gen8 Update Firmware iLO4 + BIOS System Latest HP Server FAST⚡️✅ picture

HPE microserver Gen8 Update Firmware iLO4 + BIOS System Latest HP Server FAST⚡️✅

$79.99