Discussion, talk and tips
https://forum.puppylinux.com/
@d-pupp
1. Do you have vanilladpup/vanilladpupsave on sda1?
2. Do you have vanilladpup/puppy_vanilladpup_11.0.*.sfs on sda1?
3. pdrv= is unsupported, use pupsfs= (+ read the docs)
@dimkr
1. Do you have vanilladpup/vanilladpupsave on sda1?
Yes All my pups are on sda1 in their own folder
2. Do you have vanilladpup/puppy_vanilladpup_11.0.*.sfs on sda1?
Yes all sfs files and save folders are all together in their folder for each pup
Thanks I'll change pdrv
@dimkr I had done more testing
After changing pdrv=uuid to pupsfs=uuid, dpup 11.0.169 booted without a save folder. It seems init got confused maybe because my first pup on sda1 is dpup 10.0.52 ??
I also tried another test on the menu isssue.
I changed the keyboard shortcut in labwc and didn't change anything in waybar.
I told labwc to read it's config and clicked the menu several times. Of course I didn't get the menu but the altf1 executable still ran. And this time it had no effect on waybar. Everything worked as it should.
So it seems whatever this is that is affecting my system need all 3 elements. IE waybar + altf1 executable + labwc menu opening. Weird??? 
@d-pupp Can you add loglevel=7, then save /tmp/bootinit.log to some partition once boot fails and share this file? I've been unable to reproduce the issue you're seeing.
@dimkr
bootinit.log loglevel 7
@d-pupp Thanks, should be fixed in the next build
Building 11.0.173 right now. If the build succeeds and you update to this version - watch out for boot failures, especially if you haven't set pupsfs= and psave=. (I think I'll add boot time warnings if they're unset, because this activates search on all partitions and slows down boot. I don't see any reason why a user wouldn't want to specify them.)
My misses had an old 2015 Acer Aspire laptop dual-core celeron with Windows 10 that was getting verrrrry slow. It's a bit ram challenged at 2gb. Edit 4 gb of ram. I was using the states off the Website.
I created a usb of dpup 11.0.169 did some research on how to get it to boot and bingo!
It's not dual boot as I had hoped because they are different boot types dpup is legacy and MS is uefi secure boot.
I could not mount the ntsf partition because it's dirty even after running chkdsk from Windows. 
I'll leave it for now as I have copied all her files onto the usb key anyways.
dpup recognized all the hardware and worked OOTB
CPU and RAM use are low and the speed it good. She really like the boot time of less than 1 min. compared to Windowzzzzzzzzzzz.
She has never used Linus before. It could be fun. 
@dimkr I have a request. A /root/bin folder. I think it would be handy for a lot of people to keep their scripts organized. What do you think?
Why add a new directory instead of using the standard ~/.local/bin?
I don't see a ~/.local/bin in $PATH or Spacefm?
It doesn't exist by default, you can create
Ah I think we got our wires crossed here. That was my original question... Would you be willing to make ~/bin or ~/.local/bin part of the default path on dpup 11? I think it would be useful to a lot of people. Especially newbies that don't know how to set it up. Your opinion?
@d-pupp By default - no. This is a good place to hide malware: for example, an executable with the same name as your browser. IMO users that want to place executables in their home directory rather than /usr/bin, /usr/sbin, etc' should configure things themselves. I prefer not to risk users that don't use this.
@dimkr That makes sense. Thanks for explaining it to me. I never thought about malware.
@dimkr I just updated to dpup 11.0.174 and it booted ok without a save folder even with pdrv set instead of pupsfs. Looks like the fix worked.
Warning to those installing 11.0.177 (not released yet): this one contains very big changes. It moves the vast majority of files that don't come from Debian packages from /usr to /usr/local (making it even closer to stock Debian) and drops the apt-mark hold for all preinstalled pacakges. This means that apt upgrade is free to upgrade packages without you having to apt-mark unhold them first, or update to a newer build where all dependencies are updated. In addition, dpkg -V output should be very clean, making it actually useful for troubleshooting or auditing.
In other words, 11.0.177 is going to allow Debian updates out of the box, and users who liked the previous behavior can just apt-mark hold all preinstalled packages. (Users who upgrade from previous builds still have held packages.)
We are witnessing a step-stone change in the puppy's history. We live in exciting time. Thank you @dimkr .
Warning to those installing 11.0.177 (not released yet): this one contains very big changes. It moves the vast majority of files that don't come from Debian packages from /usr to /usr/local
@dimkr With this change would it be wise to create a new save folder when updating to 11.0.77?
Only if you're unsure how to handle this transition, you don't have to. Personally, I'm going to update - I can disable the held packages inherited from 11.0.76 later if I want.
@dimkr I kinda like this change. As I look into your reasoning and how the Linux file system is setup it makes a lot of sense to have seperation between what the package manager handles and what it doesn't. Less chance the package manager will break something. Easier to figure out what part of the OS and what's not and more use of the package manager tools.
I suppose you could also use dpup 2 ways.
1 as a regular Debian like puppy running along side other versions and updated by replacing files in the frugal install.
2 or as a puppy version of Debian. Single install and updated by apt-get
I have 2 version of dpup11 running now. My daily driver and a stock version with no save folder. I'll test it both ways.
It's still not perfect because apt upgrade won't upgrade the kernel. I'm still not sure how to handle this, I have several ideas with pros and cons, but all of them require the user to configure something (extra boot codes or a configuration file), use Bootflash (which configures everything correctly) of just use the prebuilt images (which are built using Bootflash).
Using the stock Debian kernel is not an option because it won't work in a Puppy-like setting (no built-in drivers) and doesn't have the configuration tweaks to reduce RAM consumption, but I also don't want to set up a package repo and deal with the mess of signing packages and keeping the infrastructure secure.
3 last-minute changes before 11.0.177:
Automatic cleanup of files spilled from SFSs to the save file/folder, on update or addition/removal of a SFS loaded at boot time; this should allow users to apt upgrade on 11.0.177, then update to 11.0.178 and this mechanism will clean up the save from files (like updated libraries) that have copies inside the 11.0.178 SFSs
Automatic cleanup of whiteout files when the SFS stack changes, to avoid surprises like a file that refuses to appear but cannot be un-deleted
Fix for auto-configured IPv6 addresses, which broke IPv6 connectivity for me and I haven't noticed this until today
11.0.178 will add ~/.local/bin and move the run-as-spot wrappers creates by setup-spot to this directory. This is something I missed when I moved packages built from source from /usr to /usr/local: they cannot be configured to run as spot if both the executable and the wrapper want to be in /usr/local/bin with the same basename.
I tried dpup 11.0.177 installed in a HD, in an ARM machine under qemu emulation! (so I can get the wl/dkms packages I need for another machine)
It boots fast and is responsive under the correct display driver (virtio-ramfb-gl GPU supported). Gets to Desktop in 35 sec and populates it in 40 sec. For a classic puppy comparison Bookwormpup needs 90 sec for Desktop and 120 to be fully functional. 3 times as much!
Dpup177 even beats FatDog (with small initrd) that in the same VM gets to ROX desktop in 27 seconds, in 35 seconds has the 4 hard disk show and 50sec the menu is fully populated and functional.
If you do not need all the other things/options that classic puppy tries to do/offer this is clearly the way to go
Well done.
Latter: In the 10-year old i7 laptop with SSD it boots in 21 sec to a fully functional desktop
@dimkr One problem I noticed is that now the wdisplay setting changing apparent screen resolution, is not preserved through reboots.
This was not the case (up to 170 that was present in this machine)
Posting form dpup 11.0.178
I have only been using it for a few hours but it's working good.
I booted the stock install with no save folder first no issues to report there
I then booted my daily driver. I noticed a message scrubbing save folder on boot up. I did loose a few setting mostly in my browser. So anyone updating to 11.0.178 make sure you have your bookmarks saved someplace first.
From a user prospective there is no difference
Looking good @dimkr
Here is the output of dpkg -V
Code: Select all
root@puppypc:~# dpkg -V
missing /var/lib/apt/lists/partial
??5?????? c /etc/locale.alias
??5?????? c /etc/bluetooth/main.conf
??5?????? c /etc/connman/main.conf
??5?????? c /etc/issue
??5?????? c /etc/nscd.conf
retiredt00 wrote: ↑Wed Sep 11, 2024 10:17 am@dimkr One problem I noticed is that now the
wdisplaysetting changing apparent screen resolution, is not preserved through reboots.
This was not the case (up to 170 that was present in this machine)
Thanks for reporting, should be fixed in 11.0.179
Testing apt in 11.0.178
Get:29 http://deb.debian.org/debian trixie/non-free-firmware Icons (64x64) [29 B]
Get:30 http://deb.debian.org/debian trixie/non-free-firmware all Contents (deb) [23.4 kB]
Get:31 http://deb.debian.org/debian trixie/non-free-firmware amd64 Contents (deb) [1,093 B]
Fetched 79.8 MB in 58s (1,383 kB/s)
11 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@puppypc:~# apt list --upgradable
gsettings-desktop-schemas/testing 47~rc-1 all [upgradable from: 47~beta-1]
libegl-mesa0/testing 24.2.2-1 amd64 [upgradable from: 24.1.3-2]
libgbm1/testing 24.2.2-1 amd64 [upgradable from: 24.1.3-2]
libgl1-mesa-dri/testing 24.2.2-1 amd64 [upgradable from: 24.1.3-2]
libglapi-mesa/testing 24.2.2-1 amd64 [upgradable from: 24.1.3-2]
libglx-mesa0/testing 24.2.2-1 amd64 [upgradable from: 24.1.3-2]
liburi-perl/testing 5.29-1 all [upgradable from: 5.28-1]
libwireplumber-0.5-0/testing 0.5.6-1 amd64 [upgradable from: 0.5.5-1]
mesa-va-drivers/testing 24.2.2-1 amd64 [upgradable from: 24.1.3-2]
mesa-vulkan-drivers/testing 24.2.2-1 amd64 [upgradable from: 24.1.3-2]
wireplumber/testing 0.5.6-1 amd64 [upgradable from: 0.5.5-1]
Sorry I didn't document the rest of the upgrade
It running well after the upgrade. Save folder size is not 49 MB
output of dpkg -V
Code: Select all
??5?????? c /etc/locale.alias
??5?????? c /etc/bluetooth/main.conf
??5?????? c /etc/connman/main.conf
??5?????? c /etc/issue
??5?????? c /etc/nscd.conf
I tried 181, which it would appear it is using erofs for the SFSs. If I understand correctly it provides faster and aligned reads being nicer to the drives with the cost of increased size over squashfs.
Booting from my old laptop (2GHz i7 with SSD) did noticed maybe marginally faster boot (less than a second if such a claim can be done with stopwatch). And nothing noticeable with applications, though I did not checked formally.
I guess will be different when booting from a USB stick or in a slower machine.
Another "issue" for now that erofs is not supported by other puppy/puppylike kernels, is that you can not mount the erofs SFSs in other puppies. Even in the previous dpup version, but I guess this will by fixed in new kernel builds.
The puppy scripts should also be amended since they do not know what to do with these sfs (including the ones in 181)
BTW mounting squashfs SFSs by clicking in the file manager works as expected, but unmounting them fails. ie nothing happens when you click on an SFS file that is already mounted
One other thing I find annoying is that all the windows open from the top covering the bar you have to always reposition them.
Even if you set the bar to be on top is still not very usable as is blurred with the application window.
I can understand this may be a further down development issue, but if anything can be done with the bar would be nice.
retiredt00 wrote: ↑Sat Sep 21, 2024 8:11 amBooting from my old laptop (2GHz i7 with SSD) did noticed maybe marginally faster boot (less than a second if such a claim can be done with stopwatch). And nothing noticeable with applications, though I did not checked formally.
Currently the SFSs are lz4hc-compresed so you won't feel any difference with most SSD because decompression happens at RAM speeds. I'm working on switching to zstd.
EDIT: done and rebuilt 11.0.181 with zstd
retiredt00 wrote: ↑Sat Sep 21, 2024 8:11 amI guess will be different when booting from a USB stick or in a slower machine.
Exactly. If the data is compressed, there's less data to read from a slow drive, so if decompression is fast (lz4 or zstd) the total time it takes to read and decompress should be shorter than the time it takes to read the amount of data from the same drive, without compression.
retiredt00 wrote: ↑Sat Sep 21, 2024 8:11 amAnother "issue" for now that erofs is not supported by other puppy/puppylike kernels, is that you can not mount the erofs SFSs in other puppies. Even in the previous dpup version, but I guess this will by fixed in new kernel builds.
Have you tried this? My dpup builds are all with CONFIG_EROFS_FS=m, so you should be able to mount erofs images. All kernels that support erofs should support lz4 compression, so I don't think it should be a problem. If you're using a Puppy with a 6.1.x kernel, it should support all erofs features in use.
retiredt00 wrote: ↑Sat Sep 21, 2024 8:11 amThe puppy scripts should also be amended since they do not know what to do with these sfs (including the ones in 181)
Which scripts? The only script that needed adjustment is sfs_load (search all files in https://github.com/vanilla-dpup/woof-CE for "squashfs").