LxPupSc: Woof-CE, Slackware-Current, LXDE build 13-Jun-2020

[peebee]

Interim delta +2 to LxPupSc-18.01+2T-32pae.iso

BUILD_FROM_WOOF='testing;3ff35ec2;2018-01-07 23:21:18 +0800'

incorporates a raft of changes to woof-ce's pup-event handling by wdlkmpx on github

[Marv]

+2 delta downloaded, applied, and tested on the Fujitsu S761 above, both as pristine frugal and update of stripped +1 savefile. md5sums correct, clean boots on both, autoplay of CD and DVD works correctly both on pristine with default settings and on my update. USB3 flashdrive shows up correctly on PCmanFM when hotplugged. Nice to see the 4.14.12 kernel. Maybe a few more eyeballs have seen the kpti patches.. I'll use LxPupSc +2 on the i5 as daily and push the 4.14.12 kernel to Artful and LxArtful. Current versions of those three pups are now installed on the i5 and core 2 duo laptops and the Bay Trail desktop with the 4.14.11 kernel with no issues. Samba not being used at this time. Posting from Light in the pristine install.

Thanks,

[peebee]

Interim delta +3 to LxPupSc-18.01+3T-32pae.iso

- kernel 4.14.13 32-bit pae

- BUILD_FROM_WOOF='testing;358697d4;2018-01-10 22:32:18 +0800'

- Slackware Current Tue Jan 9 00:54:19 UTC 2018

with @Marv have been investigating enabling PAGE_TABLE_ISOLATION in 32-bit kernels but so far have not found how to.....

[mistfire]

@peebee I tried to compile the kernel with CONFIG_PAGE_TABLE_ISOLATION=y parameter but that parameter was missing or got deleted when start compiling the kernel

[peebee]

@peebee I tried to compile the kernel with CONFIG_PAGE_TABLE_ISOLATION=y parameter but that parameter was missing or got deleted when start compiling the kernel

Indeed - same experience here - suspect this config option is only applicable to 64-bit???

Found at: https://www.debian.org/security/2018/dsa-4078

This specific attack has been named Meltdown and is addressed in the Linux kernel for the Intel x86-64 architecture by a patch set named Kernel Page Table Isolation, enforcing a near complete separation of the kernel and userspace address maps and preventing the attack.

[mistfire]

@peebee so it means that 32-bit linux are vulnerable to meltdown attack?

[peebee]

Back to 64-bit kernel with thanks to @Marv and to FatDog64 and @jamesbond

Interim delta +4 to LxPupSc-18.01+4T-k64.iso

- kernel 4.14.13 64-bit with CONFIG_PAGE_TABLE_ISOLATION=y

[Marv]

Got it. Delta applied, md5sum correct, installed to Fujitsu S761 laptop (2nd gen i5). Both pristine and update of scrubbed +2T savefile done and checked for kpti patches and ucode loading capability. OK on all counts. Pristine checked through timezone setup, SNS connection and firewall setup, sound, video resolution, savefile creation, and reboot. OK on all counts. I'll check CD, DVD, and other hardware later. Also swap into my Artful, LxArtful, and XFCEXenial pups. Looks good!

A note on the ucode loading: There is not yet ucode for spectre mitigation for the 2nd gen i5 in the Jan 8 Intel update; but there is newer code than in my CPU so I can check the original microcode, force a late update (intel-ucode folder added to /lib/firmware) with

Code: Select all

echo 1 > /sys/devices/system/cpu/microcode/reload

and see that the microcode has been updated. Once satisfied with the setup, having the relevant intel-ucode file in /lib/firmware and the code line above in rc.local will ensure late loading on boot. I'm more used to doing it that way (late) and updating the ucode pkg. is simpler for me. As of now (and maybe forever) there is no mitigation code for any of the 3 classes of intel CPUs I run. See here for an explanation of early and late ucode loading: http://www.murga-linux.com/puppy/viewto ... 149#980149

Thanks,

Edit: Later, kernel swapped into pups listed above. All good.
Edit2: Later, above done on core 2 duo laptop and Bay Trail desktop. All OK there also. Link to jamesbonds explanation of early and late loading added.
Edit3: Later, confirmed use of 'force' line in rc.local on boot in all & added note on that.

[peebee]

CAUTION: only try this in a new frugal install!!

Updated 22-jan2018

For anybody who would like to try @gyro's new initrd approach based on overlayfs instead of aufs ......

Apply the delta to the LxPupSc-18.01T-k64.iso to produce LxPupSc-18.01+6-k64-overlayfs.iso

Do a frugal install but in addition to the usual files copy 2 extra files into the frugal directory:
BOOT_SPECS
overlay_mods.sfs

Make sure your kernel boot line in for example menu.lst contains both pdrv= and psubdir= parameters. e.g.

Code: Select all

kernel /overlayfs/vmlinuz  pmedia=atahd pdrv=sda4 psubdir=overlayfs

where my frugal directory is overlayfs and resides on partition sda4

Note that sfs handling and shutdown are different to aufs based pups. Also initial timezone is set to Pacific-Kiritimati as recommended by @01micko.

8. Reboot to enjoy the new working puppy.
To modify the list of extra sfs's that "init" tries to mount, use "Extra-SFS manager".
To modify the list of system sfs's that "init" tries to mount, use "System-SFS manager".
To change some of the boot characteristics, use "Pfix parameter manager".
To change "save" to a different mechanism or change the location of the savefolder, use "Saveconfig".

What needs to be tested:

1) That it does successfully boot current woof-ce based Puppies, i.e. they boot to the desktop.

2) Are there any Puppy utilities, other than the patched ones included in "overlay_mods.sfs", that are broken by this "init"?
Please don't bother telling me about "sfs_load" or "snapmergepuppy", these are incompatible with overlayfs.

3) That the booted Puppies work the same as when they are booted with their release "init".
While I have done many, many boots as part of this project, I haven't sustainably used the resultant Puppy.
I plan to setup a Puppy I can use as my daily workhorse and boot it with this "init".

Please report any test results on @gyro's thread.

[Sailor Enceladus]

Strange, you are using a 32-bit OS but with a 64-bit kernel? I think this is the first time anyone tried to release something like this in a puppy (?), surprised it works. Wonder if this will work on my Pentium M laptop or I'll get something like this:



Might try it later, unless someone beats me to it.

[westwest]

Hi, the option to "open download location" in palemoon brings up the dir2pet script.
This happens in both tarball and sfs versions of palemoon...
Frugal install to hd, lxpupsc 18.01+3T-32pae.

[westwest]

Problem solved, edited the mimelist...

[Marv]

Strange, you are using a 32-bit OS but with a 64-bit kernel? I think this is the first time anyone tried to release something like this in a puppy (?), surprised it works. Wonder if this will work on my Pentium M laptop or I'll get something like this:



Might try it later, unless someone beats me to it.

The use of a 64-bit kernel in LxPupSc goes back to here: http://www.murga-linux.com/puppy/viewto ... 510#962510. I've also sucessfully used the 64-bit LxPupSc kernels in a number of other pups since then, both 32-bit and 64-bit. And yep, it's only for true 64-bit CPUs so the Pentium Ms won't run it.

[peebee]

Reuploaded 18-jan-18 with reverted glib2

Interim delta +5 to LxPupSc-18.01+5T-k64.iso

- kernel 4.14.14

- Slackware Current to Wed Jan 17 21:36:23 UTC 2018 less glib2
Updated.....
:ca-certificates:
:cups-filters:
:gawk:
:gtk+:
:gvfs:
:iw:
:kmod:
:libnftnl:
:librsvg:
:libsoup:
:mesa:
:libsigsegv:
:libtasn1:
:mpfr:

Palemoon-27.7.0 also available for download

[Marv]

+4T updated to +5T on the i5 Fujitsu S761. md5sum correct, no issues noted, using it as the main daily with your Slimjet-as-spot SFS onboard. Since mesa changed, I looked at video performance and benchmarks vs +4T since I'd just done a set and saw no differences. Kernel 4.14.14 (& 4.9.77) should have retpoline patches backported so I wanted as close to an apples-to- apples comp as I could get for when that shows up. Not testing the overlayFS fork as I use SFS-load-on-the-fly and snapmerge a LOT.

Cheers,

Edit: networked HP4500 printer continues to print fine. Doing PDF taxcrap

[peebee]

+5 reuploaded 18-jan-18 with reverted glib2

bit later: also kernel 4.14.14

[peebee]

Interim delta +6 to LxPupSc-18.01+6T-k64.iso

- 64-bit kernel 4.14.14 with CONFIG_PAGE_TABLE_ISOLATION=y

- Slackware Current to Sat Jan 20 16:00:51 UTC 2018

[Marv]

+5 (original upload) savefile scrubbed and updated to +6. md5sum correct, SNS connection, video, sound, lidsuspend, printing all ok on S761 i5 laptop. CPU & memory use at idle unchanged. No CPU race condition seen loading and using LibreOffice 5.3.7. Original +5 gave 36% on this hardware. Looking at the 4.14.14 kernel mostly. No ucode from intel for this i5 so no change on that front. The retpoline patches show up as enabled in the kernel but for full support it requires compiling with GCC compiler 8.0, probably also backported to 7.3. Those compilers may also change the Spectre 1 mitigation. FWIW the output of the spectre-meltdown-checker script is attached.

Other than chasing intels tail along with the rest of the world, it seems a happy LxSc puppy.

Edit: Using glxgears, CPU cryptohash, and FPU raytracing I see no measurable change in cryptohash or raytracing adding retpoline to kpti and a 5% increase in glxgears FPS. All pretty near noise and well less than pup-to-pup differences on this same hardware.

[peebee]

The retpoline patches show up as enabled in the kernel but for full support it requires compiling with GCC compiler 8.0, probably also backported to 7.3. Those compilers may also change the Spectre 1 mitigation. FWIW the output of the spectre-meltdown-checker script is attached.

Hi Marv

I'm struggling to identify a 64-bit puppy with GCC-7...... All seem to have GCC-4 or GCC-5 (i.e. Fatdog, Slacko64 and XenialPup64) (Pyro64 has GCC-6.3.0 I think)......I'm currently compiling with Slacko64 which provides GCC-5.3.0 in its devx.

LxPupSc of course has GCC-7 but is 32-bit so no good for kernel compiling....

I have done a kernel compile using Porteus-v4.0-RC1 which does have the GCC-7 compiler - mainly to see if it changed the kernel size (which it didn't). Sadly I've since deleted it.

Cheers
peebee

[peebee]

Delta for overlayfs experiment is updated to @gyro's v0.2 - see above