Create Debian 9 (Stretch) minimal ISO similar to DebianDog

Message

rcrsn51 · #901 Post by **rcrsn51** » Tue 12 Dec 2017, 18:13

Thanks. They look good.

rcrsn51 · #902 Post by **rcrsn51** » Wed 13 Dec 2017, 13:26

Batteries provide information to the OS in a variety of ways. Batterup is a fully customizable monitor that should work with any battery. This is particularly useful with old or replacement batteries that give misleading data.

Batterup displays the time/charge/power/voltage remaining until shutdown and pops up a warning message when the battery is getting low.

Note: The Batterup tray icon does NOT change its appearance with the status of the battery - use a mouse-over. To see the time remaining, the charger must be UNplugged. Wait a moment for the information to update.

Update: V1.3 has an auto-shutdown feature. If you don't respond to the warning message for two minutes, Batterup will run a poweroff command.

--------------------------------

The default warning time is 10 minutes. To change it, do the following:

1. Go to the folder /root/Startup
2. Open the file batterup_start in a text editor.
3. Modify Line 11:

Code: Select all

UNITS=min
WARNTIME=10

4. Run System > Batterup restart

------------------------

Some batteries are calibrated using energy (mWh) instead of charge (mAh). Set the time remaining with:

Code: Select all

UNITS=MIN
WARNTIME=10

If your battery doesn't provide useful timing information to Batterup, you can use the amount of charge remaining. This will take some trial-and-error to calibrate. For example, try 10% of the full charge value:

Code: Select all

UNITS=mAh
WARNTIME=500

Or use the amount of energy remaining:

Code: Select all

UNITS=mWh
WARNTIME=3000

If none of those options work, switch to the minimum voltage in milliVolts.

Code: Select all

UNITS=mV
WARNTIME=9500

In each case, you will need some testing to find the setting that works best with your battery.

---------------------

fredx181 · #903 Post by **fredx181** » Wed 13 Dec 2017, 18:54

Added to repos: Google-drive Filemanager, deb packages:
32-bit deb: https://fredx181.github.io/StretchDog/i ... 0_i386.deb
64-bit deb:https://fredx181.github.io/StretchDog/a ... _amd64.deb
Or install with Synaptic or apt-get : googledrivegui
Info, pet packages and portable version, see here:
http://murga-linux.com/puppy/viewtopic.php?t=112322

@rcrsn51, thanks, added batterup to repos, can't test at the moment, laptop on AC power (battery dead) will do later when I get the chance.

Fred

fredx181 · #904 Post by **fredx181** » Fri 15 Dec 2017, 19:14

Google-drive Filemanager updated to v0.2.0

32-bit deb v0.2.0: https://fredx181.github.io/StretchDog/i ... 0_i386.deb
64-bit deb v0.2.0:https://fredx181.github.io/StretchDog/a ... _amd64.deb
Or upgrade with Synaptic or apt-get : googledrivegui
Changes info here:
http://murga-linux.com/puppy/viewtopic.php?t=112322

Fred

fredx181 · #905 Post by **fredx181** » Sat 16 Dec 2017, 20:21

fredx181 wrote:@rcrsn51, thanks, added batterup to repos, can't test at the moment, laptop on AC power (battery dead) will do later when I get the chance.

Hi Bill, got a battery now and tested batterup, but maybe something is wrong with my battery because it takes forever to get fully charged.
Also I tried "fdpowermon" (it's in Debian repo) , btw, did you check that ?
With fdpowermon it's In fact the same for me (taking forever to reach 100%) but at some point it shows a (promising) 99% saying only a few minutes to go, but gets stuck on that (but maybe I have to be more patient

)

Fred

rcrsn51 · #906 Post by **rcrsn51** » Sat 16 Dec 2017, 20:27

That's not unusual. What does the LED indicator on your laptop show? It is the final judge on the state of charging.

In the case of Batterup, unplug the charger to see the time remaining.

fredx181 · #907 Post by **fredx181** » Sat 16 Dec 2017, 21:59

rcrsn51 wrote:That's not unusual. What does the LED indicator on your laptop show? It is the final judge on the state of charging.

Ah, yes, goes from orange to green at some point and then when I unplug the charger it shows 130 min remaining, OK for me !
Another nice contribution from you, thanks, repos still have v1.2, will add 1.3 soon.

Fred

rcrsn51 · #908 Post by **rcrsn51** » Mon 18 Dec 2017, 12:36

Hi Fred: I ran the upgrade-kernel procedure on one of my Stretch-Live installs and it was a success.

I then took the new /lib/modules/4.9.0-4-686-pae folder and converted it into a squashfs module.

I dropped that module, the new vmlinuz1 and initrd1.xz files into another install. That appeared to do a kernel switch without having to run the upgrade procedure..

Is there any downside to this method?

Bill

fredx181 · #909 Post by **fredx181** » Mon 18 Dec 2017, 18:39

Hi Bill, what you did should work well, but the downside can be that the newer kernel (linux-image package) is not registered by the package management.
For example, In your other install, when you run now upgrade-kernel, dpkg or apt doesn't know about the up-to-date linux-image version and will do the "upgrade" to the same version you already have (otherwise it would say "already the newest version"), so upgrade-kernel is sort of useless then.
EDIT: On second thought, I think so, but not sure that the above will happen, didn't test that actually)

Fred

rcrsn51 · #910 Post by **rcrsn51** » Tue 19 Dec 2017, 16:51

Hi Fred:

If I run the mklive script today, which kernel will I get? -03 or -04?

Bill

fredx181 · #911 Post by **fredx181** » Tue 19 Dec 2017, 18:30

rcrsn51 wrote:Hi Fred:

If I run the mklive script today, which kernel will I get? -03 or -04?

Bill

The -04, sometime ago changed to that.
http://murga-linux.com/puppy/viewtopic. ... 017#975017

Fred

dancytron · #912 Post by **dancytron** » Tue 19 Dec 2017, 18:38

Quick question.

I've been using Bleachbit to cut down on the size of my changes folder.

I've noticed 2 files that I am 99% sure get created by synaptic or apt-get the first time you reload the repository databases after a remaster. They are /var/cache/apt/pkgcache.bin /var/cache/apt/srcpkgcache.bin. They are about 26 meg each.

Are these just an apt-get/synaptic cache that I can safely tell bleachbit to delete that will be regenerated when I reload the repositories with apt-get update or synaptic reload? Or should I leave them alone?

Thanks,

Dan

backi · #913 Post by **backi** » Tue 19 Dec 2017, 18:52

Hi Dancytron !

Here is what i experienced .
Using Bleachbit does not delete pkgcache.bin and srcpkgcache.bin ........i always have to delete them manually.
When reloading Repos ....they will be regenerated .
Could not discover any Downside........but can not guaranty if there are any .Maybe somebody else knows .

Regards !

fredx181 · #914 Post by **fredx181** » Tue 19 Dec 2017, 18:56

Hi Dan,

Are these just an apt-get/synaptic cache that I can safely tell bleachbit to delete that will be regenerated when I reload the repositories with apt-get update or synaptic reload?

Sure, these are regenerated when reload with Synaptic or apt-get update, so can be safely removed by using bleachbit.
(same goes for content of /var/lib/apt/lists/ , btw)

Fred

dancytron · #915 Post by **dancytron** » Tue 19 Dec 2017, 19:43

fredx181 wrote:Hi Dan,

Are these just an apt-get/synaptic cache that I can safely tell bleachbit to delete that will be regenerated when I reload the repositories with apt-get update or synaptic reload?
Sure, these are regenerated when reload with Synaptic or apt-get update, so can be safely removed by using bleachbit.
(same goes for content of /var/lib/apt/lists/ , btw)

Fred

Ok, I added them to bleachbit.

Interestingly, when Bleachbit deletes them, they instantly come back but in a much smaller size (1.1 meg and .45 meg). When I run apt-get update, they get regenerated back to normal and everything works as it should.

Thanks,

Dan

belham2 · #916 Post by **belham2** » Wed 20 Dec 2017, 09:06

Hi Fred, Rsrcn51, Dancytron & all (Happy Holidays to everyone

),

I've got a question, and apologies if this has been covered already.

I've an XFCE-Stretch-build, frugal-installed, that I've been running and using for (~4-5) months now. Today, trying to read several of the latest pages in this thread so I can somewhat keep abreast of things, I noticed this thread from Fred:

http://murga-linux.com/puppy/viewtopic. ... 873#975873

Then I also noticed msgs from Rsrcn51 (on this page) about doing an kernel upgrade.

My question: on this XFCE-stretch-build of mine, I am still using:

Code: Select all

root@live:~# uname -a
Linux live 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux
root@live:~#

Is it "best' (or strongly recommended) that I upgrade to the 04-kernel using the script, or is it ok that I stay using this kernel? I guess what I am trying to ask, is that currently everything runs great and I have no problems (and I keep everything 'updated' via Synaptic). But I am wondering if I "do not" upgrade to the latest kernel, I'll be faced with problems & issues down the road.

Thanks for any advice

fredx181 · #917 Post by **fredx181** » Wed 20 Dec 2017, 11:31

Hi Belham, happy holidays to you too !

Is it "best' (or strongly recommended) that I upgrade to the 04-kernel using the script, or is it ok that I stay using this kernel? I guess what I am trying to ask, is that currently everything runs great and I have no problems (and I keep everything 'updated' via Synaptic). But I am wondering if I "do not" upgrade to the latest kernel, I'll be faced with problems & issues down the road.

I'd say there's nothing wrong with staying on kernel 4.9.0-3 if all works fine for you.
It's still available in the stretch repos and I think if there would be security risk (or some serious other bug), the Debian maintainers would remove it from the repos.
The reason for me to change "upgrade-kernel' was to give support in case anyone wants to use the newest Stretch kernel.
(To be honest, I didn't investigate what are the changes in 4.9.0-4 compared to 4.9.0-3)

Fred

belham2 · #918 Post by **belham2** » Wed 20 Dec 2017, 15:19

fredx181 wrote:Hi Belham, happy holidays to you too !

Is it "best' (or strongly recommended) that I upgrade to the 04-kernel using the script, or is it ok that I stay using this kernel? I guess what I am trying to ask, is that currently everything runs great and I have no problems (and I keep everything 'updated' via Synaptic). But I am wondering if I "do not" upgrade to the latest kernel, I'll be faced with problems & issues down the road.
I'd say there's nothing wrong with staying on kernel 4.9.0-3 if all works fine for you.
It's still available in the stretch repos and I think if there would be security risk (or some serious other bug), the Debian maintainers would remove it from the repos.
The reason for me to change "upgrade-kernel' was to give support in case anyone wants to use the newest Stretch kernel.
(To be honest, I didn't investigate what are the changes in 4.9.0-4 compared to 4.9.0-3)

Fred

[EDIT]: Ooops, sorry, Fred, ignore this. I completely overlooked the fact that since I did a quick remaster this morning---man your remaster-scripts & options are light years ahead of puppy in terms of ease of use---that I needed to "reload" Synaptic. Haha, apologies again

....all the programs, and everything else, are there now.......]

Thanks, Fred!

Had another question: downloaded some pdf(s) the other day, went to open them, and realized I didn't include a pdf program in my xfce-stretch-build. So I opened Synaptic but I am confused: synaptic (which is updated and has all the debian repos appropriately check marked, I think) says that none of the pdf prgrams are available for download (atril, evince, okular and qpdf). ???

fredx181 · #919 Post by **fredx181** » Wed 20 Dec 2017, 21:37

Fix for "upgrade-kernel", new version 1.0.4, install from Synaptic (first 'Reload') or with apt-get:

Code: Select all

apt-get update
apt-get install upgrade-kernel

Previously (with v1.0.3) could upgrade the kernel from 4.9.0-3 to 4.9.0-4, but once 4.9.0-4 installed it couldn't upgrade to a newer (if available) (sub)version of 4.9.0-4
(seems like Debian maintainers stay now on 4.9.0-4, and upgrade (if available) to a new (sub)version number)
Upgrading to a new (sub)version of 4.9.0-4 should now be possible with upgrade-kernel.
(e.g. I had earlier upgraded to 4.9.0-4 with (sub)version number: 4.9.51-1 and now could upgrade to latest (sub)version number: 4.9.65-3)
(with v1.0.3 it said "already newest version" which was incorrect, fixed now)

Fred

rcrsn51 · #920 Post by **rcrsn51** » Thu 21 Dec 2017, 16:17

Hi Fred:

I ran mklive this morning. I manually updated my version of the script to "-4" and it ran fine.

But I have a problem. I usually boot these from ISObooter which has always worked fine with all the dogs.

But this time, I get

mount: mounting aufs on /union failed: no such device
cant setup union (aufs) - read only filesystem?

Any suggestions?

Bill

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Create Debian 9 (Stretch) minimal ISO similar to DebianDog