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

[dimkr]

Now I dont know how to install kernel source sfs. Help needed.

The kernel sources SFS is broken - see https://github.com/puppylinux-woof-CE/w ... 1024880314.

[pemasu]

This should do the trick:
$ unsquashfs kernel_sources-5.10-kernel-kit.sfs
$ rm kernel_sources-5.10-kernel-kit.sfs
$ mv squashfs-root/lib squashfs-root/usr/
$ mksquashfs squashfs-root kernel_sources-5.10-kernel-kit.sfs

Yep. Vanilladpup 9.1.5 booted after that, kernel source sfs loaded.

Compiling wl.ko...
make[1]: *** /lib/modules/5.10.0/build: Tiedostoa tai hakemistoa ei ole. Seis.
make: *** [Makefile:165: clean] Virhe 2

Yeah, it seems this puppy has finnish locale included. Anyway...error due to build symlink is wrong.
Build and source symlinks were broken. After fixing them like /usr/lib/modules/5.10.0/build, the wl.ko compiled successfully and posting using wifi. I get my android phone off the laptop.

Huoh. I should stop posting...anyway. I tried to install battery tray app, which can suspend when battery percent is 5, and...vattery-acpitool ( needed to hack the source to get it compile, vattery-0.7.5 grabbed from fatdog repo, vattery-0.7.5 source from arch repo ( compiled after that ) does not show battery icon ( red or blue ) on jwm tray. App still works ie suspends using appropriate command. I can right click the empty tray app icon place and open the app and insert the suspending command. I wonder is it due to jwm version or what that Vattery icon does not show at the tray ?

I then compiled cbatticon, grabbed missing icons from Deviant Art repo and created script to Startup for suspending: "cbatticon -l 10 -r 5 -c acpitool -s"

Ah. Read this changelog post: viewtopic.php?p=48365#p48365
I changed the header of this post accordingly. Problem fixed at woof-ce level.

[darry19662018]

Running Pups again for awhile. Had to swap kernel to 4.19.23 from Pfeco's Beowulfpup. Series 5 kernels don't boot on my Compaq CQ61.
Very nice like the BBwireless app.

[dimkr]

9.1.6 and 9.0.28 will be out soon, with a very nice list of fixes. Please use http://forum.puppylinux.com/viewforum.php?f=183 for bug reports and questions.

[OscarTalks]

Was testing 9.1.7 fresh install to a USB flash drive
System crashed to a black screen with nothing responding and requiring a hard power-off.
Not sure where to look for any further clues. Just mentioning it in case anyone else experiences anything similar.
Wonder if it was the screensaver in Xwayland kicking in after 10 minutes of mouse inactivity and doing much more than blank the screen?

I had just written it to the USB using gunzip and dd
Did a couple of steps but left screensaver activated (which I would usually turn off)
Was watching a live stream on YouTube in Firefox, when it all suddenly died including the sound.
I have a feeling something similar happened before a couple of versions ago.
Did the power-off, booted again, seemed OK, turned off the screensaver and all was well after that.

[retiredt00]

Is there a kernel change recompile in 9.1.7?
Kernel still reports as 5.10.0 but modules I have compiled in 9.1.4 and earlier fail with:

Code: Select all

~$ modprobe wl
modprobe: ERROR: could not insert 'wl': Exec format error

~$ dmesg | tail
[  182.855137] wl: disagrees about version of symbol module_layout
[  732.966508] wl: disagrees about version of symbol module_layout

~$ modinfo wl
filename:       /lib/modules/5.10.0/kernel/drivers/net/wireless/wl.ko
license:        MIXED/Proprietary
alias:          pci:v*d*sv*sd*bc02sc80i*
depends:        cfg80211
retpoline:      Y
name:           wl
vermagic:       5.10.0 SMP mod_unload modversions 
parm:           passivemode:int
parm:           wl_txq_thresh:int
parm:           oneonly:int
parm:           piomode:int
parm:           instance_base:int
parm:           nompc:int
parm:           intf_name:string

[dimkr]

Is there a kernel change recompile in 9.1.7?

Nope, the kernel is built with the same configuration.

How did compile this driver? What packages did you install before and how?

[retiredt00]

Is there a kernel change recompile in 9.1.7?

Nope, the kernel is built with the same configuration.

How did compile this driver? What packages did you install before and how?

The wl driver was compiled from Debian non-free source in 9.1.4 and installed through ‘make install”
Was running OK through 9.1.5
After doing the “simple update” to 9.1.7 (that hang tried to update the non-existing initrd.gz on a frugalified installation) the wl module was unusable with the above errors
Running ‘depmod -a’ did not change things
Something that might be relevant is that rebooting after the (hung) installation did not ask if I want to update to 9.1.7 though the 9.1.7 SFSs where used.
So something might got broken there.

Packages installed nothing major but given that synaptics reports all packages as “manual install” I can not be more specific.

[Ramachandra Iyer]

How to install google chrome. Google chrome not found Synaptic Package Manager.

[pemasu]

~$ modprobe wl
modprobe: ERROR: could not insert 'wl': Exec format error

I got this error also after updating from 9.1.5 to 9.1.7. I just recompiled wl.ko again. I dont have 9.1.5 dpup anymore, but tried wl.ko compile from dpup 9.0.27 ( 5.10.0 kernel ) and also same exec format error in dpup 9.1.7.

[Grey]

This is schmorp.de died

it's probably a temporary issue.

I still can't build anything. Not a single distro (slacko15.0 has just been interrupted at the very end). Maybe because there's http in this schmorp.de. In any case, it is impossible to get iso, although everything worked before.
PS. What is the most "beautiful" way to deal with this? Edit /woof/woof-CE/woof-code/rootfs-petbuilds/rxvt-unicode/petbuild ?

[dimkr]

PS. What is the most "beautiful" way to deal with this? Edit /woof/woof-CE/woof-code/rootfs-petbuilds/rxvt-unicode/petbuild ?

Download the files into petbuild-sources/rxvt-unicode, from a different source.

[dancytron]

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).

Is it your intent to not to fully support manual frugal installs in grub4dos or is that on the "to do" list?

[dimkr]

Is it your intent to not to fully support manual frugal installs in grub4dos or is that on the "to do" list?

This is not on my TODO list. My focus is ext4 images with frugalify and without initrd.gz. I can't test all possible installation types, partitioning layouts and boot loaders. Puppy's init script and installers are a huge can of worms - they generate too many issues for me to fix, and most of them take time to reproduce.

If someone wants to create a Vanilla Dpup derivative with ISO releases - you're more than welcome. It should be very easy to do, and super easy to automate (see https://github.com/vanilla-dpup/release ... /workflows).

[dancytron]

Is it your intent to not to fully support manual frugal installs in grub4dos or is that on the "to do" list?

This is not on my TODO list. My focus is ext4 images with frugalify and without initrd.gz. I can't test all possible installation types, partitioning layouts and boot loaders. Puppy's init script and installers are a huge can of worms - they generate too many issues for me to fix, and most of them take time to reproduce.

If someone wants to create a Vanilla Dpup derivative with ISO releases - you're more than welcome. It should be very easy to do, and super easy to automate (see https://github.com/vanilla-dpup/release ... /workflows).

Not ISO releases, .tar files are fine.

I understand this is a cutting edge experiment that can't support everything, so don't take it as a complaint, but you are cutting out a huge part of the user base if you don't support a multiboot frugal install on Windows 7 and older hardware. Better to say that clearly in the 1st post so people don't waste their time on a crippled version.

[dimkr]

Better to say that clearly in the 1st post so people don't waste their time on a crippled version.

I have limited time, and can't support every possible use case.

If you want ISO releases and don't want to build a Vanilla Dpup ISO yourself, you can use 9.0.x.

[dancytron]

Better to say that clearly in the 1st post so people don't waste their time on a crippled version.

I have limited time, and can't support every possible use case.

If you want ISO releases and don't want to build a Vanilla Dpup ISO yourself, you can use 9.0.x.

I understand. We all have limited time.

I'm just suggesting you put something in the top post so people know what's supported and what isn't before they download it.

[williwaw]

I have limited time, and can't support every possible use case.

If you want ISO releases and don't want to build a Vanilla Dpup ISO yourself, you can use 9.0.x.

Understandable.

Is this to say manual frugal installs are not possible with 9.1? I have tried various permutations of stanzas for both Grub4dos and rEFInd. Seems that my frugal partition (sda3) is not found in spite of being present and reported as being looked for. Perhaps a hardware issue, as an .img dd'd to a dedicated disk boots ok.

I find frugal installs useful if for no other reason than testing without maintaining separate disks just for vanilla. Whether I extract the frugal from an iso, tar or .img, I cannot seem to get a workable boot stanza that works with frugalify.

If anyone else has had success with 9.1, loaded by grub4dos or rEFInd please share your refind.conf or menu.lst
tx

[Ramachandra Iyer]

After some trail and error method, I have able to boot from internal hard disk (using complete sda7 partition) through refind.conf. on separate ESP fat partition.(640MB). My hard disk partition as follows.

sda1 8:1 0 260M 0 part
├─sda2 8:2 0 16M 0 part
├─sda3 8:3 0 840.1G 0 part /mnt/sda3
├─sda4 8:4 0 571M 0 part
├─sda5 8:5 0 50G 0 part /initrd/mnt/dev_save
├─sda6 8:6 0 640M 0 part
└─sda7 8:7 0 40G 0 par

I have not checked internal hard disk partition of SSD NVME. ( new generation internal harddisk)

[dimkr]

I cannot seem to get a workable boot stanza that works with frugalify.

Just take the kernel command-line from efilinux.cfg or extlinux.cfg, and copy it as-is.

[retiredt00]

Is there a kernel change recompile in 9.1.7?
Kernel still reports as 5.10.0 but modules I have compiled in 9.1.4 and earlier fail

One difference that I can find in 9.1.7 kernel is that CONFIG_NLS_UTF8/ASCII is built now in instead of a module. Config (as a module) that kernel source has in auto.conf and was the config of the earlier kernels.
Not sure if this is sufficient to trigger the “version of symbol module_layout” error.
Edit: compiling in 9.1.7 with or without changing auto.conf gives the same error.
In any case using

Code: Select all

modprobe --force wl

allows for the module to be loaded and function seemingly OK

Edit2:
Turns out that the kernel_sources-5.10-kernel-kit.sfs from 9.1.7 and the identical name and size kernel_sources-5.10-kernel-kit.sfs from 9.1.5 that both appearing as version 5.10.0 are actually different kernel sources. One is really subversion 93 and the other 96!!!
No wonder that modules compiled agains 5.10.93 will have problems with 5.10.96.
Would be useful if some indication was provided for these “stealth” changes.

[wiak]

Is this to say manual frugal installs are not possible with 9.1? I have tried various permutations of stanzas for both Grub4dos and rEFInd. Seems that my frugal partition (sda3) is not found in spite of being present and reported as being looked for. Perhaps a hardware issue, as an .img dd'd to a dedicated disk boots ok.

I find frugal installs useful if for no other reason than testing without maintaining separate disks just for vanilla. Whether I extract the frugal from an iso, tar or .img, I cannot seem to get a workable boot stanza that works with frugalify.

I took a quick look out of curiousity. My understanding from that is that most vanilladpup64 files (sfs and frugalify) needs to be stored in the root (/) of the partition it is installed on and not in a separate directory on that partition, but I could be wrong. I guess frugalify itself isn't designed for normal multi-distros in separate subdirectory type of structure, but rather as a mechanism for booting from a distro installed to a single partition (for example as might be typical usb stick media boot situation).

It can certainly be booted from WeeDogLinux initrd, however, in KLV-airedale type skeleton initrd frugal install fashion (so easy to boot from own subdirectory on hard drive or usb media then). Of course that provides entirely different layer handling capabilities and save-persistence mechanisms, which is fine, but a few issues have to be addressed at shutdown to account for the save persistence differences and so on. Most of fredx181 utilities that he has provided for KLV-airedale can however advantageously also then be used with vanilladpup64 when booted via that initrd.gz, but there is always the danger later releases will not work with any initrd since dimkr only supports its use with his C-coded frugalify. Generally, however, it is relatively easy to adjust the relatively agnostic WDL initrd/init to work with any distro root-filesystem (without even having to uncompress and modify the initrd.gz itself, but depends - a root filesystem could be tailored for the likes of say frugalify such that it becomes too much work to tweek an unsupported initrd to also boot it (but so far it should be fine).

Of course, you would likely not get dimkr official support when running his vanilladpup64 underlying overlayfs merged root filesystem that way; you might get some support from me, but generally only enough to help you boot it... Nevertheless, if you are like me, with plenty usb sticks but rarely one that is empty and ready for use, then using an initrd in typical multi-distro (separate subdirectories) is the best way to basically try out lots of distros. Actually, I hardly ever write distro images to usb sticks - I just install them frugal style into own directories on a partition, and add them to my hard disk grub2 config, or if I can't, I simply don't use them.

Code: Select all

title dpup os 9.1.X
  find --set-root uuid () 9f8b9e81-9c04-41ca-ace0-d37b1787a94d
  kernel /vanilladpup64/vmlinuz w_bootfrom=UUID=9f8b9e81-9c04-41ca-ace0-d37b1787a94d=/vanilladpup64 fwmod=usrlib w_changes=RAM2
  initrd /vanilladpup64/initrd.gz

Since above is about the WDL initrd boot mechanism more than about the root filesystem being booted itself I'll explain the method in detail as a Kennel Linux (KL) variant tomorrow (and not pollute this thread with the details), which will be able to inherit much of the work being contributed by fredx181 (DebianDog utilities often) and others to the likes of KLV-Airedale. Late here, so have to sleep now.

[dimkr]

I took a quick look out of curiousity. My understanding from that is that most vanilladpup64 files (sfs and frugalify) needs to be stored in the root (/) of the partition it is installed on and not in a separate directory on that partition

Yes, but it won't be hard to add support for psubdir= or whatever. So far, nobody asked for this.

but there is always the danger later releases will not work with any initrd since dimkr only supports its use with his C-coded frugalify.

All woof-CE build configurations produce an identical initrd.gz, and Vanilla Dpup doesn't need any special customization to boot using initrd.gz and PUPMODE=5. However, if somebody else breaks initrd.gz, that will affect any Puppy. The initrd init script is in a very sad state IMHO, it's super complex and slow, and I don't think anyone is brave enough to touch it anytime soon.

I've said it many times already: anyone is free to take the same woof-CE repo used by Vanilla Dpup's automated releases pipeline, fork it and customize it to upload ISO images with initrd.gz instead. It's super easy, and it will work.

EDIT: here's the link, so you don't have to search: https://github.com/vanilla-dpup/releases

Of course, you would likely not get dimkr official support when running his vanilladpup64 underlying overlayfs merged root filesystem that way

When you customize Vanilla Dpup like that, you lose more than my ability to help. You also break the installer and the updater, and probably introduce some issues (for example, regression of https://github.com/puppylinux-woof-CE/woof-CE/pull/2833).

[OscarTalks]

I like Dpups and run them as my everyday Pups, so your Vanilla Dpup is of interest to me, although I test various others in an attempt to contribute to testing and development.
My usual testing environment is:-
Manual frugal install to HDD
Partition is ext2 or possibly ext3
Installed into sub-directory such as /boot/vanilla
Legacy Grub

Obviously the 9.0.x releases are fine and I am happy to experiment with those
With the 9.1 it was possible to boot it a few versions back, when there was an initrd.gz in the tarball (in error, apparently)?
Although that did not add in the bdrv containing apt (I could load it as an extra .sfs)
Since then I have not been able to boot 9.1 with only frugalify and ucode.cpio
Although I did test it in a USB flash drive as I do with EasyOS
That is a little less convenient for testing though. Maybe nice as a portable way of running it.
Anyway, if anyone knows of how to configure menu.lst or if modifications are happening which will help with the manual frugal, that would be nice.
If not, no problem. Thanks for all the hard work, it is appreciated.

[pemasu]

viewtopic.php?p=48473#p48473

@OscarTalks. See above link. I have grub4dos and in that link is working menu.lst for me. I used blkid to show right UUID and PARTUUID.

[OscarTalks]

Hello pemasu,
Thanks for that. I did see your post a few days ago and saw that you got it working. I tried to use that as a guide, with the PARTUUID which I obtained, but some things are different. My usual entries don't have the UUID, they have rootnoverify (hd0,1) and there are all the other variables including the relative paths and from what root am I working with the paths? Plus does it even work with ext2? I will try some more when I get some time, but I am a little unsure that my system might not be compatible with it at all.

[pemasu]

I suppose that you replace the row rootnoverify (hd0,1) with uuid of the boot partition. I believe grub supports uuid as well since 2009 as spesifying boot partition. Blkid in terminal displays the uuid names of every partition and also PARTUUID I used in the kernel row. I just copied the example by dimkr.

[dimkr]

Plus does it even work with ext2?

Yes, it should work with ext2, ext3, ext4, XFS or btrfs.

[wiak]

I took a quick look out of curiousity. My understanding from that is that most vanilladpup64 files (sfs and frugalify) needs to be stored in the root (/) of the partition it is installed on and not in a separate directory on that partition

Yes, but it won't be hard to add support for psubdir= or whatever. So far, nobody asked for this.

That's effectively what @dancytron, @williwaw and @OscarTalks were asking for (not finding in existing implementation). Your PUPMODE 6 seems to be hard-coded (as far as main puppy sfs is concerned) and in recent 9.1.x release being used to umount /proc and thus make normal initrd unable to function anymore (in say PUPMODE 13). That greatly limits flexibility of possible use therefore (though maybe official Puppy initrd writes new PUPMODE to read-write layer on boot - certainly WDL initrd will never do that since not itself concerned with PUPMODES at all - provides its own layering, save persistence mode mechanisms that are pretty much distro root filesystem agnostic).

Of course, you would likely not get dimkr official support when running his vanilladpup64 underlying overlayfs merged root filesystem that way [wiak: context being alternative to use WeeDogLinux initrd as alternative if Puppy initrd no longer working with it and user frugalify didn't provide all modes user desired]

When you customize Vanilla Dpup like that, you lose more than my ability to help. You also break the installer and the updater, and probably introduce some issues (for example, regression of https://github.com/puppylinux-woof-CE/woof-CE/pull/2833).

Yes, I noticed the tie-in between PUPMODE6 and the likes of /mnt/home. So, yes, if anyone used vanilladpup64 via foreign initrd and wanted to develop that to make sure it always worked then it would have to be considered a fork overall in order to account for fixes to any issues and to introduce alternative mode installation routines and to follow (if so desired) some updater changes if they happened to break anything if not using that fixed PUPMODE6. But really I wasn't suggesting any formal fork - just showing an example of alternatives boot mechanism that can be made to work in typical self-contained frugal install configuration dancytron and williwaw seemed to be missing. WDL initrd doesn't use PUPMODES at all of course (as I said, has its own booting, layering and save persistence mechanisms, most of which work well with modified DebianDog app/utilities as provided by @fredx181 for KLV-Airedale use).

Certainly, if frugalify provides all the functionality the user wants then they are best to stick with that unless someone made a formal fork and maintained that to account for diverging differences - I can't see that happening though since everyone is too busy enough already.

I think I am correct, or am I not, that vanilladpup is not created by official Puppy Linux woof-CE github site, but instead has its own separate github site, so is itself a fork of Puppy Linux proper? Since you work on official Puppy LInux woof-CE site too, the water is a bit muddy in that distinction to most people probably - perhaps it is your plan to merge vanilladpup mechanisms all into official main Puppy woof-CE eventually so future Puppy will be lead by frugalify-related developments rather than @gyrog initrd mechanisms?

I'll document how to boot vanialladpup with WDL initrd in another forum section thread so as not to pollute official vanilladpup threads. It isn't a recommendation to ever use WDL initrd with it - I just use that mechanism myself (with many distros, like I understand @Duprate also does) as a frugal install convenience for me to to test out the main distro apps and, in this case, its use of Xwayland and so on.

[williwaw]

I'll document how to boot vanialladpup with WDL initrd in another forum section thread so as not to pollute official vanilladpup threads. It isn't a recommendation to ever use WDL initrd with it - I just use that mechanism myself (with many distros, like I understand @Duprate also does) as a frugal install convenience for me to to test out the main distro apps and, in this case, its use of Xwayland and so on.

Thank you Wiak. I will like to see your hack.

I should mention I am not asking for Dima to support alternative boot methods, especially if it breaks features that also need to be tested. Hence my addressing the boot parameters question to "anyone else" a few days back. Anyone else being those of us that choose to use a boot manager, which I think Dima may specifically be trying to avoid.

If I were to make a feature request, it would be for an easy way to save additional change folders at shutdown time. If one could also have the ability to choose a specific save folder to boot into at next boot, it would allow a rollback and snapshot functionality. I have no idea how to best implement this, but do think it might be a functionality worthy of discussion in this thread.