Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Project: Merging Knoppix and Debian Live to get 64 bit Knoppix derivative?

  1. #11
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801

    The Debian philosophy seems to be Roll Your Own

    Quote Originally Posted by dwstarke View Post
    Is an iso available? TIA
    Actually, the basic idea in Debian-Live seems to be that you roll your own. I have used the standard 7.6 LXDE Live ISO from July as starting point, but I may try to create a new ISO from scratch myself.
    I could use the package list from my current running system - but the three most important additions for me, VMware Workstation, Oracle XE 11g and SqlDeveloper, are not available as .deb packages. The two last were converted from .rpm by alien.

    The somewhat fundamentalist Debian approach also shows up in hardware problems. I couldn't get Wifi to work on a Asus N53S laptop, but found out that I could fix it by downloading and installing the firmware-iwlwifi package. It works perfectly, but I have to start it manually! With non-free components, wireless is disabled by default!!! While there are no such problems with more politically correct drivers.

  2. #12
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    Well - this has worked very well so far.
    I write this from a remastered Live-Debian with no persistent storage, but with all previously installed packages crammed into a 4.2 GB filesystem.squashfs file.
    It has all worked on the first try. Looks very promising, as I won't have to exceed the 4GB limit of FAT32 do set up my 64 bit servers..

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

    An extremely simple remastering script for Debian-live

    The details

    Here, I work "somewhere" with a few GB free space. In this case, 15 GB would be enough.
    The persistent store is /media/sda8/live-rw, and the compressed image file is /mnt-system/live/filesystem.squashfs. Those names are default Debian-live names.
    I run this from Knoppix, so the files are not in use. I union-mount them, copy the file system to a directory copyfs, and compress this into a squashfs image to replace the original one.
    If you insist on running from the ISO, as it is copied onto sticks, you get problems replacing the squashfs image. You may have to create a new ISO image in some way.
    But I have simply copied the /live directory (corresponds to the KNOPPIX directory) onto a hard drive, and set up good old legacy grub to boot it.

    Code:
    #!/bin/bash
    #
    [ -d sqfs ] || mkdir sqfs ;
    [ -d persfs ] || mkdir persfs
    [ -d aufs ] || mkdir aufs
    [ -d copyfs ] || mkdir copyfs
    #
    sudo mount -o ro,loop /mnt-system/live/filesystem.squashfs sqfs 
    sudo mount -o loop /media/sda8/live-rw persfs
    sudo mount -t aufs -o br:persfs:sqfs none aufs 
    #
    #
    sudo rm -rf copyfs/*
    sudo rsync -axu aufs/* copyfs 
    #
    sudo mksquashfs copyfs filesystem_rem.squashfs
    You may want to keep the old squashfs image as a backup before copying in the new one.
    Next setup a new persistent image

    Code:
    cd /media/sda8
    sudo mv live-rw live-rw-0  # Or whatever version number
    sudo dd if=/dev/zero of=live-rw bs=1M count=3950
    sudo mkfs.ext2 -F live-rw
    And I still can't see the great advantages of working in a chroot environment, glad I was able to completely avoid it..

  4. #14
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801

    Some notes on overlays and instances

    Debian-Live has a terrible way to handle overlays. All instances of live-rw encountered are sandwich-mounted together, even if the advertised label mechanism is used. So, basically, for safety one should use just one at a time, renaming the others.

    How bad is this in practice? It turns out, it doesn't have to be that bad. With frequent remasterings, we don't really need much persistent storage for everyday use, and we can mount volumes to get what else we need.

    Right now, I write this in a kvm window running Debian-Live without persistence in a Knoppix 7.0.5 host, with two other kvm instances simultaneously running from the same image, one with persistent store, the other without.
    I run them with no modification, with the same command
    Code:
    kvm -m 1024 /dev/sda
    to get the grub menu of the host, and I choose the same (!) alternative, Live-Debian without persistence, several times.

    Under kvm, I mount and modify (different) disk partitions on the host. Typically, I can run one instance for database, another for application server (e.g. JBoss), and maybe a third for mailserver.

    This is what I need to develop applications with realistic testing on just one machine.
    While it was not possible to run kvm in the virtual machine, I could run VMware there..

    Performance isn't hopeless, I may try remastering in a VM again.
    There is a definite need for knoppification of several aspects of this live-version, but the need is not desperate.

  5. #15
    Senior Member registered user
    Join Date
    May 2006
    Location
    Columbia, Maryland USA
    Posts
    1,631
    Quote Originally Posted by Capricorny View Post
    Debian-Live has a terrible way to handle overlays. All instances of live-rw encountered are sandwich-mounted together, even if the advertised label mechanism is used. So, basically, for safety one should use just one at a time, renaming the others.

    How bad is this in practice? It turns out, it doesn't have to be that bad. With frequent remasterings, we don't really need much persistent storage for everyday use, and we can mount volumes to get what else we need.
    Have you decoded Debian-Live's minirt.gz?

  6. #16
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    Quote Originally Posted by utu View Post
    Have you decoded Debian-Live's minirt.gz?
    Not so far this time around. I didn't like the init at all when working on a 64 bit version from the Knoppix side 3 years ago.
    So, eventually, it may be knoppified, but it's not something I look forward to.
    Obvious modifications are introductions of parameters fromhd, livedir and live-rw-dir.
    I don't know if it is worthwhile to implement the full Knoppix overlay setup. Because there is a general mechanism in place to mount overlays on given mount points. Which in many ways is more precise.

  7. #17
    Senior Member registered user
    Join Date
    May 2006
    Location
    Columbia, Maryland USA
    Posts
    1,631
    Quote Originally Posted by Capricorny View Post
    Debian-Live has a terrible way to handle overlays.
    Describing a process as 'bad' is not informative.
    I suspect in this case, as in Knoppix's case, the process of combining
    separate images is not bad, per se, but hazardous -unless cerain conditions are met.

    I would like to know if in general one might find a working Debian-Live to
    contain several squashfs images or devices that 'add-up' to a working
    union of the expansions of these images. This should be obvious from the
    decoded minirt.gz.

    AFAIK, Klaus K has never issued any rules for combining images in Knoppix,
    yet he continues to provide and use a latent capability to up to stack seven
    additional images together in Knoppixes 6s & 7s.

    I think the general rule in both Knoppix and Debian-Live might be that
    so long as the expanded images do not land on the same locations with
    different meanings, things will be ok. Segregating the information
    contained onto separate devices may be one way to assure that the union
    of expanded images will not be informationally corrupt.

    I routinely make a read-only Knoppix 1 which contains all my /home tweaks
    and all my added programs. My only current difficulty is in treating a
    troublesome link which must be re-established after every new image is
    added. This is without the precaution of providing /home its separate device.
    Simplistically, adding things works ok, but removing things is problematic
    in the union of expanded filesystem images.

    I'd rather start with a CD-size iso and add things, 'cause all I need works really
    well on 2 Gb SanDisk LiveUSBs. Now that 8 Gb Cruzers are so inexpensive,
    I make DVD-size LiveUSBs and just add fewer things, but it's sure
    wasteful bringing in a lot of stuff I never use, anyway.

    I'm more interested in Debian-Live's live-build on-line capability to
    define and create really tailor-made minimal isos. There's currently no
    similar magic in Knoppix.
    Last edited by utu; 11-25-2014 at 01:24 AM.

  8. #18
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    Utu, believe just what you want to, I am using this the way it is advertised to work, Which does not work. Terrible is no exaggeration. I could also add "pathetic" for the ways the same types of errors keep on cropping up over and over again. And that the Debian standard kernel is at 3.2.0 - which in itself contributes to an own set of problems, not the least in networking.
    Suffice to say that Klaus K has very good reasons for his policies with Knoppix. If you doubt, just give Debian-live a try, really using what are presented as the features.
    Debian-live is designed for multiple overlays, but I doubt many use it. There are lots of bugs, and they are not benign.
    The worst thing, is that you never know when and why things break. It has to do with all the promises that are not kept. For axample, you drop the overlay anywhere, the system just will find it. True? Not quite. I think I have experienced most of the possible combinations of errors during the last 24 hours. Overlay isn't mounted, it is mounted, but not used (that's a really terrible one), it is mounted and crashed, it is sandwich-mounted, it is not correctly updated, it is mounted, but not read correctly.

    None of those problems were ever encoutered during 8 intensive years with Knoppix.

  9. #19
    Senior Member registered user
    Join Date
    May 2006
    Location
    Columbia, Maryland USA
    Posts
    1,631
    Quote Originally Posted by Capricorny View Post
    the Debian standard kernel is at 3.2.0
    I must admit, that's a bit of a shock.

  10. #20
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801

    "Stable" gets kind of new meaning, yes..

    Quote Originally Posted by utu View Post
    I must admit, that's a bit of a shock.
    Of course there have been a few upgrades to that version, but.. On the other hand, come on, it's still not three years old

    Code:
    user@live-debian:/media/sda8$ uname -a
    Linux live-debian 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux
    user@live-debian:/media/sda8$
    The basic philosophy, their "paradigm", is worse, though. How can anyone hit on the idea to use partitions for persistent storage? Even on a small USB stick you would like to be able to place some files there too, outside of the image file. And the raw-copy-iso "installation" method makes it impossible to tweak parameters, while the creation of more user-friendly install versions is delegated to unetbootin et al. I'm not very fond of that bunch, they have been less than reliable to me.

    There are a lot of comical aspects, too. Using gparted to partition the rest of the USB stick after raw copy of the ISO image, it is equipped with a label that Debian truthfully copies to the device name on automount of the stick.
    Resulting in a mount point that the OS is often not able to handle correctly parsing commands, creating errors&problems.

    So I have had to manually unmount, and remount using the more prosaic /media/sdb2. Problems gone.

Page 2 of 3 FirstFirst 123 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
  •