dpup OS 1 Rolling

[wanderer]

hi again

if you made puppy into a modular system
and used my simple build system

you could make a module of wiak's weedog init

and anyone could choose it if they desired in their particular iso build

so now you would have 3 init choices available to everyone

william

[wanderer]

hi all

since this thread appears to be where puppy development is taking place
i will post my 2 cents here

assuming we are talking about a community puppy
it must meet 2 criteria

1. it must be infinitely flexible
(because everyone wants something different)

2. it must be accessible to everyone
(because not everyone is a guru)

the only system i see that meets those 2 criteria is
a modular puppy and
a simple build system

correct me if i am wrong

or

any other ideas

william

[wanderer]

once again

a module could be made of taersh's initrd

yet another option available in puppy linux

people can then work on their own module independently
to further develop it
without interfering with any one else

william

[wanderer]

i have already figured out how to use woof-ce
to make modules from puppy packages
see the minimal modular puppy (from fossapu64) thread
now someone needs to figure out how to determine what packages are needed for each app

the modules would fit right in with dimkrs modular puppy concept

william

[Duprate]

As in this topic, the development of the puppy happens, I will repeat my last post in FatDog64:

"Helo! I didn't know what my second step towards Overlayfs would be on FatDog64! I'm not a programmer. But I'm lucky and I never give up! Today I am pleased to say that, using the WDLGO_UbuntuFocal64 initrd developed by "Wiak", I was able to start FatDog64 811 with an overlayfs kernel! Long live freedom!
Now, I will test exhaustively .... "

The grub looked like this:

menuentry "FatDog64 WDLGO Overlayfs" {
linux /WDLGO/vmlinuz w_bootfrom=/mnt/sda3/WDLGO w_changes=RAM w_copy2ram kvm.nx_huge_pages=auto lockdown=confidentiality
initrd /WDLGO/ucode.cpio /WDLGO/initrd
}

Certainly, it works with any Puppy Linux distribution. After the moment of joy and happiness, time to think about the most convenient method to mount and umount extra modules. Thanks to the developer members, there are options ...

[dimkr]

https://github.com/puppylinux-woof-CE/w ... ssues/2217 will be fixed in build 24.

[dimkr]

I've just added support for encryption of the /save directory in frugalify: without LVM, LUKS, etc'. It's all handled by frugalify (which is 8K bigger now) and the kernel - see https://github.com/dimkr/frugalify#encryption. The user is required to enter a password on every boot, and /save is all messed up if not "unlocked" like frugalify does.

Still need to see how to do this with overlayfs, though.

[TerryH]

Just updated from dpupos 40 to 43. The installation is on a USB flash drive. Following the update I deleted the save folder to start fresh. I reload the firefox config from a backup.

Some minor issues:

After the initial setup and several reboots, the Pupmode is 66, so can't alter setting from Event Manager and unable to alter save. The extlinux.conf is as per release. I have also tried adding pfix=ram(not sure of syntax) to the Append line, but it has no effect, still remains as Pupmode 66.

On shutdown after seeing the dpupos is shutting down, I am always then dropped to tty1 command prompt and then have to do hard shutdown. In earlier version this was intermittent, now occurs all the time.

I also notice that the installation USB drive only displays a 'mounted' indicator in the top right corner, not the 'Home' indicator. When I click this drive, it runs pmount instead of opening the drive in rox.

Edit: On booting the 'home' indicator is displayed, after clicking this drive icon the indicator changes to the 'mounted' indicator.

Edit 2: So after needing to hard shutdown yesterday on all shutdowns/reboots, today I have shutdown and rebooted twice each without issue. So seems reporting the issue was enough to fix it.

Edit 3: OK I've done some checking and see that dpupos is structured differently than other pups. The /initrd directory itself appears to be the mount point of the drive partition that contains dpupos. There is no /initrd/mnt/dev_save (/mnt/home). When I look at the /mnt/sdb1 in rox even though it has the home indicator, it shows as unmounted when accessed by rox prior to mounting. So it is only accessible as /mnt/sdb1 after being clicked or a mount command issued. The drive icon still remains to appear mounted following clicking the mounted indicator, or issuing a umount command. This probably should revert to the home indicator.

[dimkr]

I have also tried adding pfix=ram(not sure of syntax) to the Append line, but it has no effect, still remains as Pupmode 66.

pfix=ram is handed by Puppy's initrd, and it's not present in dpup OS.

On shutdown after seeing the dpupos is shutting down, I am always then dropped to tty1 command prompt and then have to do hard shutdown. In earlier version this was intermittent, now occurs all the time.

I see this too. I still don't know why this happens, and the problem disappears every time I start debugging it.

busybox poweroff always works when you're dropped into the terminal.

I also notice that the installation USB drive only displays a 'mounted' indicator in the top right corner, not the 'Home' indicator. When I click this drive, it runs pmount instead of opening the drive in rox.

Yes, that's because it's mounted at / instead of getting mounted by Puppy stuff. When you click the boot partition, it's mounted again at a different place. Not sure how this can be fixed cleanly.

[dimkr]

Hope to merge https://github.com/puppylinux-woof-CE/woof-CE/pull/2265 into dpup OS soon.

This PR replaces good old X.Org with fullscreen Xwayland, making rendering smoother and tear-free, while also reducing size

[user1111]

Saw Barry's news article post https://bkhome.org/news/202103/puppy-li ... nitrd.html that led me to this thread. Interesting approach. Reminds me of using busyboxes own internal init. i.e. if no kernel init= parameter is specified it looks for /init which can be a symlink such as

ln -s /bin/busybox /init

and where busybox init uses /etc/inittab ... a list of programs to run, one per line of format:

<id>::<action>:<program>

[dimkr]

Recent changes include:

• Faster boot thanks to elimination of sleep calls and zstd compressed kernel images (as opposed to, just the fdrv using zstd)

• Migration from X.Org to Cage+Xwayland

• Codecs that make Firefox able to play online video in sites other than YouTube

• Various GTK+ 3 and icon theme fixes

[josejp2424]

Recent changes include:

• Faster boot thanks to elimination of sleep calls and zstd compressed kernel images (as opposed to, just the fdrv using zstd)

• Migration from X.Org to Cage+Xwayland

• Codecs that make Firefox able to play online video in sites other than YouTube

• Various GTK+ 3 and icon theme fixes

thank you @dimkr , it will be necessary to download it, and test it.
link in the first post?

[dimkr]

Yes @josejp2424, it's always the same place: https://github.com/dpupos/woof-CE/releases

[TerryH]

This is just a request for information on how the dpupos rolling UEFI actually boots.

Having used the extlinux legacy boot version of dpupos-rolling for a while, I am currently trying the UEFI version. I downloaded the UEFI image and created a USB flash drive. All went well and it boots and runs very well. I can't work out how it is booting. When looking at what is actually created, I noticed that the boot partition doesn't contain a grub.cfg, only BOOTX64.EFI. The only item I could find within the dpup-root partition is in /usr/share/boot-dialog. So what makes it boot to the dpup-root, is it within the BOOTX64.EFI?

[dimkr]

@TerryH Thanks for the extra testing! Great to know UEFI boot works on yet another machine.

bootx64.efi is the kernel, and it has a hardcoded kernel command-line. It's built with the kernel's "EFI stub" feature, so the kernel image itself (vmlinuz, bzImage, whatever you call it) is the EFI application, and not a bootloader that runs the kernel. The advantage is that you don't need a separate boot loader, but the disadvantage is that the kernel command-line is hardcoded.

As in the non-UEFI images, the kernel runs /init (from the boot partition), and it's responsible for setting up the layered file system and running the real /sbin/init under it.

[TerryH]

Thanks for the information. Looking at the size of the BOOTX64.EFI, being similar size to a kernel, I thought that something like that was happening. I didn't notice previously, that there is no vmlinuz in this version. I also notice that the image for the init versiona also has a second kernel version vmlinuz.efi.

[BarryK]

@TerryH Thanks for the extra testing! Great to know UEFI boot works on yet another machine.

bootx64.efi is the kernel, and it has a hardcoded kernel command-line. It's built with the kernel's "EFI stub" feature, so the kernel image itself (vmlinuz, bzImage, whatever you call it) is the EFI application, and not a bootloader that runs the kernel. The advantage is that you don't need a separate boot loader, but the disadvantage is that the kernel command-line is hardcoded.

As in the non-UEFI images, the kernel runs /init (from the boot partition), and it's responsible for setting up the layered file system and running the real /sbin/init under it.

Yes, it would be nice if kernel commandline parameters could be appended to 'vmlinuz', as can be done for the initramfs:

https://cateee.net/lkddb/web-lkddb/BOOT_CONFIG.html

I wonder, if you created a do-nothing initramfs, just use it to append cmdline params. Don't know if that is feasible.

[dimkr]

I might change the UEFI boot process in the future: use https://github.com/mfleming/efilinux as the boot loader, so the kernel command-line is in a text file, and put the kernel alongside the boot loader. That would allow change of the command-line without having to recompile anything.

I got it working, but it was a last-minute decision to eliminate this extra boot loader step.

[dimkr]

Build 53 now uses efilinux and a standard Puppy vmlinuz. The kernel command-line is configurable via efilinux.cfg.

[TerryH]

Updated with System Updater to latest dpup rolling release. Noticed that there is a new icon in tray. The icon is actually showing missing icon indicator. I clicked on it and noticed it is for bluetooth. I then set up a bluetooth speaker, which successfully connected, first attempt and is working. The only issue being the icon which is displayed. Well done, this is a nice addition.

[dimkr]

Thanks @TerryH. Yes, I'm working on Bluetooth audio support (https://github.com/puppylinux-woof-CE/w ... ssues/2348, https://github.com/puppylinux-woof-CE/woof-CE/pull/2349).

It seems to work, but Firefox keeps playing audio through the built-in speakers and not through my Bluetooth speakers. Looks like all applications running as spot just don't see the Bluetooth device, because Bluetooth audio works in Firefox when it runs as root.

[TerryH]

Thanks @TerryH. Yes, I'm working on Bluetooth audio support (https://github.com/puppylinux-woof-CE/w ... ssues/2348, https://github.com/puppylinux-woof-CE/woof-CE/pull/2349).

It seems to work, but Firefox keeps playing audio through the built-in speakers and not through my Bluetooth speakers. Looks like all applications running as spot just don't see the Bluetooth device, because Bluetooth audio works in Firefox when it runs as root.

The sound issues with firefox runnnig as spot is common in other puppies also. I tried firefox first and had no sound, I didn't check due to issues in other puppies. I have a portable vivaldi, which sound via bluetooth is working in dpupos rolling. Be good if you can work out problems with firefox.

[dimkr]

Made some good progress. It looks like Puppy's tradition of not running a D-Bus "session bus" for spot makes it impossible to run Blueman as spot.

[dimkr]

Got Bluetooth audio working for both root and spot.

The secret is running PulseAudio as spot, forcing root to use this instance and not root's session instance or a system instance and starting PulseAudio before pa-applet.

Got everything working with lots of manual tweaking but I'll implement this cleanly in woof-CE soon.

EDIT: looking good so far, build #74 should work out of the box.

[dimkr]

Build #84 features fast delta updates!

Now, instead of downloading 700+ MB, updates between build n and n+1 are about 20 MB on x86_64. pm6_updater now tries delta updates and if the result is not identical to the latest build, it falls back to downloading the entire tarball (as before). Users who update often will benefit from super fast updates and smaller download size

[Clarity]

Question
Are your upgrade(s) to cascade one after the other to current release OR are each upgrade a cumulative overlay?

[dimkr]

Question
Are your upgrade(s) to cascade one after the other to current release OR are each upgrade a cumulative overlay?

The updater always picks the latest release, so you always get the latest update and it's "cumulative" in that sense. You don't have to update twice to update build n-1 to build n+1.

However, the delta is between builds n and n+1. If you're updating from n-1 to n+1, the updater falls back to downloading the build n, but if you're updating from n-1 to n or from n to n+1, it's a quick delta update.

[cthisbear]

dimkr:

Gooday mate, probably going to ask a few stupid questions,
but I've bee pretty crook lately so it's a bit hard on the concentration.

They sent me up to theatre to drain some blood poisoning out of me,
but they told me they couldn;t get rid of my Aura of Awfulness.
The hide of those doctors.
So please....no sympathy needed.

I have been using Radkys' Dpup Stretch with the slimjet-15.1.6.0-i686.pet by Oscartalks??

I want something that can still run on rigs from 2012 and newer,
and also use Slimjet so my wife can get off her seat and use Internet Banking safely.
I want to have 2 different Boot usbs, one for a Dell laptop and another for a desktop.

So sorry if these questions have been asked and may I say it is nice to be back here. Not doing table top dancing yet,
but when your internet goes down you'll all know that I've posted a video on Youtube....ugly thought.

Cheers.............Chis

[dimkr]

@cthisbear you're probably better use viewtopic.php?f=40&t=442 or viewtopic.php?p=27644&i=1.