DebianDog64 - 64 bit DebianDog-Jessie

[rufwoof]

Shifting the Tint (bottom) panel over to the left screen edge revealed the KDE tray beneath that. Both seem fully operational/functional

Bit like a underdog setup I guess. Make a KDE sfs to load on demand and perhaps set it to desktop 2

Dragging between rox filer, pcmanfm and dolphin file managers has all three correctly reflecting any changes

[fredx181]

Hi rufwoof,

With hindsight, using
Code:
mksquashfs squashfs-root 01-fs.sfs -comp xz -Xbcj x86 -Xdict-size 524288 -always-use-fragments -nopad -b 524288

The 01-filesystem.squashfs from the 20.03.2016 ISO is made with only -comp -b and -Xbcj options:

Code: Select all

mksquashfs ..... ..... -comp xz -b 524288 -Xbcj x86

I found that using blocksize 1048576 makes it boot and run a little slower, so the gain having smaller file size is not worth it in my opinion.

ISO filesize 152MB
01-filesystem.squashfs filesize 124MB

ISO here

Thanks, will try to test soon, but may take some time (having a little vacation, feeling very tired these days).

Fred

[dancytron]

Never mind, figured it out.

Dan

[dancytron]

Hi everyone.

I just installed my remastered DD64 on to a usb stick as a test. I am seeing an issue that is somewhat similar to the issue I reported here and was fixed. http://www.murga-linux.com/puppy/viewto ... 5&start=30 It may be something as simple as a menu.1st error, I am not sure.

Thanks,

Dan

*************************************

Install was done with installer inside DD64 on sda3 installing from a ISO file to sdc1 (a usb drive). Formatted to ext4 with gparted and used Grub4dos. I am using the Porteus boot (either of the first 2 entries).

Here is my menu.1st file generated by grub4dos.

Code: Select all

# menu.lst produced by grub4dosconfig-v1.7
color white/blue black/cyan white/black cyan/black
timeout 10
default 0

title Debian-PorteusDog  -  changes=EXIT:/live/ (I added this one)
 uuid c82d532c-629d-4555-a784-f1b3e45fda4c
 kernel /live/vmlinuz1 from=/ noauto changes=EXIT:/live/
 initrd /live/initrd1.xz

title Debian-PorteusDog  -  changes to /live/ sysvinit
 uuid c82d532c-629d-4555-a784-f1b3e45fda4c
 kernel /live/vmlinuz1 from=/ noauto changes=/live/
 initrd /live/initrd1.xz

title Debian-PorteusDog  -  Always Fresh sysvinit
 uuid c82d532c-629d-4555-a784-f1b3e45fda4c
 kernel /live/vmlinuz1 from=/ nomagic base_only norootcopy
 initrd /live/initrd1.xz

title Debian-PorteusDog  -  Copy to RAM sysvinit
 uuid c82d532c-629d-4555-a784-f1b3e45fda4c
 kernel /live/vmlinuz1 noauto from=/ copy2ram
 initrd /live/initrd1.xz
 
title DebianDog  -  live-boot-3 Persistence Changes sysvinit
 uuid c82d532c-629d-4555-a784-f1b3e45fda4c
 kernel /live/vmlinuz1 boot=live persistence config quickreboot noeject autologin
 initrd /live/initrd.img

title DebianDog  -  live-boot-3 (no persistence) sysvinit
 uuid c82d532c-629d-4555-a784-f1b3e45fda4c
 kernel /live/vmlinuz1 boot=live config quickreboot noeject autologin
 initrd /live/initrd.img
 
title DebianDog  -  live-boot-3 Copy to RAM sysvinit
 uuid c82d532c-629d-4555-a784-f1b3e45fda4c
 kernel /live/vmlinuz1 boot=live toram=01-filesystem.squashfs
 initrd /live/initrd.img

title Reboot computer
  reboot

Two things happen. It has placed my changes in /live/sda3 (the only linux partition on my computer) instead of sdc1 (the usb stick it is installed on). Also, when I try to open sda3, it has the Debian Dog file system mounted, not the sda3 drive. See screenshot attached.

I managed to find the porteus-livedbg log file. It seems to document what is happening.

Code: Select all

# Recognized devices:
/dev/sda1: LABEL="Old XP" UUID="368C66D28C668C65" TYPE="ntfs" PARTUUID="025f025e-01"
/dev/sda3: LABEL="Puppy 5.2" UUID="3a4a7fe5-6763-4af1-b972-42535e7d8590" TYPE="ext4" PARTUUID="025f025e-03"
/dev/sda4: LABEL="Puppy Swap" TYPE="swap" PARTUUID="025f025e-04"
/dev/sda5: LABEL="MediaData" UUID="6A1C5CFF1C5CC7A9" TYPE="ntfs" PARTUUID="025f025e-05"
/dev/sdb2: LABEL="Internal" UUID="A82454EB2454BDCE" TYPE="ntfs" PARTUUID="c50afefe-02"
/dev/sdb5: LABEL="New XP Pro" UUID="8848056A480557F8" TYPE="ntfs" PARTUUID="c50afefe-05"
/dev/sdc1: UUID="c82d532c-629d-4555-a784-f1b3e45fda4c" TYPE="ext4" PARTUUID="a3f29f5b-01"

# Booting device:
/mnt/sdc1

#  data found in:
/mnt/sdc1///live

# Changes are stored in:
/live/

# Non standard /rootcopy dir:
none

# Modules activated during boot time:
/mnt/sdc1///live/01-filesystem.squashfs
/mnt/sda3//live//changes

[mcewanw]

title Debian-PorteusDog - changes=EXIT:/live/ (I added this one)
uuid c82d532c-629d-4555-a784-f1b3e45fda4c
kernel /live/vmlinuz1 from=/ noauto changes=EXIT:/live/
initrd /live/initrd1.xz

Hello Dan,

I think I've come across this issue before, but I'm not sure. I have a DD64 installation on usb but my partner has that at work today. However, I have a feeling you may need to add root=UUID=xxx to the kernel line (though only Fred might be able to explain why). So I suggest you try the following modification:

Code: Select all

title Debian-PorteusDog  -  changes=EXIT:/live/ (I added this one)
 uuid c82d532c-629d-4555-a784-f1b3e45fda4c
 kernel /live/vmlinuz1 root=UUID=c82d532c-629d-4555-a784-f1b3e45fda4c from=/ noauto changes=EXIT:/live/
 initrd /live/initrd1.xz

Hope that does the job and someone will explain the purpose. I know next to nothing about grub4dos - I just use what I know. From looking at it, I imagine it sets root fs to the device with UUID supplied.

I think the installer program should be modified to make any such change (assuming that is what the 'fix' is).

William

[dancytron]

title Debian-PorteusDog - changes=EXIT:/live/ (I added this one)
uuid c82d532c-629d-4555-a784-f1b3e45fda4c
kernel /live/vmlinuz1 from=/ noauto changes=EXIT:/live/
initrd /live/initrd1.xz

Hello Dan,

I think I've come across this issue before, but I'm not sure. I have a DD64 installation on usb but my partner has that at work today. However, I have a feeling you may need to add root=UUID=xxx to the kernel line (though only Fred might be able to explain why). So I suggest you try the following modification:

Code: Select all

title Debian-PorteusDog  -  changes=EXIT:/live/ (I added this one)
 uuid c82d532c-629d-4555-a784-f1b3e45fda4c
 kernel /live/vmlinuz1 root=UUID=c82d532c-629d-4555-a784-f1b3e45fda4c from=/ noauto changes=EXIT:/live/
 initrd /live/initrd1.xz

Hope that does the job and someone will explain the purpose. I know next to nothing about grub4dos - I just use what I know. From looking at it, I imagine it sets root fs to the device with UUID supplied.

I think the installer program should be modified to make any such change (assuming that is what the 'fix' is).

William

That didn't help. No change.

I'll work on it a little more in a couple of days. Not urgent from my point of view, just a bug that needs to be fixed eventually.

Maybe I'll try running grub4dos on a usb stick from Puppy and see what the menu.1st looks like for comparison.

edit: I tried installing using extlinux instead of grub4dos when it gave me a choice. It was much better, in the sense that it put the /changes directory on the USB stick instead of on my hard drive and the linux partition on my hard drive mounted correctly. However, it didn't mount my usb drive correctly. It mounted the changes directory as sdc1. However, if I browsed to /mnt/sdc1 that was correct.

As an aside, Universal USB Installer from windows works just fine, although only with fat32.

I'll look at this again if I get a chance, but like I said, it is testing for the sake of bug finding, not for my actual use at this point.

[mcewanw]

Hello again Dan,

My partner is back home so I now have my DD64 installation on her usb available to me. It has been set up with grub4dos, grldr and menu.lst on the usb, but I've renamed the grldr files to disable that and have it booting from my harddisk grub4dos menu.lst instead. The configuration is different from yours: I have my live folder in a subdirectory of the second partition on the usb (which is sdb2 on my machine). The path is /DDjessie64usb/live and the menu.lst stanza I have on my harddisk menu.lst is as follows:

Code: Select all

title Debian-PorteusDog64  -  changes to /live/ sysvinit
 uuid 6c05b5ca-00c3-4661-a097-c3346ae2ae15
 kernel /DDjessie64usb/live/vmlinuz1 root=UUID=6c05b5ca-00c3-4661-a097-c3346ae2ae15 from=/DDjessie64usb/ noauto changes=EXIT:/DDjessie64usb/live/
 initrd /DDjessie64usb/live/initrd1.xz

That booted up fine for me and I made a test blank file in /root which was there on reboot, so persistence seems to be working okay.

I'm wondering if you have any other /live directories somewhere on your system causing boot to get mixed up. I always use a unique subdir to avoid issues like that. However, I know the installer program just uses /live so you are quite correct that either way there seems to be a problem with the installer program, though I haven't myself looked into the menu.lst creation details.

William

[fredx181]

Hi Dan, William

I'm wondering if you have any other /live directories somewhere on your system causing boot to get mixed up. I always use a unique subdir to avoid issues like that. However, I know the installer program just uses /live so you are quite correct that either way there seems to be a problem with the installer program, though I haven't myself looked into the menu.lst creation details.

Yes, I think also there's conflict because you have a 'live' directory on the root of hd partition, it will search for a 'live' folder anywhere, but hard-disk has priority over USB, so it will use sda3/live if it exists.
Not the fault of the installer, manually install by copying the files and folders and creating menu.lst with entry "/live/..." would produce the same, indeed, as William said, a unique subdir prevents these kind of problems.

Edit: A unique subdir for changes only should be OK in your case Dan, something like: changes=EXIT:/live/DD64-USB (requires to have created first "/live/DD64-USB" folder on sdb1).

But... as you mentioned Dan, as second issue, that pcmanfm opens sda3 partition as /mnt/live/memory/images/changes-exit , that is a bug in my opinion.
No clue yet how to fix that, it has to do with the fact that /dev/sda3 is mounted twice and pup-volume-monitor picks the first one
Real sda3 partition is at /mnt/sda3 from file-manager , BTW.


Fred

[dancytron]

Hi Dan, William

I'm wondering if you have any other /live directories somewhere on your system causing boot to get mixed up. I always use a unique subdir to avoid issues like that. However, I know the installer program just uses /live so you are quite correct that either way there seems to be a problem with the installer program, though I haven't myself looked into the menu.lst creation details.

Yes, I think also there's conflict because you have a 'live' directory on the root of hd partition, it will search for a 'live' folder anywhere, but hard-disk has priority over USB, so it will use sda3/live if it exists.
Not the fault of the installer, manually install by copying the files and folders and creating menu.lst with entry "/live/..." would produce the same, indeed, as William said, a unique subdir prevents these kind of problems.

Edit: A unique subdir for changes only should be OK in your case Dan, something like: changes=EXIT:/live/DD64-USB (requires to have created first "/live/DD64-USB" folder on sdb1).

But... as you mentioned Dan, as second issue, that pcmanfm opens sda3 partition as /mnt/live/memory/images/changes-exit , that is a bug in my opinion.
No clue yet how to fix that, it has to do with the fact that /dev/sda3 is mounted twice and pup-volume-monitor picks the first one
Real sda3 partition is at /mnt/sda3 from file-manager , BTW.


Fred

I think that something to make the subdirectory more unique ought to be added to the installer. It shouldn't be too hard to add "live-usb" instead of just "live" to the installer. As long as there aren't multiple usb drives with DD installed on it, that ought to get rid of any chance of problems.

The reason is that it is potentially pretty destructive. If you have a user that has a "live" directory on their hard drive who then creates a usb version and lets it save to the hard drive, then they've messed up their /hardrive/changes directory. No real harm, so no foul in my case, since I haven't really been using my DD 32 in the /sda3/live since DD 64 came out, but I could see it destroying someone's install in the right circumstance.

I'll test some more tonight or tomorrow.

[dancytron]

edit 4-25-17 - Bug to fix from Fred:

EDIT: dancytron, I noticed in your chrome-remaster that /etc/fstab is not empty.
It was mistake from the beginning from me, fstab should be empty otherwise there may be problems when someone makes a full install

edit: 3-24-17

I have gone ahead and updated my Debian Dog Chrome Remaster.

ISO file (239 Megabytes):
https://www.dropbox.com/s/hs9lljs0k64g7 ... 3.iso?dl=0

Checksum file:
https://www.dropbox.com/s/9llt4h5ua3bxl ... o.md5?dl=0

From Readme file

Debian Dog 64 Chrome Remaster - Chrome Version 57.0.2987.110 (64-bit)
Linux jessie64 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux

Up to date through March 23, 2017

This is the update of my remaster of Debian Dog 64 with Chrome. Prior version info below.

Just a few new things. I've incorporated the kernel upgrade script and updated the kernel to the latest version.

I've also added a new user "cat" with the password of "cat." The only real difference from user puppy is that the user cat is not in the sudo group. This mainly a useful to allow other people to use your computer without the risk of them screwing up and trashing things.

For the highly security concious/paranoid, the cat id could also be used to run Chrome from the root or puppy user id. See http://distro.ibiblio.org/fatdog/web/faqs/login.html .

I've also added a script to "empty litterbox". This allows you to easily delete all cats Chrome user profile settings and cache files. I've put it on the root desktop for easy access.

For convenience, I've added a script to delete all Chrome user profile settings and cache files for all users. It is also on the root desktop for easy access.

Otherwise, more of the same except newer.

******************************
From 8-21-2016 version
******************************

I've decided to go ahead and publish my Debian Dog Chrome Remaster.

Total size is 225 megabytes.

The main user advantage being that it runs Netflix out of the box with no modification needed.

Unlike Puppy versions of Chrome, the Google Repositories are added and Chrome can be updated by "apt-get upgrade" like any other program in Debian.

I documented every step I took to create it in the Readme.txt file attached. I didn't really understand the menu system entirely, so there are some trial and error workarounds that probably aren't so great, but they seem to work and survive the upgrade process.

ISO file on dropbox.com 225 meg https://db.tt/UF3i8Vn6

MD5 file on dropbox -https://db.tt/UF3i8Vn6

I hope this will get a few more users for DD 64 enabling more feedback and bug finding/fixing.

Edit: 11-14-16

The only thing that has proven to not work is my fairly lame editing of the menu. When you upgrade Chrome, it will replace the .desktop file in /usr/shared/applications, which will make it reappear in the menu. However, it won't work because does not have the correct command line switches (it will work correctly if logged in as puppy).

Either ignore it or delete it every time you do an upgrade.

[mcewanw]

I've decided to go ahead and publish my Debian Dog Chrome Remaster.

Total size is 225 megabytes.

Nice to have a Chrome version for some things. I'll download and try this one.

I've made it clear on here that I'm taking a long break, but I was thinking of long being pretty much permanent, but the more I have thought about it the more I feel I don't want Toni's departure to cause the breakup of DebianDog-related developments.

I hope also that rufwoof will also include his work under the DebianDog hood if some of the developments in there are closely related - that would help boost the DebianDog development team for when Fred becomes more active again. More can be done when a team expands and becomes stable - of course I would like to see Toni come back since his exactness for detail is much missed I feel.

Also, would be good to see these new contributions being documented on DebianDog webpages Fred has created and perhaps link into the main GitHub pages there. Having originally pushed for DebianDog to use GitHub I haven't myself used it since! but if I'm sticking around I'll sharpen up on that again.

It is summer coming here soon though, and I always pretty much vanish for months and most of this current winter I was mucking around developing weX for screencast, which, as the download and feedback statistics suggest (!), was probably a waste of time really (though I like my own work!;-) ).

I don't think Toni did the right thing, and I'd think better of him if he came back in acknowledgement of that, but I also think it is the wrong thing to allow negativeness to take over as a result of things going a bit awry.

William

[dancytron]

Further testing on the installer for usb/grub4dos.

I created a new installation using ext4 on my usb stick.

I modified the menu.1st file as follows:

Code: Select all

title Debian-PorteusDog  -  changes=EXIT:/live/usbchanges/ sysvinit (this entry added)
 uuid 64df9ede-52ec-4631-b562-4f8d56e55b67
 kernel /live/vmlinuz1 from=/ noauto changes=EXIT:/live/usbchanges/
 initrd /live/initrd1.xz

title Debian-PorteusDog  -  changes to /live/usbchanges/ sysvinit
 uuid 64df9ede-52ec-4631-b562-4f8d56e55b67
 kernel /live/vmlinuz1 from=/ noauto changes=/live/usbchanges/
 initrd /live/initrd1.xz

I then added a directory /live/usbchanges.

It now works correctly in all respects!!!

Changes are being recorded in sdc1/live/usbchanges and when I click on sdc1 in the file manager it is showing sdc1 correctly.

[rufwoof]

Running several Debian versions and I have previously experienced weird behaviour likely due to picking up unintended versions. I now try to more clearly differentiate by using sub directories, my 32 bit DebianDog for instance has a menu.lst entry of

Code: Select all

title 2 Debian Jessie 32 only saves if run save2flash
find --set-root /DEBJESSIE32/live/01-filesystemlz4.squashfs
kernel /DEBJESSIE32/live/vmlinuz1 from=/DEBJESSIE32 noauto changes=EXIT:/DEBJESSIE32/live
initrd /DEBJESSIE32/live/initrd1-lz4-addon

As has been previously mentioned the hunt sequence will search for and use the first version it finds and where the HDD tends to be searched first.

I love that 32 bit DebDog, it runs well and is stable, Toni (and Fred) did a outstanding job of it IMO, and one that I keep coming back around to rebooting again. My concern after Toni left the building was a feeling of being left somewhat high and dry, which prompted me to look at the alternatives. The more it and the 64 bit version retains usage/support the better IMO.

[fredx181]

Hi William and everyone

I hope also that rufwoof will also include his work under the DebianDog hood if some of the developments in there are closely related - that would help boost the DebianDog development team for when Fred becomes more active again. More can be done when a team expands and becomes stable - of course I would like to see Toni come back since his exactness for detail is much missed I feel.

Would be very nice if there's a developers team and great if you still like to cooperate in any way William !
If it can be done with pleasure (without any pressure felt) it's OK.
Just guessing, maybe that's where it went wrong for Toni, too much pressure from outside.
Maybe you've seen what he is up to for Jwm version at the moment here:
https://github.com/MintPup/DebianDog-Wheezy

I will get back to the starting point first building base version with only live-boot-2 (without yad, without gtkdialog, without porteus-boot scripts, without /opt directory and sh restored to dash). From this point I will try to make command line scripts for frugal and full install, sfs-load, remaster and some more working with dash. The result from this base will tell how DebianDog-Jwm and MintPup development will continue here for me.

That looks to me that he likes to go back to the beginning of DebianDog without adding any programs borrowed from Puppy and without any of the programs that you (William), Terry or myself produced!.
Not very likely that he will "come back" IMO.

Although having a little break now, I do not plan to quit working on DebianDog development, I'm just contemplating about how.
For example: DebianDog-Jessie 32 bit needs to be upgraded, e.g. bug fixes, new additions, start a new thread? (for upgrade openbox_xfce version ISO (when ready), don't want to touch Jwm version because it's exclusively Toni's project).
Also, indeed, rufwoof's "Debian Live" discoveries might be nice to add to the "new" "fresh" DD project.
Any thoughts are welcome.

Fred

[backi]

Hi fred !
Glad to hear ......sounds quite promising....o.k. relax ...have some fun .

Don`t hurry....just.....be... happy !

Blessings !

[mcewanw]

Would be very nice if there's a developers team and great if you still like to cooperate in any way William !
If it can be done with pleasure (without any pressure felt) it's OK.
Just guessing, maybe that's where it went wrong for Toni, too much pressure from outside.
Maybe you've seen what he is up to for Jwm version at the moment here:
https://github.com/MintPup/DebianDog-Wheezy

I will get back to the starting point first building base version with only live-boot-2 (without yad, without gtkdialog, without porteus-boot scripts, without /opt directory and sh restored to dash). From this point I will try to make command line scripts for frugal and full install, sfs-load, remaster and some more working with dash. The result from this base will tell how DebianDog-Jwm and MintPup development will continue here for me.

That looks to me that he likes to go back to the beginning of DebianDog without adding any programs borrowed from Puppy and without any of the programs that you (William), Terry or myself produced!.
Not very likely that he will "come back" IMO.

Yes, I doubt Toni will be back, but never say never. For me, the interest that DebianDog design creates is that it is not only a hugely cut-down Debian-live compatible distribution, but also has all the pleasures of Puppy-type facilities/utilities. It's the Puppy like fun that makes it so attractive IMO - otherwise we could indeed just download Debian-live and cut it down to tiny size (only to build it up again).

Toni seems to be planning to add commandline utils, which will be interesting and useful, but most people want GUI frontends to such utilities anyway. Yes, maybe the 'external' pressures got too much for Toni, and we can be included in that external number. However, the alternative of having full power over a distribution working on your own comes with the drawback that it is a lonely road when you just build by yourself (and maybe just for yourself). Less pressure of course since no other opinions to worry about or negotiate, but even BarryK used the lots of support puppy forum members provided.

Yes, we could do with new threads to consolidate what will continue as active DebianDogs for the rest of us.

In a way, I am already on a break in that working on weX and scrox was quite intensive for a couple of months actually. The programming was particularly tricky for me (with lots of C to relearn having not programmed in C for 8 years). So that, in addition to the way Toni left, kind of tired me out. Now I am becoming a bit more relaxed again, so more like playing on computers than the burden programming scrox/weX was becoming. Still, I do intend a proper long break, but have decided to start that on 14 September since one of my daughters comes for a visit then.

In the meantime I have been myself playing with distro size-cutting. I'm not usually interested in distro-building work myself since I find the continual rebuilding and rebooting necessary doing such really tedious and the process has too much waiting around for resquashing filesystems and so on. However, I came across 'Reduce Debian' internet page, so been playing with a couple of scripts suggested on there. I'll post about main technique I've been using shortly (though haven't ended up building any new distribution variant myself - just experimenting in case I ever have a go at that (I'd like the tiniest apt-get capable commandline base possible that is DebianDog/Porteus boot capable including DD's cmdline remaster scripts - No X, since would want to add everything else later via apt).

In my playing I have (almost coincidentally) re-visited Frisbee issue when using XenialDog32 on this HP Elitebook of mine. I've been studying its code quite carefully, but the issues I'm having all seem to be timing-related, so somewhat sporadic and hard to pin down.

I've now moved details of that frisbee-related finding over to XenialDog thread.

William

[rufwoof]

Hi William.

For me, Frisbee in both DDJessie 32 and 64 had the (non ROX/JWM) tray icon either permanently (mostly) on or off, and no flashing of any activity. And that was on different PC's as well. My solution was to replace it with wicd which I find works well but requires more libs/dependencies/size I believe.

I'm more inclined towards Debian LiveCD style as a basis for a frugal HDD install and not worry about the size ... as 2GB is almost as trivial/small as 200MB on my system ... disk space is relatively inexpensive nowadays.

Running by default as root is also relatively easy in Debian (although more than frowned upon generally outside of puppy - that said I rather like the Debian KDE blue glow effect around windows as a highlight that you're running as root) and relatively few programs object, but can be worked to comply ... the only exception I've found so far is google chrome - but setting that to run as "user" is relatively trivial and perhaps a good thing anyway. Running root on a single desktop is OK IMO and certainly easier (not having to redo things twice because you forgot you didn't have the authority or access when running as 'user').

With Boot3 style you can run with persistence boot parameter and have all changes immediately preserved to disk; Or persistence persistence-read-only where changes are recorded in memory but lost on reboot, unless you run a save2flash type script; Or you don't specify any persistence boot parameter in which case only the main filesystem.squashfs is booted (no changes loaded). That meets my own personal boot objectives/choices i.e. boot a compressed filesystem instead of a non compressed filesystem (and generally with a fast compressor choice its quicker to IO around half the size + decompression overhead than it is to IO the full sized non compressed data), combined with the option to record changes in memory rather than on disk (so faster running), but with the option to preserve changes if so desired (save2flash or in my case flush2disk).

You can also load sfs's simply by including them alongside /live/filesystem.squashfs ... and even specify the sfs load order is so desired.

The rest of 'puppification' to me induces greater need to support/manage/change things - deviating more away from Debian stability. Not that adoption of some puppy stuff isn't prohibited, I have Fred's DogRadio for instance installed.

Removing un-used locale and man pages/docs alone can reduce Debian down quite a lot. You can strip out functionality or replace with smaller versions, but the more you do so the more of a FrankenDebian you're creating, inducing potential instability or package database corruption. For me the extensive repository (albeit older versions) of software combined with fast security updates is attractive. If I understood correctly I believe Toni was more of a core Debian user over that of drifting towards FrankenDebian. I'm inclined to follow that lead ... which generally speaking reduces things down to adopting the LiveCD based filesystem approach combined with more or less just a single 'save2flash' type script. By the sound of it above and beyond that for Toni was perhaps more of a pain/labour than a joy.

[mcewanw]

If I understood correctly I believe Toni was more of a core Debian user over that of drifting towards FrankenDebian. I'm inclined to follow that lead ... which generally speaking reduces things down to adopting the LiveCD based filesystem approach combined with more or less just a single 'save2flash' type script. By the sound of it above and beyond that for Toni was perhaps more of a pain/labour than a joy.

Well I do know Toni's MAIN point was to make as small a Debian-compatible system as possible. The tricky parts have been reducing the Debian live image size without breaking anything (Toni being particularly good at that), and puppifying it in terms of similar small cutdown apps and sfs load/unload facilities (much of the latter coming from Fred I believe). Indeed, at the early stages (in late 2013), Toni wasn't particularly interested in keeping the Distro multi-user compatible (which ended up needing special care in adopting puppy apps) - it was myself that first pushed for that and Toni then developed a special interest in that 'Debian' purity. In fact Toni confided that his "debian experience" started with Sickgut's Pussy linux and for a short while we had a confusing Volume id of Pussy with published id sickgut in early DD iso. Toni explained that away (though I did wonder for a while if Toni actually was 'Sickgut' back on Puppy under a pseudonym since that would explain some of his attitudes, some apparent personality traits (and maybe even his sudden disappearance), but other aspects of his work and comments didn't seem much like Sickgut at all. And then there was FoxyRoxy... which we later never heard of again. But who knows who anyone on Puppy Linux forum really is!

Aside from the difficulty reducing Debian Live images along with the puppyfying of it, I don't see why DebianDog would have existed as a project at all here since Debian Live framework is already well supported and usable as is. So on one hand we can ask the question, why DebianDog(?), and the answer I suppose was to create a much tinier Debian Live image than the official images provide out-of-the-box, along with some small apps supported with Puppy Linux type flexibility. I think it is or would be more difficult to explain on Puppy murga linux forum if DebianDog was simply a hardly modified Debian Live product. I've not saying one is better than the other, or that DD is better than Puppy Linux - just commenting on why the work proved so hard, no doubt sometimes stressful, but also somewhat satisfying during the now long time since the project was first started in late 2013. It certainly changed (improved IMO) as soon as Fred also came on board a short while after Toni brought the idea up, and the teamwork/collaboration provided a synergy that was a great driving factor for a long time.

William


http://murga-linux.com/puppy/viewtopic. ... 381#747381
Dec 31, 2013

Volume id: Pussy
Volume set id:
Publisher id: sickgut

:) Since my debian experience started with Sickgut's Pussy linux I use to make every debian iso from his one this way:
I open the iso with isomaster and replace the content of /live with new kernel, initrd.img and squashfs + replacing the content in /isolinux the same way. Generate new iso. It makes the iso bootable all the time. Creating iso from the folders is not always bootable. I don't know way.
Haven't even noticed the ID's till now. If someone feels this as a problem download the iso again. It is fixed with empty id now.
BTW my signature here has a link with the same word to Sickgut's thread. If someone does not like to post here because of my signature, sorry, I will not change it. I respect Sickgut's choice of a name for his distro.
...
Cheers, Toni

http://murga-linux.com/puppy/viewtopic. ... 755#741755
Dec 06, 2013

I don't think of this as a separate distro. It is and it will stay pure Debian-live. I will try to make it look more like puppy without breaking its structure (I hope I didn't so far. Testing will show).

http://murga-linux.com/puppy/viewtopic. ... 599#781599
June 06, 2014

Working on what we like is the most important thing, William. Everyone will learn best from own mistakes. I was not always agree with you when you pointed multiuser issue and the need to keep it working for DebianDog but you were the one who made me see my mistakes in the beginning and the advantage to keep multiuser available and working.

For DebianDog History Document...

[mcewanw]

Hi Fred,

Did you ever have any problem with Palemoon. I did, and changed to Firefox, but don't think I posted about the issue, sorry. I think the issue I had was much the same as here:

http://www.murga-linux.com/puppy/viewto ... 486#920486

http://www.murga-linux.com/puppy/viewto ... 635#920635

William

[rufwoof]

@Fred - Point of note

Not confident that your expand overlay code has the desired outcome. I've been testing expanding further by switching to using disk and it would appear that despite being expanded the system doesn't like it when it gets anywhere near much above what the system initially allocated.

A concern of mine is heavy loading and the tendency to slow/lock/crash when using memory space to record changes. Debian for instance move up to the next version using single large updates where all files are first downloaded, then extracted, then installed, so you can have 3 copies of files active at any one time ... that potentially exceeds available memory space within which to record all of those.

Instead I've been looking at using a filesystem file approach to record changes ... which can then be set to any size you choose. Creating such a filesystem file is slow typically due to slow 512 bytes at a time dd write approach. A trick however is to pre-create such a filesystem and then make a sfs of that. 8GB filesystem for instance reduces down to around 100K when compressed with lzo level 1 ... and is very quick to extract (much much quicker than it takes dd to create the same ... for instance on my system time shows unsquashfs of such a 8GB at 0.1 seconds).

The concept I have in mind is to boot with such a savefile ... lets call it CHANGES filesystem file, but counting that as though a disposable overlay of changes. So if the user selects no save at the end of a session then just replace it with a empty version (unsquashfs the 'fresh' copy), or if they opt for save then just leave it as-is so its loaded at the next reboot. Taking that further does involve further action as the user might opt to save one session, but not the next. To address that a save at shutdown might be to make a sfs of the changes recorded in that CHANGES file and replace the CHANGES file with a empty/fresh version, and append that sfs copy to the .squashfs files that are loaded at bootup (i.e. in /live). Taking that a step further forward, during a session a background task might merge multiple sfs's. In filesystem.module you can specify which sfs's are loaded and in which order, so a background task during a session might merge multiple sfs's and then repoint the content of filesystem.module to point to the merged squashfs instead of having multiple squashfs's (some additional housekeeping would also be required to remove old/no longer used copies).

Operationally that would have the impression of shutdown with no save being near instant, and shutdown with save having the additional time of however long it took to make a sfs of the changes filesystem file content (which tends to be quick for more general activity, especially if you use a fast compressor such as lzo level 1). But with some slower responsiveness during a session if/when background tasks were running to merge multiple sfs's. And that's more resilient (can be tuned so that it doesn't crash/lockup if/when memory space is heavily loaded as can occur with the overlay approach).

Some (guideline/example) code snippets :

Initial creation of a changes filesystem file

Code: Select all

dd if=/dev/zero of=changes bs=1G count=8
mkfs.ext2 -F changes
mkdir T
mount changes T/
echo / union >persistence.conf
echo >>persistence.conf
cd ..
umount T
rmdir T 

Create a sfs of that changes filesystem

Code: Select all

mksquashfs changes changes.sfs -comp lzo -Xcompression-level 1

Swap out current changes file for a fresh empty one (as a live running system I tried to make it more resilient so appears somewhat odd).

Code: Select all

#!/bin/bash
unsquashfs -d TMP changes.sfs
mv changes changes.delme
mv TMP/changes .
rmdir TMP
sync
rm -f changes.delme
shutdown -r now 

Grub4dos menu.lst

Code: Select all

title Debian Jessie Frugal
find --set-root /live/frugalboot
kernel /vmlinuz boot=live config nofastboot rw-basemount persistence persistence-path=/live/ persistence-label=changes quickreboot noprompt showmounts live-media-path=/live/ config
initrd /initrd.img

Merge filesystem.squashfs with content of changes stored in 'changes' filesystem file

Code: Select all

mkdir tmp1 tmpa CHANGES
mount changes CHANGES/
mount -o loop filesystem.squashfs tmp1/
mount -t aufs -o br:CHANGES:tmp1 none tmpa/
mksquashfs tmpa filesystem-NEW.squashfs -comp lzo -e persistence.conf
sync
umount tmpa tmp1 CHANGES
rmdir tmpa tmp1 CHANGES
mv filesystem.squashfs delme
mv filesystem-NEW.squashfs filesystem.squashfs
sync
rm -f delme
shutdown -r now