Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 16 Oct 2019, 16:26
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
DebianDog64 - 64 bit DebianDog-Jessie
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 16 of 38 [560 Posts]   Goto page: Previous 1, 2, 3, ..., 14, 15, 16, 17, 18, ..., 36, 37, 38 Next
Author Message
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Fri 29 Apr 2016, 03:44    Post subject:  

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

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Fri 29 Apr 2016, 03:57    Post subject:  

fredx181 wrote:
William wrote:
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

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Sat 30 Apr 2016, 10:01    Post subject: x86-64bit (amd64) version of xhippo uploaded  

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/viewtopic.php?p=708621#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

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
fredx181


Joined: 11 Dec 2013
Posts: 4123
Location: holland

PostPosted: Sat 30 Apr 2016, 12:01    Post subject: Re: x86-64bit (amd64) version of xhippo uploaded  

mcewanw wrote:
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/viewtopic.php?p=708621#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
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Sun 01 May 2016, 00:46    Post subject: Re: x86-64bit (amd64) version of xhippo uploaded  

fredx181 wrote:


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

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
dancytron

Joined: 18 Jul 2012
Posts: 1372

PostPosted: Sun 01 May 2016, 15:45    Post subject:  

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:
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:
(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.
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 4123
Location: holland

PostPosted: Mon 02 May 2016, 14:36    Post subject:  

Hi Dan,

Sorry for late reply, been busy with xenial:)

Quote:
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.

Quote:
(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/bugreport.cgi?bug=743995

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

Fred
Back to top
View user's profile Send private message 
dancytron

Joined: 18 Jul 2012
Posts: 1372

PostPosted: Mon 02 May 2016, 14:48    Post subject:  

Answer in red
fredx181 wrote:
Hi Dan,

Sorry for late reply, been busy with xenial:)

Quote:
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/75807/no-public-key-available-on-apt-get-update Which told me to run this:

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


Quote:
(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/bugreport.cgi?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
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 4123
Location: holland

PostPosted: Mon 02 May 2016, 16:33    Post subject:  

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/36381953/DebDog64-Jessie/Extra-Modules/skype_apulse.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/dpkg-error-duplicate-file-trigger-interest-for-filename-usr-lib-gio-modules/203056#203056
Doing this:(the answer), solves it:
Code:
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
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Mon 09 May 2016, 05:08    Post subject:  

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

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Sun 15 May 2016, 08:04    Post subject:  

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

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Fri 20 May 2016, 02:39    Post subject:  

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.

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
Belham

Joined: 07 Jan 2016
Posts: 133

PostPosted: Fri 20 May 2016, 05:49    Post subject:  

mcewanw wrote:
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 Embarassed
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3541

PostPosted: Fri 20 May 2016, 06:55    Post subject:  

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.
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Fri 20 May 2016, 08:24    Post subject:  

Belham wrote:

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

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 16 of 38 [560 Posts]   Goto page: Previous 1, 2, 3, ..., 14, 15, 16, 17, 18, ..., 36, 37, 38 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1490s ][ Queries: 13 (0.0798s) ][ GZIP on ]