Quirky Xerus 8.6 (Aug. 16), Beaver 8.7.1 (Sept. 21), 2018

[belham2]

...almost forgot "2':

Mike Walsh's excellent Slimjet-sfs packages work awesome in Quirky. I downloaded his 'Slimjet-Version-15.0.0.0 (based on Chromium 59.0.3071.86_64)', quickly converted it to a pet, and it installed easily & is now running good in Quirky 8.1.94. Slimjet provides a nice counterpoint to the installed Seamonkey 2.48---especially when I want to get at my Netflix stuff

Hold on, I'm missing something here.

How did you do this: "quickly converted it to a pet"

(hmmmm, my sub 800x600, only 244kb pics are not being posted by the murga-board....give me a sec to figure out what's going on....ah, ok, figured it out...here the two pics are)

[BarryK]

- in xerrs.log
ls: cannot access '/root/.pup_event': No such file or directory

This error message doesn't matter, but I have fixed so that it doesn't appear.

Thanks for the feedback.

[recobayu]

Updated packages:
JWMDesk 2.3
http://barryk.org/news/?viewDetailed=00604

I think jwm must be update to 2.3.6.
It has aerosnap, and we can make it looks like i3wm by setting height=1
But the theme configuration is different with vgit version.
We can control the movement window by shortcut. It is stickyjwm here:
http://murga-linux.com/puppy/viewtopic. ... 550#910550

[rufwoof]

There are changes in jwm configuration syntax ... so if you upgrade to 2.3.6 you'll have to go through the jwm configuration files to update/change those https://joewing.net/projects/jwm/config.shtml

[belham2]

There are changes in jwm configuration syntax ... so if you upgrade to 2.3.6 you'll have to go through the jwm configuration files to update/change those https://joewing.net/projects/jwm/config.shtml

I read that too before I compiled 2.3.6, but decided against changing any config-syntaxes from what came in the iso. After compiling and installing 2.3.6, I cannot find one problem with 2.3.6 versus the vgit-976 version that "jwm -v" showed as in there. By now, I would think, as much as I've modded my overall jwm settings, at least one (and probably) several problems should have popped up and/or I should've seen something. So, I don't know, but recobayu may be on to something.

[ETP]

Hi Barry,

To follow up on item 1. in my previous post:

1. Despite the return to retrovol the set master volume level still does not survive a re-boot
returning to zero every time. Suspicion falls on Aumix which perhaps should also have
been removed or some change that was made to the alsa config to accomodate Aumix in the
first place needs to be reverted. In particular /etc/init.d/aumix is still present
together with 3 related config files in /etc. (aumixrc, aumixrc1 & aumixrc2)

After today's tennis final I moved /etc/init.d/aumix to a backup directory.
Set audio volume levels were then preserved across multiple reboots so Aumix was the culprit.

That was my shortest lived Pup ever..... 2days.
Looking forward to your next release.

[rufwoof]

I moved /etc/init.d/aumix to a backup directory.
Set audio volume levels were then preserved across multiple reboots so Aumix was the culprit.

Changing /etc/init.d/aumix lines 34 and 35 to

Code: Select all

SAVEMIXER="no" # save and restore mixer setting by default
HANDLEALSA="yes" # do not save and restore if ALSA detected by default

also preserves alsa settings across reboots (/var/lib/alsa/asound.state however still disappears after a reboot i.e. if created using alsactl store).

[linuxcbon]

Quirky Xerus 8.1.94 for x86_64

- are there missing files for keyboard settings ?

Code: Select all

# /usr/sbin/quicksetup
grep: /etc/X11/xkb/rules/xorg.lst: No such file or directory
grep: /root/.packages/user-installed-packages: No such file or directory

- 2 bugs for adding a new user :
1/ the /home folder should exist by default (mkdir /home)
2/ the file /etc/shadow contains 3 bad entries (surely typos)
messagebus:!:0:99999:7::: should be messagebus:!::0:99999:7:::
haldaemon::0:99999:7::: should be haldaemon:::0:99999:7:::
uucp::0:99999:7::: should be uucp:::0:99999:7:::
That file should be manually corrected as shown above.
And then adding a new user will be bug free.

[rerwin]

I am attempting to run xerus64-8.1.94 by booting from CD but with q.sfs and s.sfs files in folder /xerus64-8.1.94 on /dev/sda1 (ntfs). The PC has 2G of RAM.

After booting from the CD, I added the b43 firmware to /lib/firmware and saved the session. I then "remastered"* the CD to preserve the name of the folder containing the saved session. But on booting from the remastered CD, the desktop was as if there were no saved session.

Here is what I see during boot-up:

• Creating compressed zram, using 1433046K of RAM
  Setting up layered file system, zram on top, Quirky SFS underneath
  Copying q.sfs to RAM
  Loading session from sda1, folder /xerus64-8.1.94, into RAM
  mkdir: can't create directory '/partition/xerus64-8.1.94/s_sfs': Operation not permitted
  mount: mounting /dev/loop0 on /partition/xerus64-8.1.94/s_sfs failed: No such file or directory
  cp: can't stat '/partition/xerus64-8.1.94/s_sfs/*': No such file or directory
  umount: can't unmount /partition/xerus64-8.1.94/s_sfs
  Performing a switch_root onto the layered file system
  Making the filesystem usable...[etc.]

Why is the mkdir not permitted?

As an experiment, I created the s_sfs directory in /xerus64-8.1.94, and rebooted. The boot-up hung at "Loading kernel modules...". But after a manual power-off and new boot-up, the desktop appeared and the /lib/firmware directory contains the b43 directory!

So, the issue is about the not-permitted mkdir.

* Instead of actually remastering the entire quirky CD, "remastering" in quirky is actually the creation of a boot- or initialization CD that relies on the q.sfs and s.sfs files saved on the hard/flash drive in the directory specified for the first "save" operation (default: /xerus64-8.1.94). Please consider a more accurate term and description, to avoid confusing or misleading users.
Richard

[radky]

Hi Barry,

Thanks for your consideration of JWMDesk in Quirky.

A couple of issues in JWMDesk-2.3 are now corrected in the new JWMDesk-2.4.

http://murga-linux.com/puppy/viewtopic. ... 688#869688

1 - The pinstall script is now Woof compatible and the JWMDesk-2.4 pet should be usable in both Woof and conventional installations.

2 - Quirky's unique PuppyPin backup script in /root/.xinitrc assumes the defaultpaint icon is always present on the desktop. Consequently, the Icon Layout option of JWMDesk-2.3 is broken.

In /usr/local/desksetup/func of the new JWMDesk-2.4, PuppyPinBACKUP syncs to the new PuppyPin and the Icon Layout option is now Quirky compatible. If you prefer a different solution, I'm open to suggestions.

The Icon Layout option also has a button to save the current desktop icon configuration as a custom arrangement. If one saves the default Quirky icon configuration as the custom arrangement, it is easy to return to the default desktop as any time, including the unique icon options to install or save Quirky.

3 - JWMDesk supports an optional second panel (accessory tray similar to wbar). This works fine for horizontal trays in Quirky's jwm vgit-976, but vertical trays are broken in vgit-976. Earlier or later versions of JWM do support vertical trays.

4 - In JWMDesk-2.4 the GUI width parameter is stored in /usr/local/jwmdesk/preferences/window_width rather than /usr/local/jwmdesk/window_width. I apologize for this inconvenience to your busy schedule.

The new Quirky is running smoothly for me.

Thanks!

[BarryK]

Mike Walsh's excellent Slimjet-sfs packages work awesome in Quirky. I downloaded his 'Slimjet-Version-15.0.0.0 (based on Chromium 59.0.3071.86_64)', quickly converted it to a pet, and it installed easily & is now running good in Quirky 8.1.94. Slimjet provides a nice counterpoint to the installed Seamonkey 2.48---especially when I want to get at my Netflix stuff

Hold on, I'm missing something here.

How did you do this: "quickly converted it to a pet"

(hmmmm, my sub 800x600, only 244kb pics are not being posted by the murga-board....give me a sec to figure out what's going on....ah, ok, figured it out...here the two pics are)

I did a quick search of the forum, found two of them:

sfs2pet 0.5, by RSH
http://www.murga-linux.com/puppy/viewtopic.php?t=80909

sfs2pet 20121001 by TheAsterisk!
http://www.murga-linux.com/puppy/viewtopic.php?t=81316

From your snapshots, it looks like you are using the one from RSH

[BarryK]

Hi Barry,

To follow up on item 1. in my previous post:

1. Despite the return to retrovol the set master volume level still does not survive a re-boot
returning to zero every time. Suspicion falls on Aumix which perhaps should also have
been removed or some change that was made to the alsa config to accomodate Aumix in the
first place needs to be reverted. In particular /etc/init.d/aumix is still present
together with 3 related config files in /etc. (aumixrc, aumixrc1 & aumixrc2)

After today's tennis final I moved /etc/init.d/aumix to a backup directory.
Set audio volume levels were then preserved across multiple reboots so Aumix was the culprit.

Thanks, I have removed aumix.

[BarryK]

I moved /etc/init.d/aumix to a backup directory.
Set audio volume levels were then preserved across multiple reboots so Aumix was the culprit.

Changing /etc/init.d/aumix lines 34 and 35 to

Code: Select all

SAVEMIXER="no" # save and restore mixer setting by default
HANDLEALSA="yes" # do not save and restore if ALSA detected by default

also preserves alsa settings across reboots (/var/lib/alsa/asound.state however still disappears after a reboot i.e. if created using alsactl store).

/etc/init.d/10alsa saves and restores the alsa state at /etc/asound.state

[BarryK]

I am attempting to run xerus64-8.1.94 by booting from CD but with q.sfs and s.sfs files in folder /xerus64-8.1.94 on /dev/sda1 (ntfs). The PC has 2G of RAM.

After booting from the CD, I added the b43 firmware to /lib/firmware and saved the session. I then "remastered"* the CD to preserve the name of the folder containing the saved session. But on booting from the remastered CD, the desktop was as if there were no saved session.

Here is what I see during boot-up:

• Creating compressed zram, using 1433046K of RAM
  Setting up layered file system, zram on top, Quirky SFS underneath
  Copying q.sfs to RAM
  Loading session from sda1, folder /xerus64-8.1.94, into RAM
  mkdir: can't create directory '/partition/xerus64-8.1.94/s_sfs': Operation not permitted
  mount: mounting /dev/loop0 on /partition/xerus64-8.1.94/s_sfs failed: No such file or directory
  cp: can't stat '/partition/xerus64-8.1.94/s_sfs/*': No such file or directory
  umount: can't unmount /partition/xerus64-8.1.94/s_sfs
  Performing a switch_root onto the layered file system
  Making the filesystem usable...[etc.]

Why is the mkdir not permitted?

As an experiment, I created the s_sfs directory in /xerus64-8.1.94, and rebooted. The boot-up hung at "Loading kernel modules...". But after a manual power-off and new boot-up, the desktop appeared and the /lib/firmware directory contains the b43 directory!

So, the issue is about the not-permitted mkdir.

* Instead of actually remastering the entire quirky CD, "remastering" in quirky is actually the creation of a boot- or initialization CD that relies on the q.sfs and s.sfs files saved on the hard/flash drive in the directory specified for the first "save" operation (default: /xerus64-8.1.94). Please consider a more accurate term and description, to avoid confusing or misleading users.
Richard

My first thought is that the ntfs partition has been mounted read-only. I have only tested on ext4 partitions.

OK, I will create a ntfs partition to test on.

Yeah, I take your point about the "remastering", I need to word that more accurately.

[BarryK]

Hi Barry,

Thanks for your consideration of JWMDesk in Quirky.

A couple of issues in JWMDesk-2.3 are now corrected in the new JWMDesk-2.4.

http://murga-linux.com/puppy/viewtopic. ... 688#869688

1 - The pinstall script is now Woof compatible and the JWMDesk-2.4 pet should be usable in both Woof and conventional installations.

2 - Quirky's unique PuppyPin backup script in /root/.xinitrc assumes the defaultpaint icon is always present on the desktop. Consequently, the Icon Layout option of JWMDesk-2.3 is broken.

In /usr/local/desksetup/func of the new JWMDesk-2.4, PuppyPinBACKUP syncs to the new PuppyPin and the Icon Layout option is now Quirky compatible. If you prefer a different solution, I'm open to suggestions.

The Icon Layout option also has a button to save the current desktop icon configuration as a custom arrangement. If one saves the default Quirky icon configuration as the custom arrangement, it is easy to return to the default desktop as any time, including the unique icon options to install or save Quirky.

3 - JWMDesk supports an optional second panel (accessory tray similar to wbar). This works fine for horizontal trays in Quirky's jwm vgit-976, but vertical trays are broken in vgit-976. Earlier or later versions of JWM do support vertical trays.

4 - In JWMDesk-2.4 the GUI width parameter is stored in /usr/local/jwmdesk/preferences/window_width rather than /usr/local/jwmdesk/window_width. I apologize for this inconvenience to your busy schedule.

The new Quirky is running smoothly for me.

Thanks!

Thank you very much for doing that!

I was going going to pm you, but you got onto it immediately.
That's great, I will upgrade to 2.4.

Yes, I have dragged my heels regarding upgrading jwm. The reason is my laziness, because I will need to fix all of the jwm theme pets.
-- there are a dozen or so of them in the "noarch" pet repo.

I only want to do minimal changes at this stage, before releasing Quirky 8.2, so I guess will leave jwm version as-is for now.

[zygo]

Barry,

I tried a few of your release since werewolf x86_64_7.3.3 but found they would freeze after a few hours or even minutes. I'm hoping that's fixed with the change to aufs.

I booted Quirky Xerus 8.1.94 x86_64 from the iso on a flash drive (live-flash you could say).

I installed mupdf, elinks, firefox and others. They're fine so far but libtre5_0.8.0-4_amd64.deb and libopenjp2-7_2.1.0-2.1_amd64.deb are each listed as a blank line in QPM and abscent from the Check dependencies app (top of setup menu).

EDIT
I noticed, before I installed anything, these 2:

qpdf is ticked in QPM but can not be invoked from the command line. How can I invoke this?

on the command line xnetl<tab> completes to xnetload but there's no executable. I then installed it and now it works fine. I don't see why name completion worked before installation.

Thanks

[rameshiyer]

After booting power failure, now the Qurky Xerus is not booting up. No desktop even after power failure ( It shows either enter option or wait for automatic boot up ).
How to restore Quirky Xerux 8.1.94 installed entire hard disk partition.

2. Please provide Universal Installer.

3. The systems is seems to be slow.

[BarryK]

I am attempting to run xerus64-8.1.94 by booting from CD but with q.sfs and s.sfs files in folder /xerus64-8.1.94 on /dev/sda1 (ntfs). The PC has 2G of RAM.

After booting from the CD, I added the b43 firmware to /lib/firmware and saved the session. I then "remastered"* the CD to preserve the name of the folder containing the saved session. But on booting from the remastered CD, the desktop was as if there were no saved session.

Here is what I see during boot-up:

• Creating compressed zram, using 1433046K of RAM
  Setting up layered file system, zram on top, Quirky SFS underneath
  Copying q.sfs to RAM
  Loading session from sda1, folder /xerus64-8.1.94, into RAM
  mkdir: can't create directory '/partition/xerus64-8.1.94/s_sfs': Operation not permitted
  mount: mounting /dev/loop0 on /partition/xerus64-8.1.94/s_sfs failed: No such file or directory
  cp: can't stat '/partition/xerus64-8.1.94/s_sfs/*': No such file or directory
  umount: can't unmount /partition/xerus64-8.1.94/s_sfs
  Performing a switch_root onto the layered file system
  Making the filesystem usable...[etc.]

Why is the mkdir not permitted?

As an experiment, I created the s_sfs directory in /xerus64-8.1.94, and rebooted. The boot-up hung at "Loading kernel modules...". But after a manual power-off and new boot-up, the desktop appeared and the /lib/firmware directory contains the b43 directory!

So, the issue is about the not-permitted mkdir.

* Instead of actually remastering the entire quirky CD, "remastering" in quirky is actually the creation of a boot- or initialization CD that relies on the q.sfs and s.sfs files saved on the hard/flash drive in the directory specified for the first "save" operation (default: /xerus64-8.1.94). Please consider a more accurate term and description, to avoid confusing or misleading users.
Richard

My first thought is that the ntfs partition has been mounted read-only. I have only tested on ext4 partitions.

OK, I will create a ntfs partition to test on.

Yeah, I take your point about the "remastering", I need to word that more accurately.

Oh dear. there is a problem with ntfs.

Not using ntfs-3g, but the one in the kernel.

# busybox mount -t ntfs /dev/sda9 /mnt/sda9

# mount
....this shows it is mounted rw.

# mkdir /mnt/sda9/testdir
...fails!!! "operation not permitted"

Any ideas why?

[BarryK]

Oh dear. there is a problem with ntfs.

Not using ntfs-3g, but the one in the kernel.

# busybox mount -t ntfs /dev/sda9 /mnt/sda9

# mount
....this shows it is mounted rw.

# mkdir /mnt/sda9/testdir
...fails!!! "operation not permitted"

Any ideas why?

The kernel has the ntfs driver builtin, and configured to allow rw mounting. The initrd used to work, mounting a ntfs partition rw and it could be written to.

However, something has changed. But what?

Anyway, I have put the ntfs-3g driver into the initrd.q, and modified the 'init' script in the initrd.q to use ntfs-3g instead of the kernel builtin driver.

I haven't tried it yet, but it should work. ntfs-3g is a fuse-based driver, and is compiled statically, about 410KB. A bit bulky.

It is better to use ntfs-3g anyway, due to its more reliable performance. Slow, because of the fuse, but reliable.

[L18L]

But after some reboots no reboot was possible any more.
I have read now that 4GB RAM is not enough.
But not finding a way out of this situation (fsck did not help) makes it a no go for me.

How did you get that idea? 4GB RAM is plenty. A full install should run on fine a PC with less than 1GB RAM.

What do you mean by "no reboot was possible any more"?
What exactly happens when you boot?

OK. that value of 4GB is for the drive.

The full install was created by

Code: Select all

gunzip --stdout xerus64-8.1.94-8gb.img.gz | dd of=/dev/sdb bs=4M

Keyboard was working but I have no idea what to do on shell in ramdisk.