Quirky April 7.0 - 7.0.3, 7.0.4, 7.0.4.1
Conceptual thing :
Booting frugally (grub4dos) and init set to create zram space using 99% of available remaining free memory (a little free is needed to be left as conventional memory to keep things working (cp ...etc)). Init then copies the contents of q.sfs (puppy) into zram and switches root to that zram image, after deleting q.sfs (having been copied to zram).
That leaves fragmentation. If q.sfs is around 500MB then there's 500MB of free space in devtmpfs (conventional memory) and the rest as zram.
To reduce fragmentation what I did was moved all of /usr and /lib (being big directories) out of zram to /dev (devtmpfs), which left devtmpfs nigh on filled up and zram nigh on empty - so in effect running the working session in zram. i.e. I sym linked /usr and /lib to the /dev/usr and /dev/lib moved folders.
That test somewhat worked, but left a system far from fully functional (but still working to a degree), i.e. it was a very quick-and-dirty crude test of viability. On my 1.5GB system the indications are that 1.3GB of 'free memory' would have been available. On other pup's I typically have around 750MB free on the same PC, so that 1.3GB free seems to tie in with how zram assumes a average 1:2 compression rate. Assuming that broadly holds true for general usage then with a better choice of what actually got moved out of zram to /devtmpfs and after booting Quirky could be running with free memory close to actual total ram/memory.
Obviously what was moved would have to be selected carefully and ideally be stuff that was fixed/read only/little changed - especially if /devtmpfs was being filled to near full capacity - and that could support being sym links rather than actual files/folders.
Booting frugally (grub4dos) and init set to create zram space using 99% of available remaining free memory (a little free is needed to be left as conventional memory to keep things working (cp ...etc)). Init then copies the contents of q.sfs (puppy) into zram and switches root to that zram image, after deleting q.sfs (having been copied to zram).
That leaves fragmentation. If q.sfs is around 500MB then there's 500MB of free space in devtmpfs (conventional memory) and the rest as zram.
To reduce fragmentation what I did was moved all of /usr and /lib (being big directories) out of zram to /dev (devtmpfs), which left devtmpfs nigh on filled up and zram nigh on empty - so in effect running the working session in zram. i.e. I sym linked /usr and /lib to the /dev/usr and /dev/lib moved folders.
That test somewhat worked, but left a system far from fully functional (but still working to a degree), i.e. it was a very quick-and-dirty crude test of viability. On my 1.5GB system the indications are that 1.3GB of 'free memory' would have been available. On other pup's I typically have around 750MB free on the same PC, so that 1.3GB free seems to tie in with how zram assumes a average 1:2 compression rate. Assuming that broadly holds true for general usage then with a better choice of what actually got moved out of zram to /devtmpfs and after booting Quirky could be running with free memory close to actual total ram/memory.
Obviously what was moved would have to be selected carefully and ideally be stuff that was fixed/read only/little changed - especially if /devtmpfs was being filled to near full capacity - and that could support being sym links rather than actual files/folders.
- Attachments
-
- shiftedfromzramtodevtmpfs.jpg
- (25.94 KiB) Downloaded 883 times
Quirky April 7.0 final
I installed to the hard drive on my emachines D620 laptop:
video-info-glx 1.5.3 Fri 27 Feb 2015 on Quirky April64 7.0 Linux 3.17.4 x86_64
5.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]
oem: ATI ATOMBIOS
product: RS690 01.00
X Server: Xorg Driver: radeon
X.Org version: 1.16.2
dimensions: 1280x800 pixels (338x211 millimeters)
depth of root window: 24 planes
AMD Athlon(tm) Processor 2650e
Core 0: @1596 MHz
After it had installed and before booting for the first time I copied
the contents of the audit directory on my desktop install to the audit
directory of the new laptop install.
When it booted for the first time on the laptop I ran the recover
snapshot, the hard drive light flashed for close to an hour before I lost
patience and rebooted.
Much to my surprise it booted to the desktop showing the 3840x1080
(squished) wallpaper from my desktop install
I needed to compile the mplayer snapshot over again because it would
crash with an error about being compiled on a different cpu, after
compiling again smplayer is working fine.
April64-7.0 seems to be very forgiving
EDIT: There is an error when booting but it doesn't seem to matter, the
desktop installation was on an SDHC card formatted F2FS,the laptop hard
drive is ext4.
I tried doing another snapshot on the laptop but the snapshot utility wouldn't start.
I also added Links-2.9 web browser for reading news while streaming
music with umplayer, it's working well.
Dillo-3.0.4.1 will compile but the fonts look terrible for some reason.
video-info-glx 1.5.3 Fri 27 Feb 2015 on Quirky April64 7.0 Linux 3.17.4 x86_64
5.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]
oem: ATI ATOMBIOS
product: RS690 01.00
X Server: Xorg Driver: radeon
X.Org version: 1.16.2
dimensions: 1280x800 pixels (338x211 millimeters)
depth of root window: 24 planes
AMD Athlon(tm) Processor 2650e
Core 0: @1596 MHz
After it had installed and before booting for the first time I copied
the contents of the audit directory on my desktop install to the audit
directory of the new laptop install.
When it booted for the first time on the laptop I ran the recover
snapshot, the hard drive light flashed for close to an hour before I lost
patience and rebooted.
Much to my surprise it booted to the desktop showing the 3840x1080
(squished) wallpaper from my desktop install
I needed to compile the mplayer snapshot over again because it would
crash with an error about being compiled on a different cpu, after
compiling again smplayer is working fine.
April64-7.0 seems to be very forgiving
EDIT: There is an error when booting but it doesn't seem to matter, the
desktop installation was on an SDHC card formatted F2FS,the laptop hard
drive is ext4.
I tried doing another snapshot on the laptop but the snapshot utility wouldn't start.
I also added Links-2.9 web browser for reading news while streaming
music with umplayer, it's working well.
Dillo-3.0.4.1 will compile but the fonts look terrible for some reason.
- Attachments
-
- links.jpg
- (77.93 KiB) Downloaded 744 times
-
- capture6565.jpg
- (81.56 KiB) Downloaded 850 times
Last edited by Billtoo on Sat 28 Feb 2015, 02:46, edited 1 time in total.
@BarryK, the work by @L18L is one of interest, bringing a OOTB localization for all user starts consistent with what FirstRUN already does. This advances PUP's worldwide appeal in an excellent yet subtle way.
Have you a FirstRUN PET for testing which would include it? Willing to test if you have one.
As subtle as FirstRUN is, it is extremely valuable in what it does in a single screen?
Have you a FirstRUN PET for testing which would include it? Willing to test if you have one.
As subtle as FirstRUN is, it is extremely valuable in what it does in a single screen?
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: installquirky
Thanks for that, fixed it.L18L wrote:Testing my translation I foundAll sizes in Giga were zero.Code: Select all
# installquirky /usr/sbin/installquirky: line 75: printf: 28.5196: invalid number /usr/sbin/installquirky: line 75: printf: 63.3428: invalid number /usr/sbin/installquirky: line 75: printf: 489.284: invalid number
fix: insert LANG=CMight also occur at other lines.Code: Select all
ONESIZE="`LANG=C printf "%.1f" $ONESIZE`G"
good old COBOL wrote:DECIMAL POINT IS COMMA
EDITsame thingCode: Select all
/usr/sbin/.childproof: line 41: printf: 14.2598: invalid number
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Quirky April 7.0 final
I have got your multilingual solution on my to-do list.L18L wrote:... and my multilingual solution for FIRSTRUN from wary64 works OOTB here in Quirky7.
Short explanation:
All available quicksetup.mo files are included.
User's very first choice is language.
This language is used in quicksetup.
Hope this will make it into ServicePack1.
Service Pack 1 though, will be strictly bug fixes.
Have already fixed two things, your LANG=C prefixes, plus missing pppoe executables, that will be in the SP1.
[url]https://bkhome.org/news/[/url]
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
firstrun
No, no FirstRUN PET.gcmartin wrote:Have you a FirstRUN PET for testing which would include it? Willing to test if you have one.
It is launch_app_in_another_LANGUAGE-1.01.pet, see:
http://www.murga-linux.com/puppy/viewto ... &start=104.
Without some knowledge of Puppy internals you won't.
Thanks for your goodwill.
Anyhow, here is how I have been tested it:
Installed april7 into a partition
Do NOT run it!
cp launch_app_in_another_LANGUAGE-1.01.pet launch.tgz
extract launch.tgz and copy usr/ to april7
(Change one line in usr/sbin/delayedrun. This change is included in pinstall script, but I have done it manually:)
edit usr/sbin/delayedrun and change line 151 from
Code: Select all
QUICKSETUP="quicksetup"
Code: Select all
#QUICKSETUP="quicksetup"
QUICKSETUP="launch_app_in_another_LANGUAGE quicksetup"
Re: Quirky 7
BarryK wrote:Yes, a bug!rameshiyer wrote:Dear Barry Sir
While trying to setup through commandline, I am getting following message:-
# pppoe-setup
Welcome to the Roaring Penguin PPPoE client setup. First, I will run
some checks on your system to make sure the PPPoE client is installed
properly...
Oh, dear, I can't execute the program '/usr/sbin/pppoe'. Please
re-install the rp-pppoe client
Executables are missing. I will get this fixed for the Service Pack, but for now, I have attached a pppoe executable.
gunzip it, set it's execute flags, place in /usr/sbin.
Let us know if that is enough to get PPPoE working.
Oh yes, the executable is for April64, 64-bit.
Dear Barry Sir
Thank you very much. Now the problem solved. In 32bit also same bug. Please provide 32bit file..
Looking forward service pack, Thanks once again.
Quirky April 7.0 final
I moved my Quirky April64-7.0 32gb flash drive install from my gateway
desktop which has nvidia graphics to my hp desktop which has intel graphics:
# report-video
VIDEO REPORT: Quirky April64, version 7.0
Chip description:
VGA compatible controller: Intel Corporation Device 0152 (rev 09)
Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 1920x1080
Depth (bits, or planes): 24
Modules requested to be loaded: dbe
Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): intel
Loaded modules: dbe dri2 extmod glx kbd mouse present
Actual rendering on monitor:
Resolution: 1920x1080 pixels (508x285 millimeters)
Depth: 24 planes
...the above also recorded in /tmp/report-video
#
I was mistaken, the latest fltk is in the repo (I don't think it was
before) so Dillo-3.0.4.1 compiled and the fonts look nice.
I did another snapshot.
EDIT: On my laptop install I added the broadcom firmware
from Fatdog64-700 to lib/firmware and the Network controller:
Broadcom Corporation BCM4312 802.11b/g (rev 01)
on my emachines D620 laptop is working.
desktop which has nvidia graphics to my hp desktop which has intel graphics:
# report-video
VIDEO REPORT: Quirky April64, version 7.0
Chip description:
VGA compatible controller: Intel Corporation Device 0152 (rev 09)
Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 1920x1080
Depth (bits, or planes): 24
Modules requested to be loaded: dbe
Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): intel
Loaded modules: dbe dri2 extmod glx kbd mouse present
Actual rendering on monitor:
Resolution: 1920x1080 pixels (508x285 millimeters)
Depth: 24 planes
...the above also recorded in /tmp/report-video
#
I was mistaken, the latest fltk is in the repo (I don't think it was
before) so Dillo-3.0.4.1 compiled and the fonts look nice.
I did another snapshot.
EDIT: On my laptop install I added the broadcom firmware
from Fatdog64-700 to lib/firmware and the Network controller:
Broadcom Corporation BCM4312 802.11b/g (rev 01)
on my emachines D620 laptop is working.
- Attachments
-
- screenshot.jpg
- (78.01 KiB) Downloaded 749 times
-
- screenshot2.jpg
- (173.53 KiB) Downloaded 751 times
Last edited by Billtoo on Sat 28 Feb 2015, 23:48, edited 2 times in total.
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
Re: Quirky April 7.0 final
Trying to help forum andBarryK wrote:Service Pack 1 though, will be strictly bug fixes.
Puppy Translators Team member Griot I have found sortof bug with keyboard layout.
quicksetup and Advanced Xorg keyboard configuration both provide
srp Serbian
which does not work.
I have been using console tool setxkbmap in different distros.
Here are the working commands:
In Fatdog use setxkbmap=rs
In Quirky7 April use setxkbmap=rs
In Puppy Precise 5.7.1 use setxkbmap=sr
Note, setxkbmap is taking immediately effect.
Thus you can play like this:
Code: Select all
# setxkbmap de
# setxkbmap rs
# љњерт
bash: $'\321\231\321\232\320\265\321\200\321\202': command not found
# setxkbmap sr
Error loading new keyboard description
# setxkbmap de
# setxkbmap srp
Error loading new keyboard description
# qwertzuiopü+
bash: $'qwertzuiop\303\274+': command not found
# setxkbmap rs
# љњертзуиопшђ
Not only play but also work with it if you are a console freak.
- Attachments
-
- serbian.png
- (32.55 KiB) Downloaded 703 times
Here's a 64 bit version of python I made in Wary64. It works in April64 as well.
http://murga-linux.com/puppy/viewtopic. ... 247#831247
___________________________________________________________
http://murga-linux.com/puppy/viewtopic. ... 247#831247
___________________________________________________________
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Someone reported a problem with flsynclient, april64.
Yes, it does seem to be broken.
I found source from fatdog64:
http://ftp.cc.uoc.gr/mirrors/linux/fatd ... p2.tar.bz2
...that has a precompiled binary in it.
...seems to work better, but no tapping on my touchpad.
Actually, I don't want tapping, I always turn it off.
But, it should be able to turn on, for those who want it.
Maybe the problem is something else in april64. haven't tried on the 32-bit april yet.
Anyone who is interested in this, grab that tarball from fatdog, open it, no need to compile, the binary is already there.
Note, in the puppy 32-bit days, we used to use a pet created by jemimah:
http://murga-linux.com/puppy/viewtopic.php?t=48011
...jemimah hacked on version 0.6. Unfortunately, her patch is no longer available. I don't seem to have it archived anywhere.
EDIT:
No, flsynclient in April 7.0 works.
I had a misunderstanding. In earlier quirkies and pups, tapping always defaulted to "on", which was always very annoying for me, as my touchpad is very sensitive and my thumb used to accidentally cause a touch.
So, I always had to run flsynclient to disable "tap on".
However, april 7.0, tap defaults to "off". I though it was broken, but it ain't.
Although flsynclient shows "on", the "Tapping" tab has to have a parameter, such as one-finger left-button, set to "enabled".
So, all is ok.
I wonder what the original bug report was about? Will have to find it.
Yes, it does seem to be broken.
I found source from fatdog64:
http://ftp.cc.uoc.gr/mirrors/linux/fatd ... p2.tar.bz2
...that has a precompiled binary in it.
...seems to work better, but no tapping on my touchpad.
Actually, I don't want tapping, I always turn it off.
But, it should be able to turn on, for those who want it.
Maybe the problem is something else in april64. haven't tried on the 32-bit april yet.
Anyone who is interested in this, grab that tarball from fatdog, open it, no need to compile, the binary is already there.
Note, in the puppy 32-bit days, we used to use a pet created by jemimah:
http://murga-linux.com/puppy/viewtopic.php?t=48011
...jemimah hacked on version 0.6. Unfortunately, her patch is no longer available. I don't seem to have it archived anywhere.
EDIT:
No, flsynclient in April 7.0 works.
I had a misunderstanding. In earlier quirkies and pups, tapping always defaulted to "on", which was always very annoying for me, as my touchpad is very sensitive and my thumb used to accidentally cause a touch.
So, I always had to run flsynclient to disable "tap on".
However, april 7.0, tap defaults to "off". I though it was broken, but it ain't.
Although flsynclient shows "on", the "Tapping" tab has to have a parameter, such as one-finger left-button, set to "enabled".
So, all is ok.
I wonder what the original bug report was about? Will have to find it.
Last edited by BarryK on Sun 01 Mar 2015, 09:26, edited 1 time in total.
[url]https://bkhome.org/news/[/url]
Hello Barry
So, with the aid of our good friend The Wayback Machine
i managed to find the file attached below.
Hope this helps
CatDude
.
On page 2 of that thread, jemimah posted a link to her patched sources.BarryK wrote:....Note, in the puppy 32-bit days, we used to use a pet created by jemimah:
http://murga-linux.com/puppy/viewtopic.php?t=48011
...jemimah hacked on version 0.6. Unfortunately, her patch is no longer available. I don't seem to have it archived anywhere.
So, with the aid of our good friend The Wayback Machine
i managed to find the file attached below.
Hope this helps
CatDude
.
- Attachments
-
- flSynclient-jemimah-patches.tar.gz
- (13.47 KiB) Downloaded 243 times
ZRAM Frugal
Downloaded the april64-70.iso (CD boot) and clicked to open that iso.
Extracted (dragged to copy) vmlinuz and initrd.q out of that iso to where I grub4dos boot i.e. in my case a folder under /mnt/sda3/quirky7
Added a entry for April to my menu.lst grub4dos boot file
title April (Quirky) 7 Final
kernel (hd0,2)/quirky7/vmlinuz rootwait rw
initrd (hd0,2)/quirky7/initrd
Extracted the content of initrd.q
mkdir MAIN
cd MAIN
cat ../initrd.q | cpio -id
Moved q.sfs up one directory (to where vmlinuz is stored)
mv q.sfs ../.
Rebuilt a initrd without the q.sfs contained within
find | cpio -o -H newc >../initrd
AFTER HAVING MADE CHANGES TO INIT
i.e. much the same as the original, but where q.sfs isn't inside the initrd file, but is read in from HDD (disk) when booting. That code is machine specific i.e. hard coded to my /mnt/sda3/quirky7 choice of HDD directory/folder - but easily changed to other choices.
Boots fine - typical frugal boot speeds (which tend to be slower than full install boots) and leaves around 800MB free space on my 1.5GB ram system. Also has nearly 800MB free space under /dev which could be used i.e. more free space than actual ram space in total !!! - Confused as to how 1.6GB of free space can be available on a PC with only 1.5GB! - Well its because its using zram compression which zram generally approximates to around a 2:1 compression rate for general usage. Neat eh!
So in summary, a small intird boots and creates a zram image using nearly all of remaining memory after that small initrd is loaded ... and the q.sfs (puppy) is copied (from disk) into zram (compressed memory space), before init switches root to that puppy.
In using a squashed file system to load into zram that sfs can be stored on any of the popular types of filesystem, ext, ntfs ...etc
Also as disk space is relatively inexpensive and often available, we can use a squashed file system that's not squashed, just stored - which provides several benefits, one of which is that they are quicker to form/create. As its being copied into zram (compressed) memory, being non compressed on disk doesn't matter assuming we have lots of available free disk space.
Booting frugally and loading into ram (zram) means that there's no save file and any changes are lost across reboots. To provide a persistence option we can remaster q.sfs from the live system. I've created a script to do that - together with a second script that simply calls the first one so that it can be run/viewed in a terminal window on the desktop
remaster2
remaster
I store those scripts in the same directory as vmlinuz, but dragged a copy of the remaster script to the desktop - so that starting the script is easier/to-hand.
To remaster (save) typically takes around 10 seconds. And of course it only saves whenever you choose to do so. You might boot the read only and experiment/trash things and opt to just reboot again. Or after rebooting you might tweak a few things and then opt to remaster so as to preserve those changes.
Another benefit of having q.sfs outside of initrd is that you can unsquashfs and mksquashfs the content directly i.e. extract q.sfs to a directory tree and edit any of the content of that as you see fit, before rebuilding the sfs again.
unsquashfs q.sfs
will create a squashfs-root directory tree of the content
mksquashfs squashfs-root q.sfs -noappend
rebuilds the q.sfs from that directory tree.
==============
Frugalling just got better thanks to Barry's April CD version
ZRAM means that q.sfs can be stored non compressed which means 'saving' is much quicker (but booting is a little slower).
With puppy (q.sfs) outside of initrd it means that we have much more space initially being allocated to zram. Such that even on a 1.5GB ram system such as my own there's still around 1.5GB of total free space after booting
Extracted (dragged to copy) vmlinuz and initrd.q out of that iso to where I grub4dos boot i.e. in my case a folder under /mnt/sda3/quirky7
Added a entry for April to my menu.lst grub4dos boot file
title April (Quirky) 7 Final
kernel (hd0,2)/quirky7/vmlinuz rootwait rw
initrd (hd0,2)/quirky7/initrd
Extracted the content of initrd.q
mkdir MAIN
cd MAIN
cat ../initrd.q | cpio -id
Moved q.sfs up one directory (to where vmlinuz is stored)
mv q.sfs ../.
Rebuilt a initrd without the q.sfs contained within
find | cpio -o -H newc >../initrd
AFTER HAVING MADE CHANGES TO INIT
Code: Select all
#!/bin/sh
#(c) Copyright Barry Kauler, 15 March 2014. Licence: GPL3 (/usr/share/doc/legal).
#simple mechanism to boot Quirky as live-CD, totally in RAM.
DRIVE=/dev/sda3
DIR=/quirky7
mount -t proc none /proc
mount -t sysfs none /sys
mount -t rootfs -o remount,rw rootfs /
ln -s /proc/mounts /etc/mtab
PATH="/bin:/sbin"
#create a zram, on /q_new...
echo "Creating a zram"
FREERAMK=`free | grep -o 'Mem: .*' | tr -s ' ' | cut -f 4 -d ' '`
HALFRAMB=$(($FREERAMK*1023)) # nearly all of free mem allocated to zram
HALFRAMM=$(($FREERAMK/1025))
echo "Creating a ${HALFRAMM}MB zram, with ext2 filesystem..."
echo "$HALFRAMB" > /sys/block/zram0/disksize
mkfs.ext2 -m 0 /dev/zram0
sync
mount -t ext2 /dev/zram0 /q_new
mkdir -p /mnt/D
mount $DRIVE /mnt/D
#copy q.sfs to zram...
echo "Copying 'q.sfs' Quirky files to zram..."
mount -t squashfs /mnt/D/$DIR/q.sfs /q_sfs #note: busybox 1.22.1 mount auto-detects need for loop.
cp -a /q_sfs/* /q_new/
sync
#150214 also all of initrd, for use by script 'savesession':
if [ ! -d /q_new/boot/initrd-tree ];then
mkdir -p /q_new/boot/initrd-tree
cp -a /bin /q_new/boot/initrd-tree/
cp -a /dev /q_new/boot/initrd-tree/
cp -a /etc /q_new/boot/initrd-tree/
cp -a /sbin /q_new/boot/initrd-tree/
cp -a /init /q_new/boot/initrd-tree/
mkdir /q_new/boot/initrd-tree/lib
mkdir /q_new/boot/initrd-tree/mnt
mkdir /q_new/boot/initrd-tree/proc
mkdir /q_new/boot/initrd-tree/q_new
mkdir /q_new/boot/initrd-tree/q_sfs
mkdir /q_new/boot/initrd-tree/sys
mkdir /q_new/boot/initrd-tree/tmp
mkdir /q_new/boot/initrd-tree/var
fi
[ ! -d /q_new/dev ] && mkdir /q_new/dev
[ ! -d /q_new/proc ] && mkdir /q_new/proc
[ ! -d /q_new/sys ] && mkdir /q_new/sys
[ ! -d /q_new/var ] && mkdir /q_new/var
[ ! -d /q_new/tmp ] && mkdir /q_new/tmp
[ ! -d /q_new/mnt ] && mkdir /q_new/mnt
sync
umount /q_sfs
umount /mnt/D
#rm -f q.sfs
#need to do this before switch_root...
mount -t devtmpfs devtmpfs /q_new/dev
sync
umount /sys
umount /proc
exec switch_root /q_new /sbin/init
###END###
Boots fine - typical frugal boot speeds (which tend to be slower than full install boots) and leaves around 800MB free space on my 1.5GB ram system. Also has nearly 800MB free space under /dev which could be used i.e. more free space than actual ram space in total !!! - Confused as to how 1.6GB of free space can be available on a PC with only 1.5GB! - Well its because its using zram compression which zram generally approximates to around a 2:1 compression rate for general usage. Neat eh!
So in summary, a small intird boots and creates a zram image using nearly all of remaining memory after that small initrd is loaded ... and the q.sfs (puppy) is copied (from disk) into zram (compressed memory space), before init switches root to that puppy.
In using a squashed file system to load into zram that sfs can be stored on any of the popular types of filesystem, ext, ntfs ...etc
Also as disk space is relatively inexpensive and often available, we can use a squashed file system that's not squashed, just stored - which provides several benefits, one of which is that they are quicker to form/create. As its being copied into zram (compressed) memory, being non compressed on disk doesn't matter assuming we have lots of available free disk space.
Booting frugally and loading into ram (zram) means that there's no save file and any changes are lost across reboots. To provide a persistence option we can remaster q.sfs from the live system. I've created a script to do that - together with a second script that simply calls the first one so that it can be run/viewed in a terminal window on the desktop
remaster2
Code: Select all
#!/bin/bash
if [ -f /mnt/sda3/quirky7/q.sfs ]; then
rm /mnt/sda3/quirky7/q.sfs
fi
mksquashfs / /mnt/sda3/quirky7/q.sfs -noX -noD -noI -noF -e /tmp /mnt /proc /sys /root/.XLOADED /.fsckme.flg
Code: Select all
#!/bin/bash
cd /mnt/sda3/quirky7
urxvt -geometry 80x5+16+16 -bg white -fg blue -title "$(gettext 'Remastering initrd.q')" -e ./remaster2
To remaster (save) typically takes around 10 seconds. And of course it only saves whenever you choose to do so. You might boot the read only and experiment/trash things and opt to just reboot again. Or after rebooting you might tweak a few things and then opt to remaster so as to preserve those changes.
Another benefit of having q.sfs outside of initrd is that you can unsquashfs and mksquashfs the content directly i.e. extract q.sfs to a directory tree and edit any of the content of that as you see fit, before rebuilding the sfs again.
unsquashfs q.sfs
will create a squashfs-root directory tree of the content
mksquashfs squashfs-root q.sfs -noappend
rebuilds the q.sfs from that directory tree.
==============
Frugalling just got better thanks to Barry's April CD version
ZRAM means that q.sfs can be stored non compressed which means 'saving' is much quicker (but booting is a little slower).
With puppy (q.sfs) outside of initrd it means that we have much more space initially being allocated to zram. Such that even on a 1.5GB ram system such as my own there's still around 1.5GB of total free space after booting
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Quirky April 7.0 final
Yes, I didn't put fltk into the devx.Billtoo wrote: I was mistaken, the latest fltk is in the repo (I don't think it was
before) so Dillo-3.0.4.1 compiled and the fonts look nice.
I did another snapshot.
EDIT: On my laptop install I added the broadcom firmware
from Fatdog64-700 to lib/firmware and the Network controller:
Broadcom Corporation BCM4312 802.11b/g (rev 01)
on my emachines D620 laptop is working.
Well good idea to have it in the devx pet, so have now done that.
It is static libs only.
7.0 final has lots of extra network formware, but I seem to have missed the extra broadcom firmware -- I will bootup fatdog64 and see what I have missed.
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Thanks for that, I have now archived it into one of my source repos.CatDude wrote:Hello Barry
On page 2 of that thread, jemimah posted a link to her patched sources.BarryK wrote:....Note, in the puppy 32-bit days, we used to use a pet created by jemimah:
http://murga-linux.com/puppy/viewtopic.php?t=48011
...jemimah hacked on version 0.6. Unfortunately, her patch is no longer available. I don't seem to have it archived anywhere.
So, with the aid of our good friend The Wayback Machine
i managed to find the file attached below.
Hope this helps
CatDude
.
Good to have it, though don't seem to be needing it now, see edit in my earlier post.
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: ZRAM Frugal
Yes, I had it in the back of my mind, that for a frugal install, there are various optimizations, such as what you have done, extracting q.sfs.rufwoof wrote:Downloaded the april64-70.iso (CD boot) and clicked to open that iso.
Extracted (dragged to copy) vmlinuz and initrd.q out of that iso to where I grub4dos boot i.e. in my case a folder under /mnt/sda3/quirky7
Added a entry for April to my menu.lst grub4dos boot file
title April (Quirky) 7 Final
kernel (hd0,2)/quirky7/vmlinuz rootwait rw
initrd (hd0,2)/quirky7/initrd
Extracted the content of initrd.q
mkdir MAIN
cd MAIN
cat ../initrd.q | cpio -id
Moved q.sfs up one directory (to where vmlinuz is stored)
mv q.sfs ../.
Rebuilt a initrd without the q.sfs contained within
find | cpio -o -H newc >../initrd
AFTER HAVING MADE CHANGES TO INITi.e. much the same as the original, but where q.sfs isn't inside the initrd file, but is read in from HDD (disk) when booting. That code is machine specific i.e. hard coded to my /mnt/sda3/quirky7 choice of HDD directory/folder - but easily changed to other choices.Code: Select all
#!/bin/sh #(c) Copyright Barry Kauler, 15 March 2014. Licence: GPL3 (/usr/share/doc/legal). #simple mechanism to boot Quirky as live-CD, totally in RAM. DRIVE=/dev/sda3 DIR=/quirky7 mount -t proc none /proc mount -t sysfs none /sys mount -t rootfs -o remount,rw rootfs / ln -s /proc/mounts /etc/mtab PATH="/bin:/sbin" #create a zram, on /q_new... echo "Creating a zram" FREERAMK=`free | grep -o 'Mem: .*' | tr -s ' ' | cut -f 4 -d ' '` HALFRAMB=$(($FREERAMK*1023)) # nearly all of free mem allocated to zram HALFRAMM=$(($FREERAMK/1025)) echo "Creating a ${HALFRAMM}MB zram, with ext2 filesystem..." echo "$HALFRAMB" > /sys/block/zram0/disksize mkfs.ext2 -m 0 /dev/zram0 sync mount -t ext2 /dev/zram0 /q_new mkdir -p /mnt/D mount $DRIVE /mnt/D #copy q.sfs to zram... echo "Copying 'q.sfs' Quirky files to zram..." mount -t squashfs /mnt/D/$DIR/q.sfs /q_sfs #note: busybox 1.22.1 mount auto-detects need for loop. cp -a /q_sfs/* /q_new/ sync #150214 also all of initrd, for use by script 'savesession': if [ ! -d /q_new/boot/initrd-tree ];then mkdir -p /q_new/boot/initrd-tree cp -a /bin /q_new/boot/initrd-tree/ cp -a /dev /q_new/boot/initrd-tree/ cp -a /etc /q_new/boot/initrd-tree/ cp -a /sbin /q_new/boot/initrd-tree/ cp -a /init /q_new/boot/initrd-tree/ mkdir /q_new/boot/initrd-tree/lib mkdir /q_new/boot/initrd-tree/mnt mkdir /q_new/boot/initrd-tree/proc mkdir /q_new/boot/initrd-tree/q_new mkdir /q_new/boot/initrd-tree/q_sfs mkdir /q_new/boot/initrd-tree/sys mkdir /q_new/boot/initrd-tree/tmp mkdir /q_new/boot/initrd-tree/var fi [ ! -d /q_new/dev ] && mkdir /q_new/dev [ ! -d /q_new/proc ] && mkdir /q_new/proc [ ! -d /q_new/sys ] && mkdir /q_new/sys [ ! -d /q_new/var ] && mkdir /q_new/var [ ! -d /q_new/tmp ] && mkdir /q_new/tmp [ ! -d /q_new/mnt ] && mkdir /q_new/mnt sync umount /q_sfs umount /mnt/D #rm -f q.sfs #need to do this before switch_root... mount -t devtmpfs devtmpfs /q_new/dev sync umount /sys umount /proc exec switch_root /q_new /sbin/init ###END###
Boots fine - typical frugal boot speeds (which tend to be slower than full install boots) and leaves around 800MB free space on my 1.5GB ram system. Also has nearly 800MB free space under /dev which could be used i.e. more free space than actual ram space in total !!! - Confused as to how 1.6GB of free space can be available on a PC with only 1.5GB! - Well its because its using zram compression which zram generally approximates to around a 2:1 compression rate for general usage. Neat eh!
So in summary, a small intird boots and creates a zram image using nearly all of remaining memory after that small initrd is loaded ... and the q.sfs (puppy) is copied (from disk) into zram (compressed memory space), before init switches root to that puppy.
In using a squashed file system to load into zram that sfs can be stored on any of the popular types of filesystem, ext, ntfs ...etc
Also as disk space is relatively inexpensive and often available, we can use a squashed file system that's not squashed, just stored - which provides several benefits, one of which is that they are quicker to form/create. As its being copied into zram (compressed) memory, being non compressed on disk doesn't matter assuming we have lots of available free disk space.
Booting frugally and loading into ram (zram) means that there's no save file and any changes are lost across reboots. To provide a persistence option we can remaster q.sfs from the live system. I've created a script to do that - together with a second script that simply calls the first one so that it can be run/viewed in a terminal window on the desktop
remaster2remasterCode: Select all
#!/bin/bash if [ -f /mnt/sda3/quirky7/q.sfs ]; then rm /mnt/sda3/quirky7/q.sfs fi mksquashfs / /mnt/sda3/quirky7/q.sfs -noX -noD -noI -noF -e /tmp /mnt /proc /sys /root/.XLOADED /.fsckme.flg
I store those scripts in the same directory as vmlinuz, but dragged a copy of the remaster script to the desktop - so that starting the script is easier/to-hand.Code: Select all
#!/bin/bash cd /mnt/sda3/quirky7 urxvt -geometry 80x5+16+16 -bg white -fg blue -title "$(gettext 'Remastering initrd.q')" -e ./remaster2
To remaster (save) typically takes around 10 seconds. And of course it only saves whenever you choose to do so. You might boot the read only and experiment/trash things and opt to just reboot again. Or after rebooting you might tweak a few things and then opt to remaster so as to preserve those changes.
Another benefit of having q.sfs outside of initrd is that you can unsquashfs and mksquashfs the content directly i.e. extract q.sfs to a directory tree and edit any of the content of that as you see fit, before rebuilding the sfs again.
unsquashfs q.sfs
will create a squashfs-root directory tree of the content
mksquashfs squashfs-root q.sfs -noappend
rebuilds the q.sfs from that directory tree.
==============
Frugalling just got better thanks to Barry's April CD version
ZRAM means that q.sfs can be stored non compressed which means 'saving' is much quicker (but booting is a little slower).
With puppy (q.sfs) outside of initrd it means that we have much more space initially being allocated to zram. Such that even on a 1.5GB ram system such as my own there's still around 1.5GB of total free space after booting
Yes, it does look good, and I will certainly consider improvements for frugal, a little bit "down the track" though, as for now just thinking about important bug fixes for SP1.
Thanks for investigating and testing these enhancements!
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Quirky April 7.0 final
I don't understand.L18L wrote:Trying to help forum andBarryK wrote:Service Pack 1 though, will be strictly bug fixes.
Puppy Translators Team member Griot I have found sortof bug with keyboard layout.
quicksetup and Advanced Xorg keyboard configuration both provide
srp Serbian
which does not work.
I have been using console tool setxkbmap in different distros.
Here are the working commands:
In Fatdog use setxkbmap=rs
In Quirky7 April use setxkbmap=rs
In Puppy Precise 5.7.1 use setxkbmap=sr
Note, setxkbmap is taking immediately effect.
Thus you can play like this:
EDITCode: Select all
# setxkbmap de # setxkbmap rs # љњерт bash: $'\321\231\321\232\320\265\321\200\321\202': command not found # setxkbmap sr Error loading new keyboard description # setxkbmap de # setxkbmap srp Error loading new keyboard description # qwertzuiopü+ bash: $'qwertzuiop\303\274+': command not found # setxkbmap rs # љњертзуиопшђ
Not only play but also work with it if you are a console freak.
"setxkbmap rs" does not work in April 7.0, as there is no "rs.gz" in /lib/keymaps.
QuickSetup does not offer any Serbian keyboard setting.
EDIT:
Sorry, /lib/keymaps are console keymaps.
Xorg keymaps are here:
/etc/X11/xkb/symbols/pc
...and that folder contains file "srp".
Yep, this works:
# setxkbmap srp
So, what is the problem?
Well, I guess one problem is it is not offered in QuickSetup, nor in the Xorg Keyboard Wizard.
That's because there is no matching console keymap.
So, it would seem that we have to find a "srp.gz" console keymap.
[url]https://bkhome.org/news/[/url]