Vanilla Dpup 9.x (x86 and x86_64) (old thread)

[Maybe]

Dear @dimkr, please help me. Tell me what am I doing wrong? I can't wait to see the new Vanilladpup.

Did you decompress the image before trying to write it to the flash drive, and before trying to open it?

For example:

Code: Select all

cd Downloads && gunzip vanilladpup-9.1.2-ext4-2gb-uefi.img.gz

If unsure, you can check if the image is compressed using something like this:

Code: Select all

cd Downloads && file vanilladpup-9.1.2-ext4-2gb-uefi.img*

I've tested https://www.balena.io/etcher/ and it decompresses the image before writing it to the flash drive. I don't know if the EasyOS tool does that too.

Hooray! everything worked out!

It turns out that my laptop (this is a gift from @ally viewtopic.php?t=4403) does not seem to support uefi. And by my inattention, I downloaded the .img image intended for uefi. Realizing my mistake, I downloaded the bios version and created a usb stick with EasyDD and it worked!

All that's left now is to set up your new Vaniladpup!

From Dmitry (Russia)

[ally]

hi dmitry

check the bios settings, I normally switch uefi off

[Maybe]

hi dmitry

check the bios settings, I normally switch uefi off

Ok, dear Ally! Thank you! I firmly shake your hand!

From Dmitry (Russia)

[ally]

from memory the uefi was for win 8.1?

hope it is working well for you

[TerryH]

New manual frugal install extracted from vanilladpup-9.1.2.tar. Booted fine, if attempting to change the hostname during the initial setup, the initial Message box is displayed, then the rest of quick setup doesn't run. Following this the install is unusable, as desktop / tray / menu launchers don't work, nothing happens when clicked. It was necessary to do hard shutdown. If the hostname is left as is, setup completes successfully. I re-tested the change Hostname to confirm issue. I think that this had occurred previously in other Puppy installs, but haven't had this issue for a long time.

There appears to be a regression with sound in 9.1.2 from 9.0.x, which had working sound. After including the firmware (intcSST2.bin) for my rt286 soundcard, I still have no sound after reboot. All appears fine when i check Pulseaudio Volume Control, the visual indicator shows it is working, but no sound. The Output Device appears as Dummy Output, with no sound audible. Generally if sound is working, the Output Device shows as rt286...

[dimkr]

The Output Device appears as Dummy Output, with no sound audible.

Super weird, I see this too. Nothing audio or PulseAudio related has changed between 9.0.x and 9.1.x, the PulseAudio packages are the same and it's even the same kernel

[TerryH]

The Output Device appears as Dummy Output, with no sound audible.

Super weird, I see this too. Nothing audio or PulseAudio related has changed between 9.0.x and 9.1.x, the PulseAudio packages are the same and it's even the same kernel

Thanks for the quick response. This rt286 is an absolute pain. Sometimes even in some installs that I know it works, sometimes when I boot it doesn't work and need to reboot. Unfortunately that isn't the case with this install.

[dimkr]

Triggered a 9.1.3 with a fix - should work

[TerryH]

Triggered a 9.1.3 with a fix - should work

Initially attempt to do quick update using existing 9.1.2 save folder, no sound. I then booted with pfix=ram, completed setup and copied in the firmware, rebooted. Sound now working.

Thank you.

[williwaw]

I'm not 100% sure what the problem is, but I can recommend two solutions:
1) mksquashfs /initrd/save/upper /initrd/my-previous-save.sfs, then boot with pfix=ram
2) cp -a /initrd/save/upper /initrd/previous-save-backup

No problem really, just seeing what might work best for utilizing Ram sessions going forward with your design.

Extra boot parameters in frugalify are always open for discussion, if they're truly useful, small and safe to implement.

thanks

[dimkr]

Finally, an opportunity to test the protection against conflicts between apt and the main SFS:

A patch for https://seclists.org/oss-sec/2022/q1/80 has been just released, and apt refuses to update policykit (and any other package in the main SFS). This is good: the Vanilla Dpup build process asks apt not to update packages in the main SFS. Instead, the Vanilla Dpup updater updates them as part of the next Vanilla Dpup release, which is built with the latest Debian packages - in this case, 9.1.3 has the fix.

apt upgrade only updates user-installed packages, and this is great, because packages can't auto-update unexpectedly and do things like replacing /bin/busybox with something else. Users can update all preinstalled packages at once (using the Vanilla Dpup updater) or automatically roll back all preinstalled package versions when they switch to a previous Vanilla Dpup release (because apt didn't touch these packages).

I'm super glad this protection works well, and this shows it is possible to have good and safe integration between Puppy and apt.

[amethyst]

I wouldn't bother about updating any packages, just download the latest release if you want the newest it's a rolling release afterall. What is the possibility of something going wrong/clashing/breaking when you update packages? I do the same with internet browsers, I never update. Rather download the newest compiled package. Anyways, that is what I would do so just a personal opinion. The greatness of the package manager should not be as crucial with a distribution presented as a rolling release.

[dimkr]

What is the possibility of something going wrong/clashing/breaking when you update packages?

Super low. Vanilla Dpup 9.1.x uses Debian Bullseye packages, and their versions are frozen, with some exceptions (browsers). apt is configured not to update the preinstalled packages that came with the Vanilla Dpup release, so you can't replace a package with a broken, newer package, using apt upgrade.

apt upgrade will update only the packages you installed yourself, and the updates are stability and security fixes, so they're relatively rare, and very safe.

Don't confuse Vanilla Dpup with a rolling release - it's a stable distro with weekly stability and security fixes, and sometimes usability improvements.

[rockedge]

@dimkr that is excellent progress! I am faced with a similar challenge with the KLV model and creating a similar mechanism to deal with converting rolling updates into a more stable type when dealing with the rootfs SFS.

Feels like you have successfully built a very solid APT addition that has integrated well into the DPup design. This is a major advancement in Puppy Linux technology.

This will open the doors to a test install of ZoneMinder using APT to see how it goes and runs. I have had some small issues with ZM on Debian systems, but may work well on Vanilla DPup. But that's what testing is all about!

Question now is are you ready to put Vanilla DPup into the Mainline section?

[dimkr]

@dimkr that is excellent progress! I am faced with a similar challenge with the KLV model and creating a similar mechanism to deal with converting rolling updates into a more stable type when dealing with the rootfs SFS.

Yeah, it's a problem. The idea of some packages in a SFS and others that you can play with via the package manager, is problematic. You need a way to update both the main SFS and the packages, and if you do it often, things are less likely to break (for example, if it's a rolling distro, some packages won't work if there's a glibc update you can't install because your glibc in a SFS and doesn't get updated).

Package management brings many fun technical challenges, what can I say.

This will open the doors to a test install of ZoneMinder using APT to see how it goes and runs.

Please keep me updated! I'm super curious to see if this works for you.

Question now is are you ready to put Vanilla DPup into the Mainline section?

I don't mind it. Is it close enough to Puppy to be considered a true Puppy?

[rockedge]

@dimkr I am firmly convinced Vanilla Dpup is in the Puppy Linux family. Puppy itself is moving forward and it is important to include and offer these distro's as it is really taking the traditional Puppy designs into a direction that keeps all of the Puppy Linux variants important, interesting and extremely useful.

We will be assigning you as the moderator of the VDP section. Not much to do, but gives you more powers to shape it and integrate it with the GitHub repo. (the "we" is me and my 2 cats with whom I've discussed this move with)

Which one should I be downloading to test out the new APT integration? This will be the one I want to try out the ZoneMinder install process on.

[dimkr]

Which one should I be downloading to test out the new APT integration? This will be the one I want to try out the ZoneMinder install process on.

The latest 9.1.x: https://github.com/vanilla-dpup/release ... x86_64-9.1

Choose UEFI/BIOS, and don't forget to gunzip before you write the image to a flash drive

[wiak]

Since all the new Vanilla Dpup threads under Mainline have been put in Locked State (differing from the other Mainline Pup threads) I guess I should ask my question here. Despite 'taking a break', I'm still reading threads and thought best to ask before I forget the matter altogether:

[*] Traditionally, Puppy uses glibc's default memory allocation settings; Vanilla Dpup uses the RAM Saver to reduce waste of RAM - together with zram swap, Vanilla Dpup should work exceptionally well on computers with 1-2 GB of RAM

That's a definitely interesting list. I'm wondering about this particular one though (especially if you intend this 'ram-saver' mechanism being used in all future Pups(?).

Am I correct in my understanding that you are patching libc.so.6 to alter the default thread-related default dynamic memory allocation mechanisms to fixed static values (thresholds and maximums) and limiting the number of memory pools these allocations are made from to a fixed number that is lower than usual dynamic defaults?

I can understand it would be possible to do something like that such that a system does indeed report less RAM usage on boot, but more important would be how the OS behaves thereafter depending on type of apps being run in terms of their memory allocation needs such that page faults and so on are avoided. I'm not criticising the attempt, but am concerned how advantageous any kind of static allocations (if that is what you are doing) might prove problematic in overall usage. Do the likes of Ubuntu, Slackware, Debian, and so on ever do similar memory allocation mechanism alterations for any of the distros they provide to consumers, and if not, why not if the overall result is so RAM-usage advantageous?

Certainly a worthy experiment and I'd like to know more about the results - beyond initial boot RAM free reports, since that simple report does not itself mean a system will use RAM well or better when running memory intensive apps such as video editing programs involving many processes and threads (which many of us do - even with Pups). On the whole, I tend to trust upstream-provided dynamic memory allocation settings (provided by experienced teams who work extensively at kernel system level), and I haven't myself come across anything convincing online to suggest it is generally better or advisable to manipulate how thread memory allocation occurs (or why wouldn't that be what was provided from upstream by default?). No question about zram swap - I use that too - works great, but that is much more 'conventional' to use and doesn't involve any major lib patches at all.

[dancytron]

I've done a pupmode=13 manual frugal install of this.

All works as expected so far.

Are you looking for hardware reports or any specific testing to help out?

[dimkr]

Am I correct in my understanding that you are patching libc.so.6 to alter the default thread-related default dynamic memory allocation mechanisms to fixed static values (thresholds and maximums) and limiting the number of memory pools these allocations are made from to a fixed number that is lower than usual dynamic defaults?

https://man7.org/linux/man-pages/man3/mallopt.3.html

By default, libc does some trade-off. System calls are expensive, and if every allocation results in a system call, memory allocation will be slow.

Therefore, libc uses multiple techniques for memory allocation: large allocations with mmap(), small allocations from a chunk of memory allocated using sbrk() and so on.

The default values (like M_TOP_PAD=128*1024) result in some waste of RAM, in the name of faster allocation. Vanilla Dpup uses a different configuration, one that trades extra CPU for reduced RAM consumption: for example, more allocations are done using mmap() (a system call), making them slower, but the munmap() call done by free() actually releases this memory.

Feel free to try this for yourself: you'll see a nice 10% reduction in memory consumption, in most cases, but in systems with a RAM bottleneck the CPU% hit is worth it. On a laptop with 2 GB of RAM and a super slow quad-core ARM CPU, I can see improvement in the the number of open tabs and the browser's overall responsiveness.

Of course, there are no right and wrong answers here, the magic numbers used by default are good in some cases and bad in others, and so are the smaller numbers. But if Puppy is famous for working well on machines with little RAM, I think the right choice is to go for more conservative settings.

Are you looking for hardware reports or any specific testing to help out?

Nope; but if you have issues, feel free to report them and I'll take a look.

[pemasu]

I couldnt figure out how to boot 9.1.latest with grub4dos from hdd install. I copied files inside .img using loopimg script from jafadmin to the hdd, thanks by the way. But I dont know how to configure menu.lst to use frugalify with hdd install. I didnt find info anywhere.

Maybe I am the only fossil still using grub4dos bootloader, but if anyone knows how to use grub4dos bootloader with frugalify, I would be very thankful of the info. Then I could test 9.1.versions

9.0.latest boots fine from hdd using grub4dos. Copying files from .iso was also easier, when I didnt have to use loopimg to acces files. Easypup does not open .img files straight which was my workhorse to configure hdd for vanilla dpup.

Using 9.0.27 now. Compiling wl.ko worked straight. Using wl.ko now for internet connection. Also usb tethering using android phone works automatically by just accepting net streaming from the phone. I used usb tethering before compiling wl.ko.

First time I got bluetooth working in this testbed HP G4 laptop. It needs BCM43142A0-0a5c-216d.hcd firmware which was not included in the firmware sfs. After copying it and several attempts with bluetooth gui and pulseaudio manager I got bluetooth speakers working. Great !

snd_hda_codec_realtek is problematic, without force module removal, the shutdown halts straight and with force removal it still does not shutdown, but at least saving to the folder happens. So clean shutdown or reboot is not possible.

[dimkr]

But I dont know how to configure menu.lst to use frugalify with hdd install. I didnt find info anywhere.

You'll need to copy the kernel command-line from extlinux.cfg to your menu.lst (with modifications, probably).

@rockedge Is there any way to lock this thread and move it to viewforum.php?f=183?

[dancytron]

I used the *.tar version, just pasted it into a directory, and used my normal simplest pupmode=13 grub4dos entry.

Code: Select all

title Puppy Linux Dpup in sda1 dir Dpup
rootnoverify (hd0,0)
kernel /Dpup/vmlinuz pmedia=ataflash psubdir=Dpup
initrd /Dpup/initrd.gz

Is that wrong?

[pemasu]

Dancytron. 9.1.X latest which I downloaded did not have initrd.gz but it had frugalify.

I am now posting from 9.1.5. I downloaded vanilladpup-9.1.5-ext4-2gb-bios.img.gz and extracted the content using loopimg script which loopmounted it.

Grup4dos menu.lst which worked for me is:
title dpup os 9.1.X (sda13)
uuid 86b28755-285e-452b-b76f-15130f6a5aa5
kernel /vmlinuz root=PARTUUID=000732f3-0d init=/frugalify rootfstype=ext4 rootwait rw
initrd /ucode.cpio

I used blkid to identify uuid and partuuid. Otherwise I used included extlinux.cfg as template.

Thanks dimkr. And sorry that I polluted the thread.

[dimkr]

Is that wrong?

@dancytron It should work. The updater and the installer probably won't work, though.

But bear in mind that initrd.gz is unmaintained in the 9.1.x branch - when I look for small and safe bug fixes I can cherry-pick from latest woof-CE into the stable 9.1.x branch, I ignore fixes that go into initrd.gz. In fact, initrd.gz shouldn't even be inside the tarball: this is a bug, and I might fix this soon.

It's impossible to maintain all the complexity inside initrd.gz and fix all the technical debt (for example, inability to add yet another *drv without breaking anything), especially when other woof-CE users resist change.

@pemasu's example is good, that's exactly how you're supposed to use frugalify with your own boot loader (as opposed to, the one installed by the Vanilla Dpup installer, or the one in the prebuilt images).

[Grey]

@dimkr , I'm sorry I'm off topic. But do you happen to know why Fossa is not being built with Woof-ce? Blame rxvt, which does not download (at the last step). Last year, everything worked out. This is schmorp.de died or someone made changes to Woof-ce?

rxvt_ops.gif (26.76 KiB) Viewed 1967 times

[dimkr]

This is schmorp.de died

Maybe - your wget timed out. It could be your internet connection, or schmorp.de. Just try again, it's probably a temporary issue.

(AFAIK, fossa64 was built using a heavily modified woof-CE, with many changes not integrated into woof-CE as we know it today. And it was long ago, so you can't really reproduce fossa64, if that's what you're trying to do. The "fossa64" in woof-CE is far from the real thing.)

(You can get a snapshot of what woof-CE can build from https://github.com/puppylinux-woof-CE/w ... #artifacts)

[pemasu]

kernel /vmlinuz root=PARTUUID=000732f3-0d init=/frugalify rootfstype=ext4 rootwait rw modprobe.blacklist=snd_hda_codec_realtek ( this is one row in menu.lst )

Blacklisting the realtek sound module fixed the hanging during shutdown process. Now I get clean shutdown/reboot. And sound still works.

[OscarTalks]

Is there a bug with the setup GUI tools for mouse cursor acceleration?
Same was happening in Void32
Opening Menu > Setup > Puppy setup > Mouse/Keyboard > Adjust mouse sensitivity
The GUI is set to Acceleration=2.00 (and Threshold=4)
This seems to be stuck on 2.00
Is it still supposed to write the settings to /root/.xset.sh and then the GUI reads back the setting from there, or is there some other mechanism?
It does write something to that file when I try to change acceleration, but it looks wrong
The old pupx script (which used to do this) now only brings up the screensaver control.

[pemasu]

9.1.5 version, hdd install. Kernel source sfs from here: https://github.com/vanilla-dpup/release ... el-kit.sfs
Downloaded and inserted to the root of the partition among other vanilladpup sfs`s.
When inserted there and rebooting, booting just hangs. Removing kernel source sfs and booting, no problem, it boots okays. I did redownload the kernel source sfs and same problem.
Now I dont know how to install kernel source sfs. Help needed.