Hope this brings insight.
As I understand it pupmode 5 and 13 are mostly the same thing
Both run in ram
The only real difference is that pupmode 13 loads you save file or folder and pupmode 5 runs the quick setup script
Moderator: Forum moderators
Hope this brings insight.
As I understand it pupmode 5 and 13 are mostly the same thing
Both run in ram
The only real difference is that pupmode 13 loads you save file or folder and pupmode 5 runs the quick setup script
d-pupp wrote: Sun Oct 22, 2023 2:39 pmHope this brings insight.
As I understand it pupmode 5 and 13 are mostly the same thing
Both run in ram
The only real difference is that pupmode 13 loads you save file or folder and pupmode 5 runs the quick setup script
Almost. For a 'layman's' understanding of the various PupModes see, https://www.forum.puppylinux.com/viewto ... 183#p97183
The post mentions using Save2SFS to create/modify adrv.sfs or ydrv.sfs. Under Bookworm I use these to include applications and/or their libraries apt/synaptic can't or I don't want apt/synaptic to manage. But an adrv or ydrv will also hold the settings and configurations you establish running the quick setup script. Adrvs and ydrvs are automatically copied into RAM on boot-up. So once you've created or modified an adrv &/or ydrv you can boot-up with your settings, configurations, without having to mount a SaveFile/Folder: that is, still operate under PupMode 5.
How Puppy works
http://bkhome.org/archive/puppylinux/de ... works.html
This explains different pupmode operation.
What causes the Quick setup to run is booting and not loading a save file/folder.
If there is no loaded save file/folder, there are no previous settings to use, so you have to make them.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
On bootup Puppys looks for 'a flag' at (I believe) /var/local. Not finding it, first-run setup is run and such flag written. If you shut-down without creating a SaveFile/Folder or creating or modifying an adrv.sfs or ydrv.sfs, the flag is not preserved and won't be found on boot-up. Once you've created a SaveFile/Folder or created or edited adrv.sfs or ydrv.sfs, the flag is preserved, f9und on boot-up and first-run setup is not run.
As BookWormPUP64 cmtinues to navigate to its next version, could QEMU v8 be made available in its Repo?
Looking forward: Reviewing these PETs in the repository
@666philb created some useful utitlities in FossaPUP64.
I recognize that BookwormPUP64 (BKW64) is a different PUP with different kernel and etc. ... yet I was wondering if there might be a similar utility in BKW64 like this from FossaPUP64 for nvidia driver assistance?
No.
And read this topic I posted about me trying to get a Nvidia driver installed and used.
viewtopic.php?t=8714
Still have not been able to get it working.
.
.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
@radky - works well. Only issue I had was cpu temp - shows contents of /sys/class/hwmon/hwmon0/temp1_input. When I modprobed coretemp driver on my pc, it used hwmon5 (?!) subfolder. I made a more compressed CD version (669mb) to release later.
I see some new Puppy reviews in YouTube, and they all grab Fossapup without checking the other options because that's what's featured in puppylinux.com. Maybe it's time to consider putting Bookworm Pup64 there and finally dethrone a Puppy with <=2020 tech.
dimkr wrote: Wed Nov 01, 2023 11:10 amI see some new Puppy reviews in YouTube, and they all grab Fossapup without checking the other options because that's what's featured in puppylinux.com. Maybe it's time to consider putting Bookworm Pup64 there and finally dethrone a Puppy with <=2020 tech.
I have been advocating for this for a while now. It makes sense to have Bookworm Pup64 featured as the main Puppy Linux and let it replace Fossapup.
Sooner than later I would think.....
I don't think I can directly modify the GitHub page that renders puppylinux.com
I can do this but I don't want to step on @peebee's toes. He's the de facto maintainer of https://github.com/puppylinux-woof-CE/p ... .github.io and the one who can edit table the "download" page points to since https://github.com/puppylinux-woof-CE/p ... 50d1842ffe, so he's the sole judge when it comes to "official" or not.
Not that I'm aware of.......
but I agree that BW64 should become the next official Puppy release ........... but @radky must be happy for that to happen.
Another small fly in the ointment is that BW64 is not fully Github Woof-CE buildable as it relies on local tweaks (quite a few).
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
peebee wrote: Wed Nov 01, 2023 5:08 pmAnother small fly in the ointment is that BW64 is not fully Github Woof-CE buildable as it relies on local tweaks (quite a few).
So do Fossapup and Bionicpip, yet they're featured at the top of puppylinux.com.
dimkr wrote: Wed Nov 01, 2023 5:28 pmSo do Fossapup and Bionicpip, yet they're featured at the top of puppylinux.com.
Indeed - but they sort of preceded your efforts to get everything maintained on Github to remove dependence on local builds as much as possible.
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
In my ISO file boot tests, this PUP, once at desktop, performs VERY well. Thanks @radky and @rockedge for all of the hard work to move this to feature-rich, quick performance and stable (most importantly).
QEMU, SG2D, and ISO booter all work without issue. But, I have discovered that it appear, externally at least, that this WoofCE generation is discriminating on Ventoy. I may be wrong, but, I can supply info that development may want to see, if there is interest. I also have the debugsave folder if interest exist.
Although it is all to simple to replicate the problem with a simple Ventoy disk. Make a folder on it named "BOOTISOS', add this ISO file, and boot the USB to see the problem. If you, also, add the SG2D ISO/IMG file, booting it from Ventoy, then launching BKW64 from SG2D's list, you get to the desktop without any issues...no matter which BKW64 Menu stanza one selects.
Since the world has seen an enormous growth in use of Ventoy to launch ISO files to desktop across the Linux spectrum, the WoofCE distro 'may' want to review so they know what users see when booting.
I recognize that the DOGs and KL do not have the problem seen with recent WoofCE distros as it pertains to being launched from any of the boot launchers, thus, those like many/most distrowatch ISO files the DOGs and KLs boot without any issues no matter which launcher is used.
There are currently 2 WoofCE distro that dont have a launch to desktop problem: @wizard's Friendly ISO file and the ISO files from @01micko Slacko's before he left. Other WoofCE's ISO files since have acquired some change(s) that discriminates and leads to the issue seen ONLY from the 1 launcher, Ventoy.
@radky THANKS for what you have done with this fabulous work and your (@rockedge too) attention to detail. thus far!
P.S. Save sessions work and continue to work as expected with NO NEED to edit ANY BKW64 boot stanzas THANKS to the work of @gyrog which automates this when SAVESPEC file is present in the boot folder. Thus from desktop start to finish, BKW64 is a dream with little to no user attention needed or paid from boot to shutdown.
Edit: Do not be fooled into 'thinking' that this is a request to support Ventoy...IT IS NOT! My comments are about what is seen in testing when a forum distro's ISO file is launched via tools that intend productivity and reduction in user efforts. QEMU. SG2D. ISObooter, Ventoy offer simple facilities launching to a functioning distro, directly OOTB, from the distro ISO file. What I present is merely observations, results and reports.
At least present BWpup more officially as release candidate to replace Fossapup ?
A fully functional LXDE/PCManFM SFS (with drives-on-desktop) might pry me off Fossapup. I run both BW64 10.0.3 and @ozsouths' Fossa64 - Less v1 currently but none of my 'users' are ROX/JWM ready yet. The LXDE/PCManFM combo is a much easier transition from (excuse me) windows-land for them. I haven't gotten that WM/FM with drives-on-desktop viable in BW64 as yet though my attempt was a bit ago now.
My pups: LxPupSc64 and Voidpup64 with LXDE ydrv and synaptics touchpad drivers, both using small savefiles for customizations. Ydrv based NoblePup64 and Fossapup64-small (both LXDE/PCManFM with no savefiles). No fdrvs throughout.
If someone is going to add Bookworm64 to puppylinux.com perhaps they could update one or two other things while they're at it, such as, under Puppy Linux Advantage:
2. Ease of use - Grandpa friendly certified. Not convinced everyone would agree with that.
3. Relatively small size - 300Mb or less. Er, since when? More recent Puppies are way over that.
Also under Puppy Linux Team, the list of Puppy "Stewards". There are a few names there that I haven't seen mentioned anywhere in a very long time, are they all still involved?
Just a thought, for what it's worth.
@rerwin
Thanks for updating and supporting the legacy Connect Wizard utilities (sns, frisbee and network wizard).
For switching to/from ConnMan and legacy Connect Wizard utilities, BW64 also provides Menu -> Setup -> Internet Connection Switcher, which automatically adjusts the requisite exe and rc files.
If the user switches to legacy Connect Wizard utilities, it may be necessary to temporarily disable the firewall before connecting via SNS or Frisbee.
Thanks again Richard, your contributions are very much appreciated !
Marv wrote: Wed Nov 01, 2023 7:54 pmA fully functional LXDE/PCManFM SFS (with drives-on-desktop) might pry me off Fossapup. I run both BW64 10.0.3 and @ozsouths' Fossa64 - Less v1 currently but none of my 'users' are ROX/JWM ready yet. The LXDE/PCManFM combo is a much easier transition from (excuse me) windows-land for themgress. I haven't gotten that WM/FM with drives-on-desktop viable in BW64 as yet though my attempt was a bit ago now.
I'm trying xfce from the package manager instead of LXDE. Needs a wm-switcher to clear jwm and start xfce. Hoping I can use the script from another puppy. L A work in progress. Any suggestions welcome.
To install Xfce:
Code: Select all
apt update
apt install xfce4
echo false > /etc/desktop_app
echo xfce4-session > /etc/windowmanager
To install KDE:
Code: Select all
apt update
apt install plasma-workspace
echo false > /etc/desktop_app
echo startplasma-x11 > /etc/windowmanager
To install LXDE (with openbox and without extra applications, only pcmanfm and lxpanel)
Code: Select all
apt update
apt install openbox-lxde-session pcmanfm lxpanel
echo pcmanfm > /etc/desktop_app
echo lxsession > /etc/windowmanager
LXDE by ydrv:
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
I made a more compressed version of BookwormPup64 10.0.3, to fit on a CD (is 669mb).
Withdrawn - v10.0.4 CD version posted later (27Dec23).
Also, I made a simple cpu core 0 temperature checker .pet (see below).
Uses pupsysinfo basics to get temperature & puts an item in Utility menu.
Install by clicking on it in ROX-Filer. Use at own risk.
.
Geek3579 wrote: Thu Nov 02, 2023 5:00 amMarv wrote: Wed Nov 01, 2023 7:54 pmA fully functional LXDE/PCManFM SFS (with drives-on-desktop) might pry me off Fossapup. I run both BW64 10.0.3 and @ozsouths' Fossa64 - Less v1 currently but none of my 'users' are ROX/JWM ready yet. The LXDE/PCManFM combo is a much easier transition from (excuse me) windows-land for themgress. I haven't gotten that WM/FM with drives-on-desktop viable in BW64 as yet though my attempt was a bit ago now.
I'm trying xfce from the package manager instead of LXDE. Needs a wm-switcher to clear jwm and start xfce. Hoping I can use the script from another puppy. L A work in progress. Any suggestions welcome.
---------------------------------
KL
PUPPY LINUX Simple fast free
Thanks, that SFS works well. I have added my portable .desktops, symlinks, panel layout and drives on desktop from a pet (desktop_drive_icons_x86_64-0.0.5.pet), maybe not the latest but it works. Even without that, the PCManFM in your ydrv handled the boot and data partitions well enough to suffice. So far I have my adds in a savefile but I'll roll them into the ydrv next. I'll use this as my daily now but so far GREAT.
Thanks,
My pups: LxPupSc64 and Voidpup64 with LXDE ydrv and synaptics touchpad drivers, both using small savefiles for customizations. Ydrv based NoblePup64 and Fossapup64-small (both LXDE/PCManFM with no savefiles). No fdrvs throughout.
To a large extent I think the problems I'm experiencing have to do with Fios's premature deployment of 5G and insistence that it be used. 5G carries more data, but uses more resources than its predecessor making it more 'finicky'. I am constantly plagued with 'loss of signal'. That said, I don't recall having as much difficulty under Bookworm 10.0.1 as under 10.0.3. [I skipped 10.0.2].
Conman quickly finds my wifi. But it also more frequently looses it and when it does, nothing short of a reboot will enable reconnecting. [And as I've mentioned a couple of times, Conman needs a better GUI. With a 12+ digit security code, you have to know if the problem connecting is a scrivener's error].
Which brings me to the traditional 3: The best of those on my system --fewest loss of connections: don't ask me why-- is Network Connection Wizard. But it's GUI needs adjustment. Without regard for what I set my Screen Resolution at, I have to 'maximize-y' to see its controls.
Simple Network Setup does not connect at all. Attached is the combined SNS log and retry-log. Remove the false '.gz'.
This time around --the 3rd-- I was able to setup a connection using frisbee. But, from experience, frisbee looses the signal more often than the Wifi Connection Wizard.
Thanks for reporting about SNS.
I see as suspicious:
dhcpcd_fork_cb: truncated read 0 (expected 4)
and conclude that dhcpcd fails in some way.
But I don't know where to go from there. Nothing useful pops up when I search about it.
I am not concerned about the note:
Note: nl80211 driver interface is not designed to be used with ap_scan=2; this can result in connection failures
because SNS tries all of the possibilities (0,1,2).
There might be a clue in the config file:
/etc/simple_network_setup/wpa_supplicant.conf-Verizon_PR3BMH-00:18:4d:f9:86:23
What do you see there?
Edit: Another approach would be to try fossapup64_9.6CE, using the Internet Connection Switcher. If the default SNS 3.3.1 works for your setup, try installing SNS 3.4 there to see whether it works for you, too. If both fail, try SNS 2.4.2, which has the old internal structure.
Richard
Bookworm Pup64 (BKW64) Team: Thanks
On my end all your improvements are performing well in my initial tests on an Intel x86-64 with Intel motherboard VGA video beyond what was occurring in v1002.
Add'l Benefits in v1003 observed
Users can now boot the ISO file directly from Ventoy launch as well as all prior ISO file booting reported
findsmb, hardinfo upgrade, btop, tldr useful utilities works
polished screenings, exFAT, filesystems, ...
Problem
A problem that I dont know of a OS method to address: How to implement a 'physical' remove and re-insertion command (or system utility) for a unmounted USB device
Scenario
When the system is booted, the launched PUP "locks" to boot device such that it cannot be mounted (or used) by the running system. I tried the following to no avail using cli commands
'lsblk" exposes the problem showing the boot stick identifying the location even though its unmounted and cannot be mounted
'udevadm trigger --action=remove /dev/bus/usb/bus-number/device-number' will remove it from on-screen
yet 'lsblk' still shows it connected ???
'udevadm trigger --action=add /dev/bus/usb/bus-number/device-number' will place it back on-screen in exactly the same position /dev/sdbn as before and the inability to mount/use the partition remains.
Circumvention
Still the ONLY way I know currently to 'fix' this problem is to physically unplug this unmounted device and plug it back in.
Question
Is there any CLI command sequence to fix this without having to reach over to pull it out, then, stick it back in?