Puppy Linux Discussion Forum

esos wrote: ↑Sat Aug 06, 2022 5:09 am

I can not send Xorg log file as you requested.

This is the reason:
"Your message contains 95905 characters.
The maximum number of allowed characters is 60000."

@esos
Dont paste the Xorg file contents as forum post. just upload the Xorg log file here on the forum. When you are posting on a forum click the ATTACHMENTS tab below. Then upload the log file here

Finally I have tested the QuickPup64 on my Hp Laptop having SSD. However, it is not booting from my HP Laptop. No surprise because of none of Puppy Linux is not booting from my HP Laptop. There is a fundamental issue on Puppy Linux. I don't know where to take up the matter.

Ramachandra Iyer wrote: ↑Sat Aug 06, 2022 2:11 pm

Finally I have tested the QuickPup64 on my Hp Laptop having SSD. However, it is not booting from my HP Laptop. No surprise because of none of Puppy Linux is not booting from my HP Laptop. There is a fundamental issue on Puppy Linux. I don't know where to take up the matter.

@Ramachandra Iyer

What version of Windows does your HP laptop have? If it was Windows 8 or Windows 10. It requires to set bios boot sequence to USB as the first priority. Then register the keys included otherwise just disable secure boot.

@esos

I see that vesa driver was still loading based from your log. Could you please download the latest version of QuickPup, boot it without savefile and run this command on terminal

xorg-autoconf

Then post the generated output here.

Also try to delete /etc/X11/xorg.conf then restart Xorg by going to MENU > LOGOUT then select RESTART X WINDOW

I have installed on internal hard disk- nvme SSD

Ramachandra Iyer wrote: ↑Sun Aug 07, 2022 1:13 am

I have installed on internal hard disk- nvme SSD

Did you install the bootloader?

RustDesk has some positive reviews!!!

Here's a short video that some of forum members would find useful.

Thanks @mistfire for the B20 version of your distro that you share with us...as it progresses.

Boot loader installed. The problem is in the boot process. Some other puppy it is looking for slow storage like usb or sda etc. There is issue in the initial boot process. It has to look into. My case may be isolated one!

Clarity wrote: ↑Sun Aug 07, 2022 5:55 pm

RustDesk has some positive reviews!!!

Here's a short video that some of forum members would find useful.

Thanks @mistfire for the B20 version of your distro that you share with us...as it progresses.

It also was featured by a YouTuber Mental Outlaw
https://www.youtube.com/watch?v=JIAdEGX_sIU

Just wanted to drop in and say I've been playing with QuickPup and really like it. It LOOKS really good which is a huge plus to me.
Thanks so much for undertaking this.

This is really great as it is.

Unwanted/duplicate applications. I have the memory of sieve and am not currently running Quickpup. But I recommend the following way to handle built-in applications you don't want. For reasons explained here, https://www.forum.puppylinux.com/viewto ... 4070#p4070, rather than removing unwanted applications, just turn their display on the Menu off.

If Quickpup has menu-manager --usually found in Menu>Setup>Menu Manager - Edit the Menu-- run it and if an unwanted application displays a green circle, click it to toggle it to red. What that actually does is write a line in the application's /usr/share/applications desktop file which reads:
NoDisplay=true
In the absence of Menu Manager you can open the desktop file in a text editor and manually add that line. Or add a 'z' the Category=: i.e. zCategory=. There being no Category, there is nowhere for an application to appear.

You are right, there is a menu manager and that would be a great way to reduce the amount of items showing on the menus.
Thanks you SO much.

QuickPup64 22.01 BETA 21 released

Changes:
* Linux kernel 5.19.1-lxpup64
* FDRV, GDRV, and XDRV fixes
* Peebee's SFS loading fix
* Added gnome-color-manager
* gPaint replaced mtPaint
* More bugfixes

Download: https://drive.google.com/file/d/1jAB_G4 ... lWd4fFJHdD
MD5 Checksum: 9567c5888c9289e462b8dea11f950974

Downloaded This ISO file to SG2D USB folder, booted, tailored, and sharing a folder with the LAN in less than 2 minutes. Access to LAN's NAS via this distro's enclosed tools, also OK.

Also tested the ISO file boot in QEMU with same performances.

No issues, thus far.

QuickPup64 22.01 BETA 22 released

Changes:
* Glibc 2.36 DT_HASH bugfix
* Linux kernel 5.19.2-lxpup64

Download: https://drive.google.com/file/d/1HLN9fK ... isu37ibFQw
MD5 Checksum: 64b53d41e95c896d343f0e250a566b10

1. Downloaded ISO file from 1st opening post to USB's "/BOOTISOS" folder (30secs)

2. Booted the ISO file in QEMU (1 min to desktop). All working as expected rapidly.

3. Booted the USB (SG2D) on bare-metal, selected the ISO file, booted to desktop (1min).

4. On Shutdown, all expected is functioning as normal in saving session changes.

All is well.

On my latest experiment on QuickPup, I tried to modify the initrd, puppy core files, and package management in order to support overlayfs. So there's a tricky part on switch_root of overlayfs because of workdir. I wonder if the workdir can be moved just like mountpoints?

Will it detect SSD nvme internal disk. Puppy Linux having some fundamental issues. Like not detecting nvme SSD and not found main sfs file.

Ramachandra Iyer wrote: ↑Thu Aug 25, 2022 11:28 am

Will it detect SSD nvme internal disk. Puppy Linux having some fundamental issues. Like not detecting nvme SSD and not found main sfs file.

That's should be detected.

Dear Guru

Upon boot from internal nvme SSD, i got error saying that Puppy-quickpup64_22.01 sfs not found. It has given me option to save error and I have created debug file in usb- sda (not able to save in nvme) and the same is attached herewith for kind perusal. Hope, it will give some idea about my issue.

Thanks

mistfire wrote: ↑Thu Aug 25, 2022 10:21 am

... I wonder if the workdir can be moved just like mountpoints?

As I remember, @wiak, @fredx181 and @rockedge have done extensive work with overlayfs. They may have insights.

For those who might be interested, I also tested with terminal's "qemu_gui" for quickly getting to QP beta 22 desktop.
Here's the stanza it generates:

qemu-system-x86_64 -boot d -m 2048 -enable-kvm -cdrom /mnt/home/boot-isos/quickpup64_22.01-beta-22.iso -smp 2 -cpu host -usb -device usb-tablet -device AC97

Ramachandra Iyer wrote: ↑Fri Aug 26, 2022 4:39 pm

Dear Guru

Upon boot from internal nvme SSD, i got error saying that Puppy-quickpup64_22.01 sfs not found. It has given me option to save error and I have created debug file in usb- sda (not able to save in nvme) and the same is attached herewith for kind perusal. Hope, it will give some idea about my issue.

Thanks

based on the debug files. Try to swap kernel and zdrv with other kernels from puppy. Don't forget to rename the zdrv as zdrv_quickpup64_22.01.sfs

Ramachandra Iyer wrote: ↑Fri Aug 26, 2022 4:39 pm

Dear Guru

Upon boot from internal nvme SSD, i got error saying that Puppy-quickpup64_22.01 sfs not found. It has given me option to save error and I have created debug file in usb- sda (not able to save in nvme) and the same is attached herewith for kind perusal. Hope, it will give some idea about my issue.

Thanks

I'm afraid I don't know much anything about grub boot stanzas for booting pups, but I did wonder about: pmedia=ataflash
That looks wrong to me. Doesn't that force grub bootloader to search usb drives, whereas you said you had the Pup installed on nvme SSD? Try without it.

I remember you said you would test latest KLV-Airedale and see if that booted for you. It should - I'm using nvme SSD on my system, though maybe they are all a bit different. Good to know something from the forum would boot, if it did; might help with Puppy boot itself on your machine.
The way I'd suggest to install KLV-Airedale would be to use the latest weedogit.sh to do the installation for you because it ends up printing out exactly what grub config to try (use the bottom one of the suggestions - always works on my system - doesn't matter what empty folder you use on your drive to do the actual build). Just download the weedogit.sh script to the empty folder on your nvme drive - name the folder whatever you like (but make unique) and then make the weedogit.sh script executable (chmod +x weedogit.sh) and finally run it with command: ./weedogit.sh (and enter choice 19 and wait while the script downloads the iso and extracts all the pieces automatically and presents you with the grub2 uuid stanza to use to boot it.

One other thing I'm wondering about, more generally though, is how are you booting? Where is your boot loader installed? Is it grub1 or what?
If you are trying to boot your nvme installation but from grub2 or similar on a usb flash stick, make sure you have the appropriate uuid or whatever correctly being searched and I'd advise not to have any actual distro installed to your usb stick itself (only grub) for your tests since avoids grub confusion.

If KLV build doesn't work then frankly you system must be very difficult nvme drive indeed! Yet you said some other distros did work installed to it... must be some reason... but none of these reports you uploaded suggest much to me.

On my latest experiment I successfully boot QuickPup in overlayfs using modified initrd init script. However only works if a save file is loaded. It will threw WRONG FILESYSTEM error message upon switch_root if no savefile was loaded. I need some clues on how to mount overlayfs on PUPMODE=5

Grub2 on separate fat32 partition. I don't want disturb windows efi system. The setup on another hp laptop having sda is not loading my home laptop with nvme drive !!. So not the issue of boot loader but some issues on either my hardware or software initialisation. I strongly feel that it is because of fundamental issue on OS boot process. Unfortunately no effort was made even after repeated posting. See antix and portues were working fine on different boot loader like refind, grub2 and at last in Limine. Now posting from mobile and travelling.

mistfire wrote: ↑Sun Aug 28, 2022 2:30 pm

On my latest experiment I successfully boot QuickPup in overlayfs using modified initrd init script. However only works if a save file is loaded. It will threw WRONG FILESYSTEM error message upon switch_root if no savefile was loaded. I need some clues on how to mount overlayfs on PUPMODE=5

You'd need to supply more information than that mistfire to explain what the issue you are having with "Pupmode 5" using overlayfs is.

I have never studied Puppy initrd/init so didn't even know what the different Pupmodes mean. However, I just searched the forum and read up on them to see what the numbers were standing for (and I think Pupmode 5 is just what I refer to as RAM0 mode in WeeDogLinux - i.e. session changes just in RAM and not using save folder at all). From 2013 up till 2019 I was using DebianDog almost exclusively, and not Pups, but it had similar modes and did use aufs back then (in particular uses modified Porteus initrd with changes EXIT mode being I think like Pupmode 13 - I think...). When I was creating my own initrd for WeeDog, I didn't want to use aufs anyway, so I just studied kernel docs on overlayfs back then in early 2019, practiced with it and then made the initrd/init as flexible as I could think of. So from that time the WDL initrd has been able to:

1. Simply store session changes in system RAM rw-layer (is that Pupmode 5)?
2. Load any previous save folder contents back to system RAM rw layer on next boot (I have no idea what if anything Pupmode would call that).
3. Mount any previous save folder to uppermost read-only layer, such that merged result will include that plus the top in RAM rw session-only changes layer (I suspect that is pretty much what Puppy calls Pupmode 13?)
4. Mount any previous save folder to top in RAM rw layer such that any writes are immediately save back (I suspect that is pretty much what Puppy calls Pupmode12?)

Whilst pretty much all union-filesystems have been able to do the above since the early 1970's Sun microcomputer days; they are just different ways of arranging layers and unfortunately every such design gives them different names or modes if that is the term being used.

One major difference with aufs compared to using overlayfs is of course that once you set up layers in overlayfs you can't really change them, whereas aufs allows you to load new layers anytime and reflects back such alterations into the merging of the layers. One result of that is the aufs sfs-load ability, which overlayfs can't directly provide by itself. But also, in item3 above, if same thing done with aufs I believe when you use a rsync utility or similar to save back from rw RAM to the save folder you can at the same time flush out the RAM that had been used since the new save folder contents with aufs reflects back to the merge result (if you see what I mean). With overlayfs, the merge result doesn't re-apply the new save folder contents, so to keep everything working you cannot save RAM by flushing the rw RAM layer after the save back to the save folder.

Much the same comments as all above apply if using a save file instead of a save folder. In practice there is almost no technical difference except that you have to mount the save file (read-write) before then using its contents pretty much exactly the same as save folder.

So, my understanding of your comment is that you are loading a save file into one of the layers (upper most read-only layer for Pupmode 13 or maybe topmost read-write layer for Pupmode 12?), but are getting errors when not doing that and instead simply trying to use RAM (assuming that is Pupmode 5). Is my understanding of the issue you are having correct? If so, you'd need to upload the mount -t overlay code line with an explanation of whatever variables you refer to in that. Using RAM alone requires having tmpfs set up previously for that purpose - at least that's how I do it in WDL initrd and in that RAM area I have upper_changes and work directories (though you will likely use Puppy names for these I expect). I can't imagine why switch_root to the merged result would give any issue, though it is important to make sure the work directory is on same filesystem as the 'upper_changes'.

@wiak

PUPMODE 5 means the read/write layer was tmpfs only (at the ramdisk)

On initrd I mount tmpfs at /overlay then I create writable folder and working folder like this

/overlay/writable
/overlay/workdir

Then mount the overlayfs like this

mount -t overlay overlay -o workdir=/overlay/workdir,upperdir=/overlay/writable,lowerdir=< sfs mountpoints here >,xino=on /pup_new

Then move the /overlay mountpoint to /pup_new/overlay

And lastly switch_root

See the init script attached