DebianDog - Jessie - Continued
-
- Posts: 40
- Joined: Mon 10 Oct 2016, 12:23
Looks like there is several methods to resolve time issues) I would like to add even more)) Unfortunately time zone is required for some apps to operate correctly (twitter for example).
My notes says that after setting time zone run which binds your time zone to your hardware clock (bios), for displaying TZ current settings.
Full article here https://www.linuxbabe.com/desktop-linux ... e-in-linux
My notes says that after setting time zone run
Code: Select all
timedatectl set-local-rtc 1
Code: Select all
timedatectl status
Full article here https://www.linuxbabe.com/desktop-linux ... e-in-linux
Hi Belham,
I wrote earlier that I added redshiftgui .deb also to the DD64 repository, well, that one didn't work on DD64 (Oooff... I should test first before uploading in the future... )
Fixed now though, so to install on DD64:
Fred
I wrote earlier that I added redshiftgui .deb also to the DD64 repository, well, that one didn't work on DD64 (Oooff... I should test first before uploading in the future... )
Fixed now though, so to install on DD64:
Code: Select all
apt-get update
apt-get install --reinstall redshiftgui # --reinstall in case already installed the previous one
Hi Fred,fredx181 wrote:Hi Belham,
I wrote earlier that I added redshiftgui .deb also to the DD64 repository, well, that one didn't work on DD64 (Oooff... I should test first before uploading in the future... )
Fixed now though, so to install on DD64:FredCode: Select all
apt-get update apt-get install --reinstall redshiftgui # --reinstall in case already installed the previous one
No worries!! I have been playing with this latest Debiandog so much I haven't gotten around to install redshift on my DD64. So I am lucky, haha
Thank you again for doing this latest DebianDog....I was worried, with everything that went on and how Toni acted (which is one of those things I'll never understand) that it might have made you want to give up & quit. But boy you sure didn't. And you even came back stronger with putting XFCE in----I can't begin to describe (for me, at least) how much easier XFCE is to deal with than when I was modding Tint2rc---which can be a pain at times. Tint2rc is great and all, but XFCE is another world, imho, both simple & elegant, and basically just as fast.
P.S. I truly wonder if Puppy enthusiasts realize that the 'keeping your OS up-to-date with critical security flaws is a brain-dead easy with the DebianDogs? I mean, you install "unattended-upgrades" via the terminal, and you never have to worry about it again. It has changed how I view puppies overall, and imho, gives other pups & pup-related OSes something to shoot for. Slacko repos are great and all, but Debian repos seem to get stuff out faster, with less problems.
VERY Nice Fred!
So far I've just tweaked the initial bootup, but looking around everything else I have briefly looked at looks fine.
Switching to using lz4 compressed filesystem squashfs and lzo compressed initrd1.lzo instead of initrd1.xz, combined with swapping out frisbee for wicd (and turning frisbee and conky off), shaves around 4.5 seconds of bootup time for me (down from 17 to 12.5 seconds)
Frisbee was a clear bottleneck
Frugal to HDD. Grub4dos menu.lst entry of :
title DD V2 (32 bit) only saves if run save2flash
find --set-root /DD/live/jessie-i486.sgn
kernel /DD/live/vmlinuz1 init=/bin/systemd from=/DD noauto changes=EXIT:/DD/live
initrd /DD/live/initrd1.lzo
Running boot times analysis :
root@jessie:~# systemd-analyze plot >p.svg
(had to convert from svg to jpg in order to post to free image hosting service as they don't cater for .svg files)
In short, gzip'd main filesystem, lzo compressed initrd and swapping out frisbee for wicd, at least on my system, improved boot speed.
lz4 and gzip were similar overall in speed, but lz4 has more IO (less compression) than zip (faster to decompress than gzip, but more work (data size) to do than gzip, overall comparable). lz4 however is nicer for remastering (quicker).
So far I've just tweaked the initial bootup, but looking around everything else I have briefly looked at looks fine.
Switching to using lz4 compressed filesystem squashfs and lzo compressed initrd1.lzo instead of initrd1.xz, combined with swapping out frisbee for wicd (and turning frisbee and conky off), shaves around 4.5 seconds of bootup time for me (down from 17 to 12.5 seconds)
Frisbee was a clear bottleneck
Frugal to HDD. Grub4dos menu.lst entry of :
title DD V2 (32 bit) only saves if run save2flash
find --set-root /DD/live/jessie-i486.sgn
kernel /DD/live/vmlinuz1 init=/bin/systemd from=/DD noauto changes=EXIT:/DD/live
initrd /DD/live/initrd1.lzo
Running boot times analysis :
Code: Select all
Booting filesystem squashfs lz4 remastered of original (filesize 332.4MB)
root@jessie:~# systemd-analyze
Startup finished in 7.160s (kernel) + 9.562s (userspace) = 16.722s
root@jessie:~# systemd-analyze blame
5.224s frisbee.service
1.953s networking.service
1.382s keyboard-setup.service
680ms start-pup-volume-monitor.service
528ms loadcpufreq.service
492ms systemd-logind.service
479ms lm-sensors.service
472ms pppd-dns.service
280ms udev-finish.service
258ms rc-local.service
256ms rsyslog.service
211ms systemd-journal-flush.service
211ms kbd.service
203ms console-setup.service
132ms cpufrequtils.service
115ms systemd-random-seed.service
114ms dev-hugepages.mount
113ms kmod-static-nodes.service
112ms systemd-update-utmp.service
99ms systemd-tmpfiles-setup-dev.service
87ms systemd-udev-trigger.service
85ms dev-mqueue.mount
83ms sys-kernel-debug.mount
73ms systemd-modules-load.service
50ms systemd-setup-dgram-qlen.service
43ms systemd-user-sessions.service
39ms systemd-remount-fs.service
28ms systemd-sysctl.service
13ms systemd-tmpfiles-setup.service
9ms systemd-update-utmp-runlevel.service
8ms systemd-udevd.service
7ms live-tools.service
2ms sys-fs-fuse-connections.mount
root@jessie:~#
Booting standard (gzip'd filesystem squashfs filesize 238.1MB)
root@jessie:~# systemd-analyze
Startup finished in 7.585s (kernel) + 9.483s (userspace) = 17.069s
root@jessie:~# systemd-analyze blame
5.183s frisbee.service
2.006s networking.service
1.395s keyboard-setup.service
653ms start-pup-volume-monitor.service
600ms systemd-logind.service
569ms lm-sensors.service
564ms pppd-dns.service
561ms loadcpufreq.service
321ms rsyslog.service
270ms dev-mqueue.mount
265ms rc-local.service
256ms sys-kernel-debug.mount
249ms dev-hugepages.mount
243ms udev-finish.service
208ms console-setup.service
175ms sys-fs-fuse-connections.mount
158ms systemd-udev-trigger.service
131ms systemd-tmpfiles-setup-dev.service
112ms kbd.service
97ms cpufrequtils.service
76ms kmod-static-nodes.service
57ms systemd-udevd.service
48ms systemd-setup-dgram-qlen.service
36ms systemd-sysctl.service
29ms systemd-journal-flush.service
27ms systemd-modules-load.service
24ms systemd-update-utmp.service
19ms systemd-user-sessions.service
16ms systemd-tmpfiles-setup.service
11ms systemd-random-seed.service
8ms systemd-update-utmp-runlevel.service
5ms live-tools.service
4ms systemd-remount-fs.service
root@jessie:~#
Uncompressing initrd1.xz and booting using lz4 compressed filesystem
root@jessie:~# systemd-analyze
Startup finished in 5.928s (kernel) + 9.616s (userspace) = 15.544s
root@jessie:~# systemd-analyze blame
5.219s frisbee.service
2.003s networking.service
1.378s keyboard-setup.service
579ms loadcpufreq.service
525ms start-pup-volume-monitor.service
490ms systemd-logind.service
472ms lm-sensors.service
465ms pppd-dns.service
299ms rc-local.service
245ms udev-finish.service
221ms kbd.service
213ms console-setup.service
185ms cpufrequtils.service
165ms systemd-journal-flush.service
151ms systemd-random-seed.service
136ms rsyslog.service
121ms kmod-static-nodes.service
117ms dev-hugepages.mount
116ms dev-mqueue.mount
114ms sys-kernel-debug.mount
94ms systemd-udev-trigger.service
93ms systemd-update-utmp.service
69ms systemd-tmpfiles-setup-dev.service
50ms systemd-modules-load.service
49ms systemd-setup-dgram-qlen.service
26ms systemd-user-sessions.service
25ms sys-fs-fuse-connections.mount
24ms systemd-remount-fs.service
14ms systemd-sysctl.service
11ms systemd-update-utmp-runlevel.service
10ms systemd-tmpfiles-setup.service
9ms systemd-udevd.service
8ms live-tools.service
root@jessie:~#
booting with busybox lzop initrd (lzo compressed) and lz4 compressed filesystem squashfs
root@jessie:~# systemd-analyze
Startup finished in 5.959s (kernel) + 9.550s (userspace) = 15.509s
root@jessie:~# systemd-analyze blame
5.228s frisbee.service
2.117s networking.service
1.387s keyboard-setup.service
612ms start-pup-volume-monitor.service
511ms loadcpufreq.service
469ms systemd-logind.service
451ms lm-sensors.service
444ms pppd-dns.service
367ms rsyslog.service
288ms console-setup.service
255ms rc-local.service
225ms udev-finish.service
169ms dev-hugepages.mount
165ms kmod-static-nodes.service
161ms kbd.service
149ms systemd-udev-trigger.service
116ms dev-mqueue.mount
114ms sys-kernel-debug.mount
82ms cpufrequtils.service
61ms systemd-tmpfiles-setup-dev.service
56ms systemd-modules-load.service
52ms systemd-journal-flush.service
49ms systemd-setup-dgram-qlen.service
48ms systemd-user-sessions.service
24ms systemd-random-seed.service
21ms systemd-update-utmp.service
13ms systemd-sysctl.service
13ms sys-fs-fuse-connections.mount
11ms systemd-remount-fs.service
10ms systemd-udevd.service
9ms systemd-tmpfiles-setup.service
8ms systemd-update-utmp-runlevel.service
4ms live-tools.service
root@jessie:~#
Installed WICD removed frisbee, commented ~/.config/openbox/autostart.sh to look like
#!/bin/sh
xfdesktop &
xfce4-panel &
sleep 2
xfce4-clipman &
#sleep 2
#frisbee-tray &
#wait $!
#sleep 1
#if [ -f /mnt/live/tmp/modules ]; then
#conky -c ~/.conkyrc-port &
#else
#conky -c ~/.conkyrc-live &
#fi
#wait $!
volumeicon
root@jessie:~# systemd-analyze
Startup finished in 5.923s (kernel) + 6.597s (userspace) = 12.520s
root@jessie:~# systemd-analyze blame
2.406s networking.service
2.361s wicd.service
1.004s keyboard-setup.service
998ms start-pup-volume-monitor.service
834ms loadcpufreq.service
778ms systemd-logind.service
749ms lm-sensors.service
745ms alsa-restore.service
743ms frisbee.service
742ms pppd-dns.service
612ms rc-local.service
294ms console-setup.service
290ms rsyslog.service
285ms kbd.service
255ms systemd-journal-flush.service
197ms systemd-tmpfiles-setup.service
155ms systemd-random-seed.service
150ms cpufrequtils.service
146ms kmod-static-nodes.service
146ms dev-hugepages.mount
134ms dev-mqueue.mount
133ms sys-kernel-debug.mount
109ms systemd-udev-trigger.service
91ms udev-finish.service
80ms systemd-modules-load.service
62ms systemd-update-utmp.service
59ms systemd-tmpfiles-setup-dev.service
59ms systemd-setup-dgram-qlen.service
33ms systemd-sysctl.service
31ms systemd-user-sessions.service
30ms systemd-remount-fs.service
10ms systemd-update-utmp-runlevel.service
7ms sys-fs-fuse-connections.mount
6ms live-tools.service
4ms systemd-udevd.service
(had to convert from svg to jpg in order to post to free image hosting service as they don't cater for .svg files)
In short, gzip'd main filesystem, lzo compressed initrd and swapping out frisbee for wicd, at least on my system, improved boot speed.
lz4 and gzip were similar overall in speed, but lz4 has more IO (less compression) than zip (faster to decompress than gzip, but more work (data size) to do than gzip, overall comparable). lz4 however is nicer for remastering (quicker).
Last edited by rufwoof on Mon 17 Oct 2016, 21:09, edited 2 times in total.
Yes, I was shocked by how quick the remaster went with the "Quick Remaster" script.rufwoof wrote:<snip>
lz4 and gzip were similar overall in speed, but lz4 has more IO (less compression) than zip (faster to decompress than gzip, but more work (data size) to do than gzip, overall comparable). lz4 however is nicer for remastering (quicker).
I don't really use sfs's now, I have everything extracted to the save file and a empty main filesystem sfs, so no need to remaster ...etc. (as that eliminates overlays, and enables booting either frugally (read only) or as though fully installed). Prior to that however I used a similar remaster as Fred's quick remaster (but single click only) ... which was fast enough IMO to be a replacement for saving (no need for a savefile/folder, just remaster a new main filesystem sfs with all of the changes incorporated).
As quick as it is, the bottleneck is disk. Remaster in ram or to a fast SSD and its even quicker
As quick as it is, the bottleneck is disk. Remaster in ram or to a fast SSD and its even quicker
Hi ruf!
Could you please elaborate further on it ? ...
Thanks
What`s the purpose/advantage of this method and how to accomplish it (Details) .I don't really use sfs's now, I have everything extracted to the save file and a empty main filesystem sfs, so no need to remaster ...etc. (as that eliminates overlays, and enables booting either frugally (read only) or as though fully installed)
Could you please elaborate further on it ? ...
Thanks
With live boot 3 you can create a partition with a label of 'persistence' and use that as the save 'folder'. That can also contain grub4dos bootloader (grldr and menu.lst) and the /live folder within which 01-filesystem.squashfs resides. When all of 01-filesystem.squashfs is extracted to that / root partition, then everything is in effect in the "savefolder", such that the 01-filesystem.squashfs can be empty. With everything extracted to the / folder it also means you can boot it like a full install. My menu.lst looks like :
i.e. by default boots frugal/read only (but with a save2flash type script that can flush memory recorded changes to disk), or it can be booted like a full install ... handy for installing the likes of kernel updates and (in time) later versions of Debian stable as and when they come online (that might otherwise not be installed using a frugal type boot due to insufficient memory space being available to record all of the changes).
Whilst 01-filesystem.squashfs is empty, leaving it present means you can still load other sfs's if you so desire (just drop them into /live folder so they're loaded at bootup).
Slower to boot, but once a program has been run once then typically it remains memory resident so subsequent runs are quick. Easy to backup, I just boot frugally and make a mksquashfs of /mnt/sda1 on another partition. No need to pin apps or the kernel i.e. accepts all updates such as to wget rather than running with older (weaker security) versions. The equivalent of a full Debian stable version, where security updates come through in a timely manner and the set of programs available in the repository work well.
I originally allocated 16GB to that partition, but typically it uses less than 5GB in total.
A nice feature is that /lib/live/mount/persistence/sda1 is the path to the persistent layer, so for instance in my home folder I created a sym link called documents-persistent to /lib/live/mount/persistence/sda1/documents-persistent, so that any document changed in that folder are preserved across reboots even if no save is run during a frugal booted (read only) session. Similar for Osmo (so all calendar/task changes are preserved). 99.9% of time I'll boot frugal. Full boot is only when a attempted update during a frugal booted session indicates that it was unable to apply the updates (kernel or whatever), in which case reboot without saving ... into full boot mode and re-run the updates, before rebooting back into frugal mode again.
For the full boot, menu.lst chains to Debian installed boot menu.
Works well for me, and just requires a single additional script to make it save changes (extended version of save2flash that I called flush2disk)
Code: Select all
# menu.lst
color white/blue black/cyan white/black cyan/black
timeout 2
default 1
title Debian FULL Install RW filesys (/boot/grub/menu.lst)
find --set-root /debian-usb
configfile /boot/grub/menu.lst
commandline
title Debian Jessie Frugal RO only saves if run flush2disk
find --set-root /live/01-filesystem.squashfs
kernel /vmlinuz boot=live timezone=Europe/London xorg-resolution=1280x768 config nofastboot persistence persistence-read-only persistence-label=persistence quickreboot noprompt showmounts live-media-path=/live/ config rw
initrd /initrd.img
Whilst 01-filesystem.squashfs is empty, leaving it present means you can still load other sfs's if you so desire (just drop them into /live folder so they're loaded at bootup).
Slower to boot, but once a program has been run once then typically it remains memory resident so subsequent runs are quick. Easy to backup, I just boot frugally and make a mksquashfs of /mnt/sda1 on another partition. No need to pin apps or the kernel i.e. accepts all updates such as to wget rather than running with older (weaker security) versions. The equivalent of a full Debian stable version, where security updates come through in a timely manner and the set of programs available in the repository work well.
I originally allocated 16GB to that partition, but typically it uses less than 5GB in total.
A nice feature is that /lib/live/mount/persistence/sda1 is the path to the persistent layer, so for instance in my home folder I created a sym link called documents-persistent to /lib/live/mount/persistence/sda1/documents-persistent, so that any document changed in that folder are preserved across reboots even if no save is run during a frugal booted (read only) session. Similar for Osmo (so all calendar/task changes are preserved). 99.9% of time I'll boot frugal. Full boot is only when a attempted update during a frugal booted session indicates that it was unable to apply the updates (kernel or whatever), in which case reboot without saving ... into full boot mode and re-run the updates, before rebooting back into frugal mode again.
For the full boot, menu.lst chains to Debian installed boot menu.
Works well for me, and just requires a single additional script to make it save changes (extended version of save2flash that I called flush2disk)
- Attachments
-
- flush2disk.gz
- fake .gz (remove)
- (9.86 KiB) Downloaded 316 times
@rufwoof, thanks for testing!
Another alternative for wireless-manager could be wifibox
William and I worked on that in the Xenialdog thread some time ago, it uses busybox's udhcp, so it's very light.
http://debiandog.github.io/Jessie/i386/ ... 4_i386.deb
@dancytron
Should be OK now, included choice for backup of save storage, install new version 1.0.2a:
Or from synaptic, or install this deb package:
http://debiandog.github.io/Jessie/i386/ ... 2a_all.deb
To get back again to older version:
Testing most appreciated!
Fred
Yes, it hangs a little just before login, maybe that's caused by dhcpcd, not frisbee itself.Frisbee was a clear bottleneck
Another alternative for wireless-manager could be wifibox
Code: Select all
apt-get install wifibox
http://debiandog.github.io/Jessie/i386/ ... 4_i386.deb
@dancytron
Me too, it's hard to believe that it works well, with the speed of lightYes, I was shocked by how quick the remaster went with the "Quick Remaster" script.
I had looked into that before but did seem too complicated (e.g. to cover all cases, savefile, savefolder, possibly be on different partition than boot-partition)The only thing I can see that I would change would be to also rename the save folder/file rather than give you a choice to delete it. That would make stepping back if there is a problem bullet proof.
Should be OK now, included choice for backup of save storage, install new version 1.0.2a:
Code: Select all
apt-get update
apt-get install quick-remaster
http://debiandog.github.io/Jessie/i386/ ... 2a_all.deb
To get back again to older version:
Code: Select all
apt-get install quick-remaster=1.0.1
Fred
Hi rufwoof !
Thanks for your reply and your patience .
This seems to be another sophisticated method to run
frugal or frugal(full) with save on demand only .
Since I am quite happy using Porteus boot method with save on demand , so it seems to me not much advantage going over (although there are some quite interesting aspects in it) using Deb Dog this way.
Maybe someone else will.
There is just one thing which is confusing me in your description above ( maybe could confuse some other amateur too) .....how to " empty" this 01-filesystem.squashfs ?
or am i asking a wrong question .....makes me somehow curious...did i misunderstood this ?
But not so urgent.
Maybe in some quiet hour i will go experimenting with it ,it`s not a question of live or death for me......maybe for someone else it is .
Thanks ruf !
Thanks for your reply and your patience .
This seems to be another sophisticated method to run
frugal or frugal(full) with save on demand only .
Since I am quite happy using Porteus boot method with save on demand , so it seems to me not much advantage going over (although there are some quite interesting aspects in it) using Deb Dog this way.
Maybe someone else will.
There is just one thing which is confusing me in your description above ( maybe could confuse some other amateur too) .....how to " empty" this 01-filesystem.squashfs ?
Also... can everything the "savefolder" and the live folder be on the same partition labeled persistence ?When all of 01-filesystem.squashfs is extracted to that / root partition, then everything is in effect in the "savefolder", such that the 01-filesystem.squashfs can be empty. With everything extracted to the / folder it also means you can boot it like a full install.
or am i asking a wrong question .....makes me somehow curious...did i misunderstood this ?
But not so urgent.
Maybe in some quiet hour i will go experimenting with it ,it`s not a question of live or death for me......maybe for someone else it is .
Thanks ruf !
Hi backi,
In case you or anyone like one day to bring rufwoof's idea in practice, here's a howto for DebianDog (but can in fact be used with any Debian Live, (with some small changes)):
http://murga-linux.com/puppy/viewtopic. ... 964#928964
It's very similar to what I posted earlier for DebianDog64:
http://murga-linux.com/puppy/viewtopic. ... 339#916339
See it as sort of a mix between frugal and full install, the good thing is that way it's 100% pure Debian (Live) (as with porteus-boot it's not, of course), and there's the ability to upgrade the kernel (not on DebianDog normal frugal install, the kernel is pinned).
The RO menu.lst entry is similar to porteus-boot "EXIT" (but you can save on demand, using flush2disk).
Fred
In case you or anyone like one day to bring rufwoof's idea in practice, here's a howto for DebianDog (but can in fact be used with any Debian Live, (with some small changes)):
http://murga-linux.com/puppy/viewtopic. ... 964#928964
It's very similar to what I posted earlier for DebianDog64:
http://murga-linux.com/puppy/viewtopic. ... 339#916339
See it as sort of a mix between frugal and full install, the good thing is that way it's 100% pure Debian (Live) (as with porteus-boot it's not, of course), and there's the ability to upgrade the kernel (not on DebianDog normal frugal install, the kernel is pinned).
The RO menu.lst entry is similar to porteus-boot "EXIT" (but you can save on demand, using flush2disk).
Fred
backi wrote:Just another Question .
In puppy ,to mount an Iso file with Rox-Filer, just click and it will be mounted .
In Deb-Dog Rox-Filer won`t do it... also Thunar does not mount Isos........is there a way to make this work ?
Backi,
I just checked mine, and I agree with Fred. I tried 4 different ISOs I have on a data partition, and with one 'click' Thunar mounted them & for each opened up a Thunar to show you what was inside 'em. Then, to unmount, just 'click' them again, and they are unmounted.
I'm telling ya, Backi, I swear you gotta lay off the weed & alcohol a little bit, or you're gonna fry those remaining brain cells of yours....hahahahahah (just joking ya).
hahahahahah (just joking ya).
hahaha ..i hope so ....hahaha
hahaha ..i hope so ....hahaha
I am going to check it .I just checked mine, and I agree with Fred. I tried 4 different ISOs I have on a data partition, and with one 'click' Thunar mounted them & for each opened up a Thunar to show you what was inside 'em. Then, to unmount, just 'click' them again, and they are unmounted.
Last edited by backi on Wed 19 Oct 2016, 17:17, edited 1 time in total.
I'm running pure Debian Jessie (installed from Debian live cd), and neither pcmanfm nor thunar load a ISO directly.
Open a su terminal in the folder and
mkdir t
mount *.iso t
will mount it
umount t
when done to unmount it (assuming just the one iso otherwise change *.iso to a more single iso identifiable name).
There's likely a way to enter a command sequence into pcmanfm and/or thunar to automate something like that as per DebianDog likely does ???
Open a su terminal in the folder and
mkdir t
mount *.iso t
will mount it
umount t
when done to unmount it (assuming just the one iso otherwise change *.iso to a more single iso identifiable name).
There's likely a way to enter a command sequence into pcmanfm and/or thunar to automate something like that as per DebianDog likely does ???