DebianDog64 - 64 bit DebianDog-Jessie

[mcewanw]

EDIT: the reason I was trying to see if system would work without conky is that conky uses about 1% of my CPU - tiny, I know, but I was just striving for minimal dogradio playing

Why not just disable the Dogradio conky-ticker? (from tray-icon menu, see screenshot)
And for the other conky processes you probably know how to disable, e.g. ~/Startup/conkyclock and the entries in autostart.

Fred

You are correct, Fred. That is a much more sensible idea and easy. For some reason I wasn't thinking straight - too many late nights recently! Funnily enough I had even noticed the disable conky setting (in fact I first noticed the function in the dogradio code).

Cheers, William

[mcewanw]

Added to Extra-modules:
Skype module with multi-arch build in, run Skype from Menu> Network after activating.
https://dl.dropboxusercontent.com/u/363 ... e.squashfs

DebDog64-Jessie/Extra-Modules at DropBox
...
Fred

Hi Fred,

Is there a mechanism for having this skype module loaded automatically at boot time? Or is that a problem with dpkg? I tried sticking it in .../live/ folder but that didn't load it on boot.

William

[fredx181]

Hi William

Is there a mechanism for having this skype module loaded automatically at boot time? Or is that a problem with dpkg? I tried sticking it in .../live/ folder but that didn't load it on boot.

Yes, sticking it in the live folder should work, I just tested and works for me, module loaded and Skype runs fine.
Can you see it in the list showing modules loaded at start of porteus boot ?
(assuming you use porteus-boot)

Edit: To avoid misunderstanding: it should be in the "live" frugal install folder where is also 01-filesystem.squashfs, not in the /live system folder.
No problem with dpkg, BTW, it is not dpkg registered.

Fred

[mcewanw]

Hi William

Is there a mechanism for having this skype module loaded automatically at boot time? Or is that a problem with dpkg? I tried sticking it in .../live/ folder but that didn't load it on boot.

Yes, sticking it in the live folder should work, I just tested and works for me, module loaded and Skype runs fine.
Can you see it in the list showing modules loaded at start of porteus boot ?
(assuming you use porteus-boot)

Edit: To avoid misunderstanding: it should be in the "live" frugal install folder where is also 01-filesystem.squashfs, not in the /live system folder.
No problem with dpkg, BTW, it is not dpkg registered.

Fred

Hmmm, that's odd. I thought it should work from frugal live folder too, but in tests neither it nor ffmpeg.sfs were loaded. Since then I've remastered with downloaded skype actually installed (as well as apulse) and so I can't test the modules again right now but I'll create a pristine setup and try again later. I had applied all the stuff mentioned in the fixes post and possibly used remasterdog for something or other prior to trying skype module in live folder - just wondering now if I broke something.

Remastering is such a breeze though and so very useful in DebianDog - way better than just relying on Porteus changes folder, which is what I otherwise usually do. But changes on EXIT: is also a great facility, which is why I prefer DebianDog to the otherwise nice to use official Linux Mint (which my partner admittedly generally uses still...). I've been promising myself to start work on new gtkdialog based app with C backend, which I originally planned out almost a year ago... so I'm trying to settle down in distribution fiddling and get on with that instead, but easily distracted these days unfortunately.

William

[fredx181]

Hmmm, that's odd. I thought it should work from frugal live folder too, but in tests neither it nor ffmpeg.sfs were loaded.

Yes, it is odd indeed for the skype module but not in case of ffmpeg.sfs, it should be renamed to ffmpeg.squashfs. Only modules with .squashfs extension will load at boot (for to activate during a session .sfs works though).

Fred

[mcewanw]

Sorry, my previous comment was inaccurate Fred. The second squashfs file that didn't load was actually libav-tools.squashfs (not ffmpeg.sfs) but I'll try it out again now and report back.

Cheers, William

[mcewanw]

Hmmm, that's odd. I thought it should work from frugal live folder too, but in tests neither it nor ffmpeg.sfs were loaded.

Yes, it is odd indeed for the skype module but not in case of ffmpeg.sfs, it should be renamed to ffmpeg.squashfs. Only modules with .squashfs extension will load at boot (for to activate during a session .sfs works though).

Fred

Sorry, false alarm. I was working too late last night... I happen to have two DDJessie64 distributions on this laptop, one booting into openbox and the other into jwm. I had put the squashfs files into the jwm frugal live folder not noticing that my menu.lst was set to boot the openbox one... hence the squashfs files were of course never seen... sigh...

William

[mcewanw]

x86-64bit (amd64) version of xhippo uploaded (dotpet and deb). Remove dummy tar first if installing deb version. The deb has been quickly tested on DebianDogJessie64. Note that the deb is simply the dotpet converted into a deb package using DebianDogJessie's inbuilt 'Convert pet to deb' utility; it thus installs xhippo binary into /usr/bin (rather than /opt/bin, which was location used in 32bit DebianDog's).

http://www.murga-linux.com/puppy/viewto ... 621#708621

The package includes the xhippo and xrecord GUIs along with the commandline utilities xhplay, xhrecord and make-xhippo-playlist (use --help argument for usage help for these latter utilities: e.g. xhplay --help).

William

[fredx181]

x86-64bit (amd64) version of xhippo uploaded (dotpet and deb). Remove dummy tar first if installing deb version. The deb has been quickly tested on DebianDogJessie64. Note that the deb is simply the dotpet converted into a deb package using DebianDogJessie's inbuilt 'Convert pet to deb' utility; it thus installs xhippo binary into /usr/bin (rather than /opt/bin, which was location used in 32bit DebianDog's).

http://www.murga-linux.com/puppy/viewto ... 621#708621

The package includes the xhippo and xrecord GUIs along with the commandline utilities xhplay, xhrecord and make-xhippo-playlist (use --help argument for usage help for these latter utilities: e.g. xhplay --help).

William

Thanks William!, that was still missing in DD64, I will test soon and add to the repository.

Fred

[mcewanw]

Thanks William!, that was still missing in DD64, I will test soon and add to the repository.

Fred

Yes, I actually compiled it on DDJessie64 Fred.

William

[dancytron]

I got a couple of errors when running an update. Just wanted to report them before I remastered.

Upgraded using synaptic.

When running "reload" (same as apt-get update), I got this:

Code: Select all

W: There is no public key available for the following key IDs:
1397BC53640DB551

I then marked upgradable packages and clicked apply. I got this:

Code: Select all

(synaptic:9051): GLib-CRITICAL **: g_child_watch_add_full: assertion 'pid > 0' failed
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 32694 files and directories currently installed.)
Preparing to unpack .../base-files_8+deb8u4_amd64.deb ...
Unpacking base-files (8+deb8u4) over (8+deb8u3) ...
Setting up base-files (8+deb8u4) ...
Installing new version of config file /etc/debian_version ...
(Reading database ... 32694 files and directories currently installed.)
Preparing to unpack .../libc-bin_2.19-18+deb8u4_amd64.deb ...
Unpacking libc-bin (2.19-18+deb8u4) over (2.19-18+deb8u3) ...
Setting up libc-bin (2.19-18+deb8u4) ...
(Reading database ... 32693 files and directories currently installed.)
Preparing to unpack .../libc6_2.19-18+deb8u4_amd64.deb ...
Unpacking libc6:amd64 (2.19-18+deb8u4) over (2.19-18+deb8u3) ...
Setting up libc6:amd64 (2.19-18+deb8u4) ...
Processing triggers for libc-bin (2.19-18+deb8u4) ...

The second error looks kind of serious, so I chose not to save on exit, so if there is anything you want me to check, I have a clean, pre-update system.

Thanks,


Dan

edit: This isn't the version I was messing around with the logins and slim. It is pretty much stock, other than Chrome instead of Pale Moon.

[fredx181]

Hi Dan,

Sorry for late reply, been busy with xenial:)

W: There is no public key available for the following key IDs:
1397BC53640DB551

Sorry, can't reproduce that, don't know were it comes from, try apt-get update again? Maybe a temporary thing.

(synaptic:9051): GLib-CRITICAL **: g_child_watch_add_full: assertion 'pid > 0' failed

This seems to be a bug from synaptic, see e,g. here (or do a websearch for that message):
https://bugs.debian.org/cgi-bin/bugrepo ... bug=743995

In my opinion this is not a serious bug, I mean it doesn't break anything.

Fred

[dancytron]

Answer in red

Hi Dan,

Sorry for late reply, been busy with xenial:)

W: There is no public key available for the following key IDs:
1397BC53640DB551

Sorry, can't reproduce that, don't know were it comes from, try apt-get update again? Maybe a temporary thing.

Apparently it has to do with updating Chrome from its repository. I found a thread on an Ubuntu site basically concluding it is Google's fault.

edit: I was able to fix it with the instructions on this page. http://unix.stackexchange.com/questions ... get-update Which told me to run this:

Code: Select all

 wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | apt-key add -

[/color]

(synaptic:9051): GLib-CRITICAL **: g_child_watch_add_full: assertion 'pid > 0' failed

This seems to be a bug from synaptic, see e,g. here (or do a websearch for that message):
https://bugs.debian.org/cgi-bin/bugrepo ... bug=743995

In my opinion this is not a serious bug, I mean it doesn't break anything.

Okay, I'll ignore it.

edit: I used apt-get for update this time and there was no error.

Fred

[fredx181]

Hi William, All,

I found that the skype_apulse.squashfs module can break dpkg when it's loaded at boot.
Please use this one (fixed):
https://dl.dropboxusercontent.com/u/363 ... e.squashfs
The older one is replaced by this one in Extra-Modules.
Not that I fully understand (it has to do with multiarch setup), but I ran into this issue (not being able to 'apt-get upgrade') described here:
http://askubuntu.com/questions/134842/d ... 056#203056
Doing this:(the answer), solves it:

Code: Select all

sed -n -e"s,/,\\\\\\\\/,g; s/:$(dpkg --print-architecture)$//p " \
       /var/lib/dpkg/triggers/File \
 | while read line; do
      sudo sed -i -e"/^$line$/d" /var/lib/dpkg/triggers/File
 done

but I thought it's better to prevent the problem by changing the skype module (left out the file /var/lib/dpkg/triggers/File inside it)

William, xhippo uploaded to the repository, thanks again.

Above added to the Changes and fixes list

Fred

[mcewanw]

Hi Fred,

Actually I'm currently settled down with a fattened up DebianDog64, which my partner is also now using. It's big... my 01-remaster_DDJessie64.squashfs is 607 MB in size... However, advantage is I don't really use any additional changes folder/persistence with this (though I have that option via my menu.lst kernel entry with changes=EXIT:/DDjessie64b/live/ - nor am I generally using any extra squashfs modules since most of what I use is built in:

Full KingSoftOffice suite; GIMP; OpenShot; Full Inkscape; Skype + apulse; Adobe Flash; ffmpeg (libavconv actually); Master PDF Edit; wine32; PDFXchangeViewer; Python 2.7 and 3.x, and mesa graphics and so on. Actually I think I even have gcc etc compile build stuff built in - though I can't remember installing that as it happens... So a lot packed in for 600MB size really.

I like having this one big 01-remaster squashfs because it is easy to copy between machines and just works without further thought, except for me fine-tuning it everything occasionally. I also have several Puppy Papp pets converted to deb using pet2deb and installed; stuff like Precord, Peasy DVD player, Peasy PDF convert/join/extract. Plus Xhippo of course! and rdesktop for use with DoMyCommand rdp remote desktop to my partner's work Win10 machine server.

I can always purge programs and remaster again if I need it smaller for some reason. Yes, DebianDog/MintPup/XenialDogs are very flexible, particularly with changes=EXIT: facility and so very easy to remaster to any shape or form wished for. Thanks greatly that Toni started all this and you jumped in to add your spin Fred - terrific system to use and even with this fattened DDJessie64 it's still only using around 118MB RAM or so at startup according to conky display (live Linux Mint Rosa 64bit xfce version uses about three times that much RAM at bootup - I'm using your OpenBox version of DDJessie64 - since the 01-...squashfs is so big I'm not using copy2ram, but its fast enough on this Core2 duo machine anyway).

William

[mcewanw]

Hi Fred,

I have finally gotten round to trying to boot DDjessie64 from SD card and I can confirm it worked fine.

However, I think it important to remark that I used DebDog-installer to put grub4dos on the SD card, but I manually copied over the necessary DDjessie64 files and structure (vmlinuz1 and so on). I wanted to double-check that order of copying was important, which I can confirm it was. When I just copied the live folder over in one lump, the system wouldn't boot, but if I carefully copied vmlinuz1 first (and sync'd), followed by initrd1.xz, then 01-filesystem.squashfs, and then the rest, it booted fine.

I believe the controllers used in SD cards and most usb sticks are pretty simple and act like old fashioned hard disks with BIOS type limitations in evidence such that it is important that vmlinuz1, in particular, is installed 'early'. How early, I'm not sure, and no doubt depends on machines BIOS (assuming normal BIOS here). In my machine it seems to be in first 2 GB of the SD card (I derived that value last time I tried all this). To quickly test, I put two partitions on my SD card (first being fat32 of size 1.5GB, and second being ext2 on which I installed vmlinuz1 before anything else) - that arrangement booted fine. But I also tried same arrangement with larger first partition of around 6 GB and it couldn't then find vmlinuz1 on second partition on boot, even though I installed it first.

I've noted similar issues with usb flash sticks, though I do expect it depends on system used and flash stick controller maybe - but nevertheless, like Toni's old test machine, it is good to test with lowest system capability in mind. Hence I think this confirms the early install (by which I mean copying over of vmlinuz) arrangement of DebDog-installer is good and we shouldn't ever be tempted to simplify that and copy live (or casper) in one go.

Willliam

[mcewanw]

Hi Fred,

I haven't really been bothering about copy2ram capability of Porteus boot method, but inspired by amazing fast performance of Slitaz cooking I'm inspired to work play with DDjessie64 running in RAM (I have 2GB system, so I'm presuming, like Slitaz, that will work).

Unfortunately, I'm not sure it is working for me. When you run 'free utility' using Slitaz it is clear that a lot of RAM is being used (cos the whole thing has been loaded into RAM), but I don't see that altered effect with DDJessie64 - just shows same used RAM as when not using copy2ram on kernel command line. Could you possible kindly try it and post 'free' (or similar) result to show me what to look for. Also, can you tell the whole system is running in RAM via df utility or some other utility?

Thanks, William

EDIT: As far as I recall, Slitaz seems to load everything into tmpfs (from df). I don't have it running just now, so can't check. I wonder if the squashfs get uncompressed into there by Slitaz? But though I don't have DDjessie64 booted with copy2ram at moment, I seem to remember df just showing it as loop mounted somehow - not that I understand most any of these mechanisms very well. Either way, I'm simply not seeing the extreme speed-up effect of Slitaz being completely loaded into RAM.

[Belham]

Hi Fred,

I haven't really been bothering about copy2ram capability of Porteus boot method, but inspired by amazing fast performance of Slitaz cooking I'm inspired to work play with DDjessie64 running in RAM (I have 2GB system, so I'm presuming, like Slitaz, that will work).

Unfortunately, I'm not sure it is working for me. When you run 'free utility' using Slitaz it is clear that a lot of RAM is being used (cos the whole thing has been loaded into RAM), but I don't see that altered effect with DDJessie64 - just shows same used RAM as when not using copy2ram on kernel command line. Could you possible kindly try it and post 'free' (or similar) result to show me what to look for. Also, can you tell the whole system is running in RAM via df utility or some other utility?

Thanks, William

Hi William,

I've a question (or couple really), hope I am not hijacking this thread and/or Fred & your's discussion. I noticed (above in bold) what you wrote, and have always wanted to ask this but sort of shutup for fear of sounding really ignorant. I use both a 64gb SD and/or an old laptop USB-attached 120GB HD. Which I use depends on what I grab first. Both the SD and HD have 'grub4dos' installed on both with Fatdog, and then there are 7 & 12 partitions, respectively. So far, on both the SD and HD, I thus have loaded &use: Fatdog64-710, Slacko 64 6.3.0, Quirky-Xerus64, Tahr64, MX-Linux64 and Peppermint64 Linux (and soon to try Fred's DebianDog64-Jessie). I actually do rotate thru them all, using & enjoying each (they each share a small data partition on their respective drive for browser/email/home folder(s) sync-ing).

My question is thus this: When I am in, say, Fatdog or Slacko or any of the pups (not MX or Peppermint), I have often wondered what happens if I pull the SD card out and/or unplug the USB. Do not all the Puppys run in Ram-mode (my diff computer systems range from 4GB up to 16GB) and thus unplugging from what they booted have no effect (short of screaming if any "save" function is running)? Or have I been assuming this wrongly and you have to specifically load whichever puppy you want via the "copy2ram" you mention (which I assume is in the bootloader of whichever puppy you bootup??).

Outside of the save functions many puppies have, I had just thought all Puppy-versions ran from RAM naturally..... once you booted off a SD and/or USB-related device they were on. Kind of a dumb assumption, I guess

[rufwoof]

To my non-tech mind I have a simple mental vision of half of available ram being allocated to the front end system, half to back end. So if all of the system fits in available ram once read its all memory bound.

copy2ram will copy the entire system into ram in a single (slow) pass during bootup (assuming it fits). Without copy2ram its copied in bit by bit, as required (and once copied in may remain in memory thereafter). Libre Office for instance will take longer to load the first time, but quicker thereafter assuming its remained memory bound.

Much of the system might never be used during a session. gparted for instance is rarely used. With copy2ram that takes up memory space even though (potentially) not being used. With copy as-when if not invoked it doesn't take up memory space - but if you have more than enough memory anyway that's not a problem.

A benefit of copy2ram is that assuming it does all fit into memory, then once copied you can remove the medium from which it was copied. On the fly copying however requires that the medium remains available throughout the session.

Much of Linux memory monitoring is at best just a guide - more to show loading than actual (so you can see if there are runaway processes) as there's also paging in/out, swap file space ..etc factors involved. The likes of Puppy are typically smaller than the average more recent PC's available memory, so more often will run all in ram, once copied in. That copying can either be done all at once at bootup, or bit by bit as running.

Similar in some respects to the Load icon in some Puppy's tray - that shows the number of processes running, so again you get a feel if there are runaway processes possibly repeatedly spawning processes so that you can take corrective measures to kill those runaways.

Something like when a program is required Linux will look at primary front end memory, and if not there look into back end memory, and if not there look into swap, and if not there read it from disk. And where programs get moved around in memory (move something else that hasn't been used for a while from front end to back end to make space in front end for something that is being invoked ... or from back end to swap ...etc.). Just way too complicated for a single figure to accurately reflect the current memory status.

[mcewanw]

Outside of the save functions many puppies have, I had just thought all Puppy-versions ran from RAM naturally..... once you booted off a SD and/or USB-related device they were on. Kind of a dumb assumption, I guess :oops:

Hi Belham,

It is important to realise that DebianDog is not a Puppy per se, its a slimmed-down, and modified, version of Debian Live, so its copy to ram boot functions are different. It also has several different booting mechanisms, one of which, Porteus boots, needs a kernel line entry copy2ram in order to bring everything into RAM at boot time. I'm just asking Fred to check that is actually happening, because I can't myself see evidence in terms of better system performance or RAM usage figure reflecting the main squashfs file loaded into RAM. I'm also wondering if it is loaded into RAM compressed or uncompressed.

Standard Puppies has its own load into RAM mechanisms, which I can't remember, but suspect you may be correct that it will happen automatically if you have a large amount of RAM. I can't swear to that at all though, and some Puppy creations may be different so someone more expert on Puppy boot will have to answer your question.

William