Moderator: Forum moderators
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.
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.
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.
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.
My pups: LxPupSc64 and Voidpup64 with LXDE ydrv & synaptics touchpad drivers, both using savefiles. Ydrv based Jammypup64 (JWM), Bookworm64, Fossapup23 & FossapupFire (LXDE/PCManFM). No savefiles, no fdrvs there. 
Marv wrote: ↑Thu Apr 06, 2023 3:57 pmMissed 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
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
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,
My pups: LxPupSc64 and Voidpup64 with LXDE ydrv & synaptics touchpad drivers, both using savefiles. Ydrv based Jammypup64 (JWM), Bookworm64, Fossapup23 & FossapupFire (LXDE/PCManFM). No savefiles, no fdrvs there.
I can confirm, it boots up and runs nicely on all my hardware, UEFI and BIOS. Nice work @ozsouth.
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
|_firmwareWhich 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.
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
]
LateAdopter wrote: ↑Tue Apr 11, 2023 9:50 amCould 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.
LateAdopter wrote: ↑Tue Apr 11, 2023 9:50 amWith 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.
jrb wrote: ↑Thu Apr 13, 2023 2:23 amLateAdopter wrote: ↑Tue Apr 11, 2023 9:50 amWith 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.
LateAdopter wrote: ↑Thu Apr 13, 2023 8:28 amThe 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.
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.
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?
@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).
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
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.
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.
@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.
ozsouth wrote: ↑Mon Apr 17, 2023 5:55 am@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.
@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.
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.
My pups: LxPupSc64 and Voidpup64 with LXDE ydrv & synaptics touchpad drivers, both using savefiles. Ydrv based Jammypup64 (JWM), Bookworm64, Fossapup23 & FossapupFire (LXDE/PCManFM). No savefiles, no fdrvs there.
@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.
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.
Marv wrote: ↑Wed Apr 19, 2023 11:42 pmI 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.
ozsouth wrote: ↑Thu Apr 20, 2023 2:44 am@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_hidMy 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