Another Jammy64pup

[jrb]

I really would like this project/build to develop further and not stagnate or be abandoned.

If you're only worried about security, you need this Puppy to be rebuilt with the latest Ubuntu 22.04 packages every once in a while, and update your Puppy.

I can do that. I haven't abandoned this project, but I am taking some time to focus on other parts of my life.

It would seem the heavy lifting on this project is pretty well done. I applied the various fixes from this to the Debian BookWorm build template and they all worked. Took about an hour, so I don't think a rebuild will be too onerous. I am very surprised however at how often there are changes in the ubuntu packages. I think I would have to issue a rebuild every few days to keep up.

[mikeslr]

... I think I would have to issue a rebuild every few days to keep up.

Don't go crazy. Ubuntu builds frequently because (a) Canonical's staff has to find things to do or face unemployment and (b) the unitary structure --constantly reading from/writing to-- the Storage media renders Ubuntu's much less secure than Puppys.

I'd suggest period checks to see what 'updates' Ubuntu has made. Only those relating to internet access and security are of significance.

And as I've posted a couple of times, what would be of value to all reasonably current and future Puppys is a dedicated repository which could hold bug fixes and updates obtained via a quickpet application.

[dimkr]

A monthly build sounds adequate to me, and you can automate the process of building it. I automate all my dpup builds (https://github.com/vanilla-dpup/releases/actions) and this 1) ensures they're built in a clean environment with everything needed and no unknown packages or version mismatch that can pollute the build 2) ensures the build is reproducible 3) ensures all changes are tracked and it's easy to tell if problem A is the result of change B 4) allows others to customize dpup without fear that the starting point is wrong 5) saves time and makes Puppy development using limited free time much more efficient.

Building periodical "update" packages manually and serving them via something like quickpet sounds impractical and unsustainable to me.

[Marv]

Missed being able to transfer files/pictures to and from from my open source android flipphone in jammypup64. Path of least resistance for me was to install PupMTP 1.2 by pet from here https://oldforum.puppylinux.com/viewtop ... 9#p1029389, simple-mtpfs-0.3.0-x86_64_common64.pet downloaded from a ubuntu focal repo (not available in the jammy repos), and libmtp9_1.1.19-1build1_amd64.deb from the jammy repos.

Not a lot of overhead and works correctly and simply for me in jammypup64 D3.

[jrb]

Missed being able to transfer files/pictures to and from from my open source android flipphone in jammypup64. Path of least resistance for me was to install PupMTP 1.2 by pet from here https://oldforum.puppylinux.com/viewtop ... 9#p1029389, simple-mtpfs-0.3.0-x86_64_common64.pet downloaded from a ubuntu focal repo (not available in the jammy repos), and libmtp9_1.1.19-1build1_amd64.deb from the jammy repos.

Not a lot of overhead and works correctly and simply for me in jammypup64 D3.

Have built a "simple-mtpfs" package in WoofCE using the files you have specified. It will be in the next build, hopefully posted today. Just finishing up another package before I post.

Cheers, J

[jrb]

OK, New ISO at page 1 post 1

Changes include Ubuntu files up to date, PupMTP android mounter on Filesystem menu (Thanks @Marv), Encfs Folder Encrypt on Utility menu, Lame mp3 encoder.

The PupMTP android mounter opens a GUI for me but I have no android equipment to test it on. I followed @Marv's instructions so it should be good to go.

The Encfs Folder Encrypt is actually a cli app on the right click menu. Opening it from the Utility menu will show you instructions on how to use it.

Lame mp3 encoder just because I use software which creates .wav files and I like to convert them to .mp3.

Cheers, J

[Marv]

Up and running E1. md5sum correct. Same minimal frugal install to the Fujitsu S761 hardware circa 2012 as previously, repo package information correction from D3 noted, PupMTP checked and working here -thanks-, Sound fine, I'll check USBflash install and boot and multimedia stuff later and just use it a bit. No Samba use planned. Posting from a Brave portable now.

Thanks,

[ozsouth]

I made a usrmerge 6.1.23 64bit kernel (/lib /sbin symlinks from /usr) with sources & headers. Tested OK in D3 - see forum Kernels section.

[jrb]

I made a usrmerge 6.1.23 64bit kernel (/lib /sbin symlinks from /usr) with sources & headers. Tested OK in D3 - see forum Kernels section.

I can confirm, it boots up and runs nicely on all my hardware, UEFI and BIOS. Nice work @ozsouth.

[rockedge]

The user merge model is utilized by KLV kernels. Up until now to get a huge Puppy Linux kernel to integrate into KLV it was a matter of decompressing the fdrv SFS from the huge kernel and move /lib/firmware to /usr/lib/firmware and squash the fdrv back to a SFS file.

I made a kernel 5.16.14-KLV that is both patched for AUFS and has Overlayfs builtin and the fdrv SFS has the structure:

Code: Select all

/fdrv.sfs
|_lib
   |_firmware
|_usr
    |__ lib
         |_firmware

Which allows quick interchangeability between a Puppy Linux system or a Kennel Linux system when using the FirstRib skeleton initrd.gz

I will try out this kernel to see it I can just swap it into a KLV now running a Void Linux kernel.

[LateAdopter]

Could someone tell me what is preventing Rox from using the correct icon size, please?

I'm currently using D1 but the behaviour hasn't varied.

With the standard settings Rox should change to small icons at a set number, but it doesn't.
If I set small icons, nothing happens.
If I set huge icons the spacing changes but the icons stay the same.
All the icon themes seem to be normal and I haven't changed from PMaterial.

Something is preventing Rox from working normally.

Thanks

[jrb]

]

Could someone tell me what is preventing Rox from using the correct icon size, please?

I'm currently using D1 but the behaviour hasn't varied.

With the standard settings Rox should change to small icons at a set number, but it doesn't.
If I set small icons, nothing happens.
If I set huge icons the spacing changes but the icons stay the same.
All the icon themes seem to be normal and I haven't changed from PMaterial.

Something is preventing Rox from working normally.

Thanks

This is in E1. I opened the Rox window, selected Options-IconView-Large and then, leaving the first window open, opened the window again. Then I repeated for Huge Icons, so I ended up with 3 windows each with different size icons. If you want to see a difference you have to reopen the window after setting the Icon option.

I'm reasonably sure that's the case for D1 as well.

[jrb]

With the standard settings Rox should change to small icons at a set number, but it doesn't.

I'm not sure I understand this. Which set number are you referring to?

It occurred to me that you might be talking about the icon size in the menu bar in Rox so I tried changing that, with no luck whatsoever. So I tried it in Bionic64, S15Pup64 and ScPup64 with no success. Let me know what menus you have been using.

[LateAdopter]

With the standard settings Rox should change to small icons at a set number, but it doesn't.

I'm not sure I understand this. Which set number are you referring to?

Hello jrb
Thanks for investigating.
The number I was referring to is in Rox filer - Options... - Icon View - Automatic small icons

The pictures that you posted are what I would expect and what i get with Bionicpup and Fossapup but it's not working like that in my copy of jammy64pup.
I can reproduce the results that you get if i use the buttons on the window's toolbar in the applications directory. However, whenever I open a window containing directories it doesn't do what I expect. I'll work through what happens so that I can tell you the steps to reproduce...

And I'll make an E1 install and try again in case something I have installed may have broken the Rox or xdg configuration.

EDIT
In the process or trying to define "steps to reproduce" I have fixed it...

To change the ROX settings you right click any icon on the desktop and select ROX-Filer, but jammy64pup doesn't have any icons to start with. I had installed Celluloid and I previously right clicked that icon to get to the ROX-Filer settings. But changing the settings didn't have any effect.
This time I put the ROX-Filer icon on the desktop and right clicked that. Having changed the settings that way, it now does what I expect.

Sorry for the distraction.

[jrb]

The number I was referring to is in Rox filer - Options... - Icon View - Automatic small icons

I had never noticed that setting before and I find that it doesn't seem to work in E1 or in Bionic64. Do you know of a Puppy where it works?

You don't need a desktop icon to change Options. Just open a Rox window, Menu-FileSystem-ROX-Filer will do, and right click in any blank area in the window. You should see Options on the right-click menu.

[fr-ke]

@jrb
works in Fossabpup64-ce

Screenshot.png (253.32 KiB) Viewed 7867 times

[/img]

[LateAdopter]

Hello jrb

It's working now in my copy of jammy64pup, but I don't know exactly what fixed it. After reading your original reply I tested manual setting of icon size on the /usr/share/applications folder, both set huge and set small with L & R mouse clicks and automatic size mode. They all worked. Then I went back ROX filer options and set automatic and that worked too.

It seems that jammy64pup needs a bit of training first. I have not had to fiddle about before with other puppies.

I set JWM to tile ROX windows, so I like to keep them small, if possible.

[mikeslr]

I try out new Puppys/versions by mounting their ISO, copying system files into a folder and editing menu.lst or grub.cfg. With jrb-E1 I noticed two files whose purpose wasn't apparent: zdrv_cp2deb and zdrv_rst. What are they for/ do they do; and how does one use them?

There's another file which has been around for some time. Maybe I once knew its purpose and have forgotten: ucode.cpio. Deploying Puppys as above, is it needed? useful?

[ozsouth]

@mikeslr - those 2 zdrv_ files are scripts to convert an older zdrv to usrmerge format. The ucode file is microcode to mitigate against spectre/meltdown. I made standalone intel microcode files in the past, but that is now unnecessary for usrmerge pups (& perhaps other woofce pups too).

[jrb]

With jrb-E1 I noticed two files whose purpose wasn't apparent: zdrv_cp2deb and zdrv_rst. What are they for/ do they do; and how does one use them?

As @ozsouth explained (thanks), zdrv_cp2deb will convert any zdrv with the older file structure to the new Debian USR_SYMLINKS system. Just have the new zdrv and its accompanying vmlinuz in the same folder, a different Puppy install folder will do, and drag the zdrv onto the zdrv_cp2deb script. Windows will open, scripts will run and you can watch it being converted. In your Jammy64 folder the original zdrv_upup_22.04.sfs and its vmlinuz will become zdrv_upup_22.04.sfs.old and vmlinuz.old. A new zdrv_upup_22.04.sfs and vmlinuz will appear and hopefully you will be able to reboot with a new kernel.

If you are not satisfied with the new kernel simply click on zdrv_rst (restore) and the .old files will be restored. Be prepared however, if your reboot is unsuccessful you will have to boot up a different Puppy and then click on zdrv_rst. Also on my old slow laptop zdrv_upup_22.04.sfs.old restores but vmlinuz.old doesn't so I have to rename it manually.

My laptop has a long pause when booting with the default 5.15.85 kernel and any of the 6.XXX kernels I have tried. Bionic64's 4.19 kernel and peebee's huge-5.11.11-lxpup64 kernel boot rapidly with no pause so I'm using 5.11.11. Thanks peebee.

I hope that explanation makes sense. Cheers, J

[mikeslr]

Thanks, jrb, for the explanation. I too will try peebee's huge-5.11.11-lxpup64 even though I don't find the startup delay intolerable.

By the way, if anyone's interested, I solved the issues I had running pwidgets. See, https://www.forum.puppylinux.com/viewto ... 899#p86899.

[mikeslr]

Well, maybe I won't try huge-5.11.11-lxpup64 for a while. I've remembered that on my ToDo list is exploring Jammy64pup using overlays.

The two things I wanted to explore were (a) To what extent nicOS's Save2SFS might be used, realizing that at best it would create an a/ydrv which would have to be renamed. But just having completed creating a ydrv with the stock kernel using aufs it occurred to me that even if Save2SFS didn't work directly under overlays, there is a possible work-around. IIRC, oz builds kernels which can be employed working with either aufs or overlays depending on a boot argument. At least theoretically, you can start with aufs, create a a/ydrv --after which you wouldn't be using a SaveFile/folder-- then rename the a/ydrv and edit the grub/menu argument. Well, a workaround at least while our Devs continue creating such flexible kernels.

Other than our Devs not having to modify 'Stock kernels', I'm still not sure what advantage overlays have. Maybe it's easier to update frequently changed applications, e.g. web-browsers.

(b) Remastering: still don't have any useful thoughts.

[ozsouth]

@jrb - I wonder at what stage your boot is stalling? I had those problems years ago - seemed to be an issue finding root, so I set labels on all my ext (or ntfs) partitions via gparted. I used date & letters, i.e. 170423a , 170423b etc. Then in grub, I added to the linux (kernel) line (for example) pdrv=170423b rootwait . Seems to work well, especially with usb, which can change drive letters.

By the way, I really like your Jammypup. Well done.

[jrb]

@jrb - I wonder at what stage your boot is stalling? I had those problems years ago - seemed to be an issue finding root, so I set labels on all my ext (or ntfs) partitions via gparted. I used date & letters, i.e. 170423a , 170423b etc. Then in grub, I added to the linux (kernel) line (for example) pdrv=170423b rootwait . Seems to work well, especially with usb, which can change drive letters.

By the way, I really like your Jammypup. Well done.

Glad you like it. I'm pretty happy with it too.

Here's what's happening at boot:
Choose the Jammy64pup from grub4dos boot menu.
Immediately goes to (hd0,2) - the home directory.
Within 1 sec
[linux-bzimage, setup=0x3c00 size,0x4e860]
[linux-initrd @ 0x7tbe000 0x2402f9 bytes]
At this point it sits there for 2+ minutes and then proceeds to boot up normally.

It looks to me as if something in vmlinuz is causing the delay but I never have figured out how to extract or rebuild vmlinuz, so I'm just guessing.

The odd thing is I have this Core2duo 2.2Ghz laptop setup next to a Core2duo 2.6Ghz desktop which shows not the slightest hesitation in booting with any of the kernels I have tried. Also Bioni64 4.19 and peebee's 5.11.11lxpuup kernels show no hesitation in booting on this laptop. Oh well, another mystery.

[ozsouth]

@jrb - as it's finding root ok, could be (like another old system I've had) just not readily compatible with later kernel branches.
Your replacement kernels are very old, so I'll try to modify my 5.10.174 kernel (March 2023), which may work ok.
EDIT: 5.10.174 provided a good (unexpected) test outcome, but not especially useful, so won't upload it.

[Marv]

I don't (knock on forehead) have any delays to speak of on any of my i5 based lappies no matter what kernel I throw at them. About 17 seconds button push to usefullness from the grub4dos SSD and just the expected 5 second delays and read times from USB3. Does your balky laptop have either an sd cardreader or a pcmia/pciexpress slot you don't use? If either, you could try disabling them in BIOS if possible. My Bay Trail desktops both had serious coffee making and getting delays that were due to a USB connected multi card reader. They weren't really being used on either, I pulled them, and the delay is gone. Just a thought.

[ozsouth]

@jrb - Marv's suggestion is quite possible.

I edited my 5.10.174 kernel & it gave an error, waited 60 sec, then booted, ran & shutdown normally.
The stock kernel seems to have created a file (in the folder with all the sfs's) upupinitmodules.txt (it isn't in the E1 iso),
which contains: i2c_hid_acpi,i2c_hid

My 5.10.174 kernel doesn't have that acpi driver configured, & removing that from the .txt file gave a normal boot, no delay.
The bionicpup64 4.19.23 kernel also doesn't have that configured. Nor does 5.11.11lxpup.

My 5.10.174 & 6.1.23 kernels & the stock kernel boot normally with just i2c_hid in the file.

I'm thinking your troublesome pc may not support i2c_hid_acpi, so if you have upupinitmodules.txt with just i2c_hid, delay may go.

[LateAdopter]

I have needed to deal with the I2C_HID issue for a long time. In my system they are used for my Logitech K400+ wireless keyboard.
The *initmodules.txt is put in the directory with the savefile.
There are two variables:

If you change to a kernel with the module(s) built-in, then init complains because it can't load the module(s)

The number and naming of the module(s) has varied with different kernel versions. So what's in the *initmodules.txt may not match the kernel that you are using.

For my keyboard the solution is simple: rename / delete *initmodules.txt. The Logitech keyboard behaves as a generic USB keyboard and mouse to start with and will work in the BIOS setup screens. It's only when linux recognises it as Logitech that it needs to load the modules or it stops working. When this issue first arose, a lot of Ubuntu users got stuck at the login screen because the kernels did not have the module built.

If you don't need the I2C device to boot the init then the *initmodules.txt is redundant. The module(s) get loaded automatically before you need them anyway.

[jrb]

I don't (knock on forehead) have any delays to speak of on any of my i5 based lappies no matter what kernel I throw at them. About 17 seconds button push to usefullness from the grub4dos SSD and just the expected 5 second delays and read times from USB3. Does your balky laptop have either an sd cardreader or a pcmia/pciexpress slot you don't use? If either, you could try disabling them in BIOS if possible. My Bay Trail desktops both had serious coffee making and getting delays that were due to a USB connected multi card reader. They weren't really being used on either, I pulled them, and the delay is gone. Just a thought.

Had a look at the Bios, no hardware control at all, as minimal a Bios as I've ever seen.

[jrb]

@jrb - Marv's suggestion is quite possible.

I edited my 5.10.174 kernel & it gave an error, waited 60 sec, then booted, ran & shutdown normally.
The stock kernel seems to have created a file (in the folder with all the sfs's) upupinitmodules.txt (it isn't in the E1 iso),
which contains: i2c_hid_acpi,i2c_hid

My 5.10.174 kernel doesn't have that acpi driver configured, & removing that from the .txt file gave a normal boot, no delay.
The bionicpup64 4.19.23 kernel also doesn't have that configured. Nor does 5.11.11lxpup.

My 5.10.174 & 6.1.23 kernels & the stock kernel boot normally with just i2c_hid in the file.

I'm thinking your troublesome pc may not support i2c_hid_acpi, so if you have upupinitmodules.txt with just i2c_hid, delay may go.

No sign of a upupinitmodules.txt file. I'm thinking that I might just keep trying kernels, you've got lots to choose from, and see what happens. The two minute wait isn't that big a deal and this laptop really only gets used with Bionic64 running Mike Walsh's Zoom Portable, my wife has a weekly meeting.

Thanks to you all for trying to help , J