Vanilla Upup 22.04.61

[dimkr]

This is a basic x86_64 Puppy built using Ubuntu 22.04 packages.

It's not intended to replace any other Puppy: the goal is to build a solid and efficient, "unofficial" barebones Puppy with good apt support and without legacy cruft.

Download ISO here

jammy64.png (272.67 KiB) Viewed 14156 times

This is similar to Vanilla Dpup, but more barebones and more like a traditional Puppy release.

Major features:
1) Supports apt-get and Synaptic, with the 32-bit repo (where you can find Steam and Wine) pre-configured, automatic menu refresh on package installation or removal, and support for automatically setting problematic applications to run as spot
2) Uses an Ubuntu-like directory layout - /bin, /sbin, /lib and /lib64 are symlinks to their counterparts under /usr, making it incompatible with some old Puppy packages
3) Uses overlay instead of aufs, for extra stability and great performance with PUPMODE 13; sfs_load works but SFSs can be loaded only at boot time
4) Built from Ubuntu packages and packages built from source; nothing is prebuilt, the entire process is automated and reproducible
5) Uses a huge 5.15.x kernel with lots of drivers (almost identical to the Ubuntu kernel) and installation of non-free drivers (i.e. apt install nvidia-driver-510) should work out-of-the-box
6) Comes as a traditional ISO image (with UEFI support, using Ubuntu's boot loader)
7) Uses PulseAudio PipeWire for audio, like Ubuntu 22.04: pavucontrol and Blueman work just fine, even for applications running as spot
8) Uses ConnMan, connman-ui and connman-gtk for network management
9) Comes with Netsurf, a basic browser you can use to look up documentation online, and (hopefully) use to download the large browser of your choice
10) Everything uses GTK+ 3 and ROX-Filer is replaced with PCManFM; the built-in themes support both GTK+ 2 and GTK+ 3
11) Uses a patched version of the dwl Wayland compositor, running a fullscreen Xwayland in kiosk mode
12) The terminal supports command-line completion, man pages and missing package recommendations
13) Useful keyboard shortcuts
14) Some things that traditionally don't work in Puppy, including Flatpak (partially), Podman, Buildah and bpftrace, work fine
15) Enough built-in fonts to make websites and emojis render correctly

[mikeslr]

I haven't gotten very far in exploring Vanilla Upup 22. I'll probably wait until problem (1) is resolved.

(1) It hangs on shut-down. After making some basic changes --e.g. configure wifi-- I shut-down, creating a SaveFolder. The SaveFolder was successfully created and, on reboot, my settings had been preserved. But both on initial shut-down after creating the Save and on shut-down following a reboot the terminal was filled displaying activity but reboot stopped. To regain control of the computer I had to unplug the power source. I don't want to do that often.
If it helps, I'll boot into Van-upup again and try to hand-write the last few lines displayed by the terminal on shut-down.

(2) No AppImages work, nor 'portables' if they are merely AppImages with a wrapper both enclosed in a folder. Attempts via a terminal displayed something about 'fuse' being required. IMHO, the ability to run AppImages is essential for modern Puppys. We don't really have the 'staff' to produce every application likely to be commonly desired.

If setting up 'fuse' is to be a 'User's choice', what is the command/procedure to do so?

(3) The module for adding launchers to panels is broken. Launchers can be added. But new Launchers can not be relocated from the end/bottom to anywhere else. The GUI shows they are moved. But 'Apply' doesn't change the display of their location on a panel.

[darry19662018]

I haven't gotten very far in exploring Vanilla Upup 22. I'll probably wait until problem (1) is resolved.

(1) It hangs on shut-down. After making some basic changes --e.g. configure wifi-- I shut-down, creating a SaveFolder. The SaveFolder was successfully created and, on reboot, my settings had been preserved. But both on initial shut-down after creating the Save and on shut-down following a reboot the terminal was filled displaying activity but reboot stopped. To regain control of the computer I had to unplug the power source. I don't want to do that often.

Had same problem Mike on my Compaq CQ61

[dimkr]

(1) It hangs on shut-down.

If it's what I think it is - it's an aufs bug that affects all 5.15.x+ kernels. Will be fixed soon, I hope. As a contingency plan, I'm working on overlayfs support in initrd.gz.

If setting up 'fuse' is to be a 'User's choice', what is the command/procedure to do so?

You have 3 options.

1 - use PPM, as you normally would

2 - use Synaptic

3 - apt update && apt install fuse

(3) The module for adding launchers to panels is broken. Launchers can be added. But new Launchers can not be relocated from the end/bottom to anywhere else. The GUI shows they are moved. But 'Apply' doesn't change the display of their location on a panel.

I guess it's broken

EDIT: @mikeslr, can you upload a screenshot of this launcher GUI thing? I want to make sure I'm looking at the right piece of code.

[mikeslr]

I've attached a screenshot taken immediately after boot-up. It shows both the GUI and placement of Launchers on the Right-side. I habitually move launchers relating to applications I frequently use (or may want to use ASAP) to the Left-Side* leaving only Launchers relating to providing info on the Right-Side. Accordingly, the Launchers for 'Show-Desktop', Default File-Manager, Default Web-Browser and Screenshot should be on the Left. Before shut-down/reboot the GUI showed that they had been moved to the Top of ITS panel while the display continued to show them on the Right of the Tray.

Not shown in the Screenshot is the 'intelligently' hidden panel on the Right-edge*. I'm pretty sure I got around to relocating Launchers from the order in which they were added (alphabetically while scrolling) to the pattern I always use (Word and number-crunchers at the Top); but that they remained in the order selected (Last selected at the bottom).

Screenshot.png (70.52 KiB) Viewed 14694 times

--=-=--=-=-=-
* I delete all desktop launchers, placing launchers for commonly opened (or instantly desired) applications in proximity to the Left-bottom corner. 'Muscle-memory' replaces both having to think about 'What do I have to do to open such applications?' and/or scrolling thru JWM's Menu labyrinth.

p.s. Thanks for the instructions regarding fuse. Is there any reason for it not being a builtin?

FYI: The computer is a OptiPlex 9010, Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, employing Intel Xeon E3-1200 v2/3rd graphics.

[dimkr]

p.s. Thanks for the instructions regarding fuse. Is there any reason for it not being a builtin?

Nothing in the ISO depends on it, and it will get installed if you apt install something that needs it.

If you use some other package format, like AppImage, you're on your own, and you'll need to install those dependencies first. Other Puppy family distros you've been using happen to have fuse built-in, for their own reasons.

(I might publish a slightly bigger and more traditional flavor in addition to this super barebones one, with ROX-Filer and friends.)

[pcplague]

What problems did you had with PipeWire ?

[dimkr]

What problems did you had with PipeWire ?

It worked perfectly!

Ubuntu 22.04 sticks with PulseAudio, so I decided to go that way too. The difference in size and RAM consumption was negligible.

[mikeslr]

One step forward, one step back.

I swapped in ozsouth's 5.15.27 fsctx fixed kernel (vmlinuz and accompanying drivers) viewtopic.php?p=52020#p52020. Vanilla Upup booted and (importantly) shut down cleanly. [Well, almost: on boot-up there was a notice that zram failed].
But the step back was that Vanilla Upup no longer recognized my wifi. The original vmlinuz and zdrv.sfs did. I was hoping it was a firmware problem. But neither using the original firmware sfs nor two others (which other Puppys found satisfactory) helped.

I'll test oz's kernel under a different Puppy. But I suspect it's not a driver problem but rather a mismatch between Vanilla Upup and 'regular' Puppy kernels. And no, it's not a problem with the wifi module Vanilla Upup uses. With the built-in wifi module now being unresponsive I installed the latest versions of radky's frisbee, network wizard and Simple Network Setup to no avail. All ran; none saw a network.

Edit-Update: I just copied the above specified kernel package by ozsouth into xenialpup64; that is the vmlinuz, zdrv and fdrv which I had used under vanilla Upup; merely renaming the last two. Xenialpup64 booted and wifi works. I'm posting from it now.

[dimkr]

@mikeslr Can you share the output of dmesg? It's probably missing firmware, beta4 uses the standard 5.15.x kernel used by other woof-CE builds.

EDIT: I think I know what happened, it's not related to firmware. Vanilla Upup uses an Ubuntu-like file system layout, where /lib is a symlink to /usr/lib. You can't just swap in any kernel package, because kernel packages that put the modules in /lib/modules won't work - all module loading, including zram and wifi, will just fail.

[mikeslr]

@mikeslr Can you share the output of dmesg? It's probably missing firmware, beta4 uses the standard 5.15.x kernel used by other woof-CE builds.

EDIT: I think I know what happened, it's not related to firmware. Vanilla Upup uses an Ubuntu-like file system layout, where /lib is a symlink to /usr/lib. You can't just swap in any kernel package, because kernel packages that put the modules in /lib/modules won't work - all module loading, including zram and wifi, will just fail.

I think you're right. But I'm kind-of busy today. Will look into this tomorrow, both by running dmesg and by rebuilding fdrv & zdrv sfses after examining the upup's originals. Is rebuilding both necessary?

Long term issue: Given how Ubuntu now packages debs, shouldn't that be handled by woof? Or would that screw-up Slackos?

I am reminded of the situation encountered when using PaDS to create 64-bit SFSes from Ubuntu debs. PaDS worked fine with all 32-bit puppys as they only used /lib, usr/lib and /usr/local/lib folders. And it worked fine under Slackos which placed 64-bit libs and firmware under /lib64, /usr/lib64 and /usr/local/lib64 folders. But ubuntu had located its 64-bit libraries under comparable folders albeit named something like ...x86_64-linux-gnu. Ubuntu-binary-compatible Puppys could not find those folders. After building SFSes using PaDS I had to mount those SFSes, copy their contents into a folder, move the libraries to .../lib and dir2sfs. Taersh eventually modified PaDS to automatically handle the problem. viewtopic.php?p=6355#p6355
The thing is that while exploring the problem I discovered and reported that even Ubuntu/debian Puppys found libs if they were located in folders named /lib64 etc. But no one having woof influence ever followed up on that.

Which leads me to wonder: Although PaDS was designed to decompress multiple files then reassemble them outputting one SFS --I think I once started with 86 debs-- it can work with just one package. Might see what running fdrv.sfs and zdrv.sfs thru it will do.

Some universal solution would be preferable to having to maintain two species of zdrvs and fdrvs.

[dimkr]

Is rebuilding both necessary?

Any package (.pet, .deb, .sfs, whatever) where /bin, /sbin, /lib or /lib64 is a directory, is likely to be broken or even break your system. SFSs are especially dangerous, because by replacing /lib with a directory, they may hide sub-directories - for example, a zdrv SFS that replaces /lib with a directory that contains just /lib/modules, hides the /lib/firmware in fdrv.

Long term issue: Given how Ubuntu now packages debs, shouldn't that be handled by woof? Or would that screw-up Slackos?

woof-CE and kernel-kit support both directory layouts, the traditional one (used in Puppy until now, and still in use in Slackware), and the "/usr merge" (>= 2018?) one. kernel-kit produces two variants of each kernel package, because the only way to fix this at runtime is to modify SFSs in memory, and that's costly.

It is possible to use the old style directory layout in Vanilla Upup (it's a woof-CE configuration parameter), but that will break many Ubuntu packages, or break packages that work on Ubuntu. I think it's safe to assume most users will do most of their package management with apt (rather than, .pet or .sfs). It's a trade-off between backward-compatibility with some Puppy-specific packages, or much better Ubuntu compatibility.

[mikeslr]

As it nagged me and I had a couple minutes before I have to run, I tried the easy ways: (a) just renaming in oz's fdrv & zdrv lib folders to lib64 and repackaging and (b) running them thru PaDS. Neither resulted in functional wifi; and booting up reported zram failed. Might just be directives in vanilla upups boot folder. I know nothing about that.

Tomorrow I'll see what manually restructuring oz's sfses might disclose.

But if and when you get a chance, maybe find out why oz's kernel doesn't generate the shut-down problem.

[rockedge]

@dimkr There is a similar situation with KLV and Puppy Linux kernels. In the fdrv (firmware) the usual structure is /lib. But KLV (Void Linux) needs /usr/lib. At this point of testing I am building kernels with the kernel-kit and then modifying the fdrv SFS. I have success by making the firmware SFS look like /lib/firmware and also /usr/lib/firmware but keeping both increases the size by x2. I am experimenting with /lib/firmware as a symlink and also the other way around, with limited success. At this time I have to use 2 different fdrv.sfs files, one for Puppy and one for KLV.
I am working with a newly compiled 5.16.14

My question is how do I use the usermerge.sh during the kernel build? And is this the right approach I'm looking for?

[dimkr]

My question is how do I use the usermerge.sh during the kernel build? And is this the right approach I'm looking for?

It doesn't need any arguments, just run it after build.sh.

This is how the woof-CE CI pipeline runs it:

https://github.com/puppylinux-woof-CE/w ... t.yml#L103

[dimkr]

But if and when you get a chance, maybe find out why oz's kernel doesn't generate the shut-down problem.

It's probably patched with the patch from https://github.com/sfjro/aufs5-standalone/issues/9.

I'm kinda sick of the issues with aufs lately, and I'm working on https://github.com/puppylinux-woof-CE/woof-CE/pull/2963 with intention to ditch aufs even if user experience with overlay isn't perfect. Random kernel panics and random I/O failures are so much worse.

[mikeslr]

So, I did the following:

Decompressed both the zdrv.sfs from oz's kernel package and that accompanying Upup22.03 and examined both. Then created a new zdrv.sfs by

1. using oz 's boot folder

2. used dimkr's etc folder renaming modules.builtin and modules.order by substituting -5.15.27-64oz as ending. [This may not have been necessary. But I don't know anything about /etc].

3. Most other files/folder and their content were identical except that where 5.15.25 had the modules folder in /usr/lib 5.15.27-64oz had them in /lib. So I replaced the 5.15.25 modules folder with those from 5.15.27-64oz.

4. Also decompressed correponding fdrv.sfses. Similar to the above oz's fdrv had the firmware folder in /lib while 5.15.25 had it in /usr/lib. So I replaced the latter with the ones from oz's fdrv.sfs which I knew included firmware required by my computer. Saw no reason to have a separate fdrv so included this in the zdrv. [Replacement of firmware was probably unnecessary. IIRC, Vanillaupup provided firmware required by my computer].

dir2sfs the modified zdrv, giving it the name zdrv_vanillaupup_22.03.sfs. Then used it along with oz's vmlinuz, and Vanilla Upup's initrd.gz and puppy_vanillaupup_22.03.sfs.

Then booted into it. During boot-up there was no complaint about zram. It booted to desktop and enable me to configure my wifi, mount sda3 on which my portables are located and start portable palemoon on which I have this forum bookmarked. I'm posting from it now.

Short version: AFAIK, all that was actually necessary other than using the vmlinuz of 5.15.27-64oz was to delete /usr/lib/modules and replace it with kernel 5.15.27-64oz' s /lib/modules.

About auf's vs. Overlays: 99% of new User's won't know the difference. I'm happy with either so long as the instructions rockedge provided (or a substitute) is available. Under weedog'd PopOS I set up three boot listings:
PopOS AUTO-SAVE; PopOS RAM-MODE NO CHANGES >uses the w_changes=RAM0 argument; and PopOS NO-NEW-CHANGES > uses the w_changes=RAM2 argument. [I think I've got that right].

P.S. Shutdown without incident. Now to explore to what extent Vanillaupup can make use of the AppImages, SFSes and portables I've accumulated or provide alternative. Eager to see what synaptic can do.
By the way, as it has synaptic can I assume an underlying apt could also be put to use? Sometimes I only need libraries rather than an entire application.

[dimkr]

By the way, as it has synaptic can I assume an underlying apt could also be put to use?

Yes, even stuff like apt install gimp, apt install wine and apt install steam should work, and you can use the official Chrome/Edge/Vivaldi/etc .deb.

[dimkr]

Just uploaded beta5.

It's 18 MB bigger, because the kbuild SFS is now included in the ISO. The main SFS is a bit broken, but in beta6, apt install nvidia-driver-510 (and every other DKMS-based driver package) will work out-of-the-box, just like it does on Ubuntu:

In addition, beta5 switches to overlayfs at /:

(beta6 will also fix the order of the layers, it's a bit messed up)

[dimkr]

beta8 is uploaded and fixes for many issues in previous builds. It has two flavors, one with aufs (with the patch for the recently discovered issue) and another with overlay, which I'm using to post this comment.

Non-free drivers can be installed with Synaptic or apt install now, and everything feels responsive and stable in a flash drive installation.

[mikeslr]

Note that I am now exploring Upup 22.04 so disregard previous posts about 22.03 except the need to install fuse if you want to use AppImages. Recommend that it be installed using synaptic which will list both fuse and fuse3 and a couple of other 'fuse' applications which might be useful/needed.

Upup 22.04 may have booted to desktop faster than any other 'Puppy' I'm familiar with. And its wifi configuration tool worked quickly OOTB.

None of my portables worked. So I decided to install Iron using netsurf to download the '.deb'. netsurf runs as spot and dimkr has properly configured it: attempts to download beyond /home/spot will fail.
In a complex world where there are choices, each choice involves a 'trade-off'. I currently don't know the answer to these question for the reasons explained following: If applications downloaded into /home/spot do not have 'root' permissions then some application such as MikeWalsh's 'permission-changer' may be needed to transfer them and change their permissions. Such an application may also be useful merely to move files to where they can more often be accessed/edited. I wouldn't mind running other web-browsers as Spot; but will gdebi (may have the name wrong) install them to the /Spot folder AND create Menu entries? If not, how do I create those menu entries? And if I wanted to run a web-browser as root, how do I get the deb out of Spot?

Such as bolded above because Mike permission changer is a bash-script and I could not use portables in part I think as they are initiated by bash-scripts which may not function under Upup. Some scripts worked; other didn't.

Tip to those not familiar with upup's file manager. There are no Right-Click pop-up menus. To open a terminal in the folder you're focused on you select action that from the file-manager's toolbar. Took me awhile to figure that out.

My immediate problem is this: the iron deb was taking a while to download. So I took a break. When I returned I was facing a splash-screen which apparently required a password. After a couple of guesses I gave up but had to 'pull the plug' to terminate the OS.

What's the password?

[neojack]

Covering jwm with sway what a genius

[dimkr]

None of my portables worked. So I decided to install Iron using netsurf to download the '.deb'. netsurf runs as spot and dimkr has properly configured it: attempts to download beyond /home/spot will fail.

Netsurf runs as spot, so if you try to open the download file via Netsurf, you'll do that as spot. You'll need to open a file manager window and open that file from there, otherwise installation won't work.

You can use setup spot netsurf-gtk=false to make Netsurf run as root, if you really want that.

What's the password?

The default is woofwoof, as in any other Puppy.

[dimkr]

Covering jwm with sway what a genius

Press Win+Shift+Enter to get a terminal in a native Wayland window that floats above the X desktop

[neojack]

Press Win+Shift+Enter to get a terminal in a native Wayland window that floats above the X desktop

Ya ya ya... got it. Tried to run 2 mtPaint. One on X and one on Wayland. The one on X followed the theme but the other didn't. This is insane !!!
Tried to screenshoot but the wayland part was always bypassed. I think it because of the Wayland is located above the system's screen. So, I can only share my screen through a photo.

shoot001.jpg (181.14 KiB) Viewed 5243 times

[dimkr]

Tried to screenshoot but the wayland part was always bypassed. I think it because of the Wayland is located above the system's screen.

X screenshot tools take a screenshot of the fullscreen Xwayland, while Wayland windows float above it. Use grim to take a screenshot of the Wayland display

[TerryH]

New manual frugal install. Installed and so far running OK. Just a minor issue. I connected bluetooth ear buds, which connected first time without issue. The problem is that the message box that appears to show connected (or when disconnected) stays constantly on the screen on all virtual desktops, for the remainder of the session.

Edit 2: Restarting graphical server clears the message box, the bluetooth connection remains connected.

Edit: Image inserted to show message box removed, as it only showed a pixellated square

[dimkr]

The problem is that the message box that appears to show connected (or when disconnected) stays constantly on the screen on all virtual desktops, for the remainder of the session.

Opened https://github.com/puppylinux-woof-CE/w ... ssues/3060, I'll take a look soon.

[dimkr]

I'm not saying it's a good idea, but it's cool to see GNOME Software working (to some degree) in Puppy

software.png (122.54 KiB) Viewed 6122 times

[Clarity]

+1

Appears to be consistent with the several "friendly" desktops springing up all over in past year/so.