Discussion, talk and tips
https://forum.puppylinux.com/
Question @mypuppy2
Is there an OS on your system drive (other than the PUPs you test) that boots? If so, which OS?
In the past was the drive seen by past PUP distros? If so, which?
I have several OS installed which includes: Windows 10, Windows 7, and Xubuntu 19
Nope, this is my first time using Puppy Linux but I have already tested some old distros that I already have from long time. With these old distros I can normally boot and install them without HDD detect issues.
Here's list of some images that I can run them without HDD detect issue:
Code: Select all
antiX-22_x64-full.iso
linuxmint-21.1-mate-64bit.iso
xubuntu-19_10-desktop-amd64.iso
@mypuppy2
Boot the PUP again
Open a terminal and show us the results of this command >> parted -l that's a lowercase "L"
Model: SanDisk Cruzer Blade (scsi)
Disk /dev/sdb: 15.7GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 8258kB 15.7GB 15.7GB primary ntfs boot
Model: Unknown (unknown)
Disk /dev/zram0: 3022MB
Sector size (logical/physical): 4096B/4096B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 3022MB 3022MB linux-swap(v1)
Any MEMBERS seen this before?
The issue are confirmed that it's been caused by the kernel.
Is there a way to change the kernel used in Puppy distros ?
Is there a way to change the kernel used in Puppy distros ? It's very easy. But that may not be your problem.
To swap kernels you can grab the vmlinuz and zdrd,sfs (e.g. zdrv_fossapup64_9.5.sfs) and replace the current versions renaming the zdrv.sfs to zdrv_dpupbw64_10.0.6.sfs. Or download a hugh package from here, https://www.forum.puppylinux.com/viewforum.php?f=65 extract it; rename the vmlinuz_xxx to just vmlinuz, and rename kernel_modules.sfs to zdrv as previously. Then swap. You may also need firmware; also available from the cited Section; renaming firmware to fdrv_dpupbw64_10.0.6.sfs.
But I notice that you've previously installed "antiX-22_x64-full.iso
linuxmint-21.1-mate-64bit.iso, and xubuntu-19_10-desktop-amd64.iso"
and that
"Model: Unknown (unknown)
Disk /dev/zram0: 3022MB
Sector size (logical/physical): 4096B/4096B
Partition Table: loop Emphasis supplied.
Disk Flags:"
I now have two laptops which can't boot any Puppy from the internal drive after installing first Manjaro, then Zorin, then Linux-Mint, then Zorin-xfce. Not even after trying with the new Grub2config-2.0.2, https://www.forum.puppylinux.com/viewto ... 35#p115435. Attempt to install it results in the 'can't write error' previously reported. I examined the Dell laptop yesterday and discovered that sda1 had been over-written to create an extended partition with (now) Zorin being located on a logical partition.
The problem started with Manjaro when I replaced an old version of Linux Mint. As indicated above, I can replace a 'Major' distro with others, doing so didn't enable me to boot any Puppy. And, yes, I've used gparted to completely revise the partition table; but I don't recall using gparted, then NOT installing a Major Distro before installing Puppy.
I'm considering doing a low-level format. But was going to seek advice first.
P.S. I'm really pissed. Caution: anyone trying to resolve this problem by installing a Major Distro should realize the risk ending up with a computer which can't boot Puppys. Caution 2: I chose Zorin-xfce as the last as it worked best with my Dell hoping that I could then custom edit it's grub menu. But it's grub menu isn't simple.
Remastering BW64
Remastering is a Puppy feature that allows you to build all your added apps and customization's into a new main Puppy .sfs file and/or ISO file.
Bookworm64 includes @amethyst great nicOS-Utility-Suite which can be used to remaster Puppy. If you choose Remaster-Classic or Remaster-Alternative it will rebuild the main Puppy .sfs file. When that is complete you have to manually add additional files from the ISO file that was used to set up the installation, before creating the ISO.
That process may be confusing for new or unfamiliar users.
Remasterme.sh is an alternate method that uses remasterpup2 (which is also included in BW64). Remasterpup2 has not been maintained, so just running it will not produce the expected results.
The script program "remasterme.sh" uses remasterpup2 and adds to it to produce a remaster including desktop and wallpaper.
It requires the user to place the Puppy ISO (must be the only ISO) and remasterme.sh program in the same directory and then run remasterme.sh. No manual copying is required, just read and follow the on screen instructions carefully.
Here is a comparison of the two programs, the test installation contained a 206mb save folder.
Both methods have plus's and minus's. I will use both, depending on the situation
In the test, remasterme.sh created an ISO that was 275mb smaller than produced by nicOS-Utility-Suite.
Please use this first release for testing only. Comments and suggestions are invited.
Thanks
wizard
The remastered size of the ISO is relative to the size of the original distribution AND your changes to the system AND the compression method you use HOWEVER note that the actual size of your remaster is a constant as far as the uncompressed data is concerned so the actual (raw size of the operating system data) of your remastered distribution stays the same no matter what compression method you use. Compressing the contents is just an archiving method. XZ compression gives the highest compression ratio but also the slowest compression and decompression times whilst gzip (a very common one) is much faster for compression (but the archiving size is bigger) and decompression. The only benefits these days of using xz compression I can think of are when you have limited space on your storage media (which is extremely rare these days) and when you want to distribute the distribution (for uploading and downloading because the uploading and downloading size will be smaller). In all other cases, xz compression should be avoided because its slowness impacts the actual operational speed of your distribution and that really is the last thing you want. I have repacked all my sfs's in the gzip format. The gzip format is also used in my remaster suites and thus the archived files (but not the actual size of the contents) will be bigger in size than those packed in the xz format. When I first published my suites there were more users options (like selecting different compression methods) but I changed things for simplicity, faster speed and compatibility for older and newer Puppys. Also note that the gzip format is very kind on system resources especially when using older machines. Also - the main purpose of my remaster suites are the remastering of the base sfs (which most existing users would want to do) but also an additional option to make an ISO for those who want to and that ISO option specifically needs manual user intervention for very good reasons, ie: 1. you may not have the original iso anymore so the process will guide you in terms of what is essential to make an ISO even if you do not have the official iso anymore 2. you will have the opportunity to manually add extra things you want to include in the new ISO (like extra sfs's or whatever other data) and 3. You will have the opportunity to manually make changes, for example include a different kernel (zdrv, vmlinuz, fdrv) etc.
I've never commented on this in the past, but I've noticed various confusing comments related to the above in the past. Some posts seemed to suggest Puppy save persistence worked as long as their was an external file, which Puppy calls SAVESPEC, but elsewhere I've read (from gyrog himself, though I can't recall where) that that SAVESPEC file doesn't get read when booting from Ventoy (so won't work with that mechanism) and manual editing of the Ventoy menu is required to put in that PSAVE= parameter instead. Okay SAVESPEC directing is claimed to work with SG2D above, but I'm more interested in Ventoy alone scenario (bare metal booting Ventoy installed usb still and not involving Qemu, the use of which just confuses me further in tests of Ventoy).
Can we at last conclude that is the case, one way or the other, so that users can avoid wasting time trying to get save persistence with Puppy iso booting from Ventoy via any external so-called SAVESPEC file? This seems to have been going on for years. Can we put it to bed and make the final statement about that in whatever is main forum Ventoy thread (assuming there is one)?
I would like to avoid this method since I prefer to install it from the live session then remaster it.
@wizard I understand the script you posted are used for remastering the distro, but how could I Install the kernel in first place ?
Please excuse my late respond ...
Thanks!
@mypuppy2
The kernel files are not actually affected by the remaster process, so you can do it before or after.
Look here for how change kernels:
viewtopic.php?p=78872#p78872
Thanks
wizard
@radky, @Jasper and other interested Puppians,
At long last I have uploaded a redesigned network_connect_update package that integrates support for connman and peasywifi, along with a correspondingly updated simple_network_setup (SNS) package. They are intended for submission to woofCE.
They are attached as versions 20240404-beta and 3.5 to the posting at:
viewtopic.php?p=2241#p2241.
Their change listings are at: viewtopic.php?p=2249#p2249.
Please try them and report any misbehavior by them, to ensure they are ready for woofCE and the next releases of BookwormPup.
I also uploaded frisbee-2.0.2 to use gtk+ 2 when available.
Radky, note that the integration of connman has changed as to the modifications made to the file names. Instead of needing the defaultconnect and .desktop files to be changed to invoke connman as 'connman-gtk.sh', they now use the original 'connman-gtk'. The connectwizard now changes file 'connman-gtk' to 'connman-gtk.sh' at bootup and intercepts invocation of 'connman-gtk' to perform the switch to connman and then execute connman-gtk.sh.
Although the beta version will correct the defaultconnect file, it does not change the connman (Internet Connection Manager) desktop file 'Exec=' line to 'connman-gtk'. The "release" network_connect_update version will assume the correct Exec= line.
The update provides a desktop (menu) file of "Internet Connection Wizard" to distinguish it from "Internet Connection Manager (connman)". (Please consider this as a suggestion that we can change.)
Richard
wiak wrote: ↑Thu Apr 04, 2024 5:10 pmI've never commented on this in the past, but I've noticed various confusing comments related to the above in the past. Some posts seemed to suggest Puppy save persistence worked as long as their was an external file, which Puppy calls SAVESPEC, but elsewhere I've read (from gyrog himself, though I can't recall where) that that SAVESPEC file doesn't get read when booting from Ventoy (so won't work with that mechanism) and manual editing of the Ventoy menu is required to put in that PSAVE= parameter instead. Okay SAVESPEC directing is claimed to work with SG2D above, but I'm more interested in Ventoy alone scenario (bare metal booting Ventoy installed usb still and not involving Qemu, the use of which just confuses me further in tests of Ventoy).
Can we at last conclude that is the case, one way or the other, so that users can avoid wasting time trying to get save persistence with Puppy iso booting from Ventoy via any external so-called SAVESPEC file? This seems to have been going on for years. Can we put it to bed and make the final statement about that in whatever is main forum Ventoy thread (assuming there is one)?
The reason for the dirrerence is:
SG2D uses the grub2 loopback method, (preferred).
Ventoy creates a pseudo CD and uses the 'classic' method.
See viewtopic.php?p=116425#p116425 for more detail.
@rerwin
Thanks for the updates and looking forward to testing these updated applications 
@rerwin
I tested your pet files
OS: BW64-10.0.6. fresh frugal install, onboard ethernet, Wifi dongle TP-Link WN 725N, r8188eu
SNS-3.5 shows r8188eu usb Realtek Wireless Lan Driver, but no WiFi found ("No wireless network found")
The Ethernet connection works.
Right click on the icon in the desktop/tray:
"Disconnect from network" works.
“Reconnect to network” works.
Network Wizard recognizes r8188 module and offers to use it, after selection "yes" WiFi works.
The Ethernet connection works.
Right-clicking on the icon in the desktop/tray partially works:
“Disconnect from network” works.
"Reconnect to network" does not work, message: "Failed to connect to any networks" (/tmp/network-wizard/network-connect.log is empty)
Frisbee 2.0.2:
Wireless Networks: WLAN is not recognized, launching “Diagnostics” does nothing
Network Interfaces: wlan0 is not recognized, eth0 is recognized and works
Right-clicking on the icon in the desktop/tray doesn't work:
Clicking "Disconnect from network" does nothing (the connection remains active).
ConnMan:
Ethernet and wireless works.
Disconnect and reconnect works both in the desktop/tray and in the input mask.
@fr-ke - I tried the bookwormpup 10.0.6 / WN725N combo & found that if I ran: modprobe rtl8xxxu , then removed & replugged in the WN735N, then ran internet connection from menu & restarted wireless, wifi was detected, with standard kernel 6.1.76.
Later kernels (like my 6.7.5 aoum, in forum Kernels section), load the rtl8xxxu driver automatically.
@ozsouth
I tried the bookwormpup 10.0.6 / WN725N combo & found that if I ran: modprobe rtl8xxxu , then removed & replugged in the WN735N
hasn't led to any change for me.
What do you mean by “ran internet connection from menu”.
I get SNS-3.5, Network Wizzard, Frisbee 2.0.2 and ConnMan to choose from.
Just tried out 10.0.6...
After opening a drive, closing it, and reopening it...
Any enlightenment?
@sonny
Thanks for the report.
The free partition space depicted by the bar graphic will be corrected in the next release of BW64.
Sure lack of btrfs file system support is not part of this issue?
.
.
@fr-ke - I ran my tests again today. I used Menu -> Setup -> Internet Connection Manager in all my tests.
In kernel 6.1.76 (original) I realised I had not removed r8188eu , so rtl8xxxu was not operative. I did notice that cfg80211 was not loaded for r8188eu, as I would have expected (ran in terminal: lsmod | grep r8188 ). May contribute to your issue.
In both my kernels 6.7.5 aoum & 6.6.13 aoum, rtl8xxxu was loaded (by the kernel - r8188eu was not loaded), along with cfg80211 & mac80211, & I was able to connect via frisbee (via Menu->Setup->I.C.M.), without any other intervention. Sorry for the confusion.
I think the next bookwormpup will have a 6.6.x kernel, as the usually conservative ChromeOS crostini (based on Debian Bookworm) is up to 6.6.17.
Since PUPs are built from WoofCE and use PUP created kernels and packages, wouldn't one of the latest kernels be a better choice. This is all work within the PUP community layered on top of established distros found "in the wild".
Curious
@ozsouth
I implemented your suggestions on the desktop and a laptop.
I can't make a connection with frisbee.
Neither with frisbee-2.0.1 (see screenshot) nor with frisbee-2.0.2.
In frisbee-2.0.2, as described, the Diagnostics button does not work.
@fr-ke - I think changing the kernel is necessary - I was able to use frisbee once I did that. With the original 6.1.76 kernel, I got same result as you.
@rerwin
Update: Possibly not important, the interfaces eth0 and eth1 are recognized/displayed as Type wireless in frisbee-2.0.2.
This distribution does not run for me on an ntfs partition. Any reason for this?