Puppy Linux Discussion Forum

Great!

Downloaded the ISO file to the SG2D USB and directly booted. Including the download time, I was on a pristine desktop in 3.25 minutes (slow internet).

System is responsive as usual. Setup was completed via the Control Panel for startups and servers.

Very smooth.

Question

• Will the Control Panel's Savefile utility expand to accomodate generating an entry for users who save their sessions in a save-folder?

Request:

• I had tested BTOP found in ImpPUP64 and found it extreme useful. It is much more feature-rich for system's operations at a glance than HTOP while taking the same on-screen real-estate. Please evaluate as an OOTB for FD final.

Enjoying the system.

Clarity wrote: ↑Sat Oct 16, 2021 9:36 pm

Great!
System is responsive as usual. Setup was completed via the Control Panel for startups and servers.
Very smooth.

Thanks for testing.

Question

• Will the Control Panel's Savefile utility expand to accomodate generating an entry for users who save their sessions in a save-folder?

Err, it already does that, doesn't it?

Request:

• I had tested BTOP found in ImpPUP64 and found it extreme useful. It is much more feature-rich for system's operations at a glance than HTOP while taking the same on-screen real-estate. Please evaluate as an OOTB for FD final.

Are you talking about this one?

I don't think Clarity followed it through to the end, where saving in a directory is offered. Yes, it does refer to savefiles all the way through, but the directory option is there at the business end. I suppose it could be referred to at the start, but this leads to more cluttered dialogs and potentially more confusion.

Everything working ok for me anyway. All good stuff, as ever.

Current 'Savefile' generator
Yes, the Utility will generate a correct addition for the linux line. ('I should have not been in such a hurry, as company was arriving, when it was reported.")

I "think" what might be helpful is NO change in the utility function, rather

• a re-wording of the title ("save-session generator" vs. "savefile ...)

• or the screen describing what to add to for the generator.

Where a user might mis-understand is that the utility needs to know where the save-session folder is or where the save-session file is. or some similar wording.

My only concern is not to change its behavior, merely some manner of making a bit more clear that it covers the save-session bases of covering those who save sessions in folders vs those who save in files. Noticed this before, but never commented.

BTOP
Yes, that BTOP github is what is included in @666philb latest. It has a ton of 'in-your-face" useful info that I think all, new or seasoned users, would find helpful. If you think it will benefit users, I'm sure it will show up going forward.

This distro is outstanding thus far. A "ton" of usefulness.

Created new directory, extracted initrd and vmlinuz into it, changed the path in grub's menu.lst and rebooted. No surprise here, boots up fast and on first inspection everything works.

Alright, thanks for testing, guys!

Clarity wrote:

My only concern is not to change its behavior, merely some manner of making a bit more clear that it covers the save-session bases of covering those who save sessions in folders vs those who save in files. Noticed this before, but never commented.

Sure, why not, it's just a cosmetic change.

Clarity wrote:

I had tested BTOP found in ImpPUP64 and found it extreme useful. It is much more feature-rich for system's operations at a glance than HTOP while taking the same on-screen real-estate. Please evaluate as an OOTB for FD final.

It can't be built natively in Fatdog, because:

Needs GCC 10 or higher,

and we have 7.3.0.

You can still use the official binary, though.

Greetings!

If BTOP is to be considered, understanding what Jake has share, this may/may-not be helpful.

FYI

JakeSFR wrote: ↑Sun Oct 17, 2021 5:53 pm

It can't be built natively in Fatdog, because:

Needs GCC 10 or higher,

and we have 7.3.0.
You can still use the official binary, though.

I'm quite happy to re-package the official binary and turn it into a package.
But just be warned that for the "optimal monitoring experience" (TM), you need more than just btop.
You need:
- terminals with 24-bit truecolor support (urxvt is __not__ one of them, I don't think Fatdog has any of the listed ones)
- fonts with braille glyphs (I don't think Fatdog has this either)
- and if you have rendering issues, contact the developer of the the terminal program (hint: not btop's developer).
If you don't need the requirements, you can still run it under 1980's compatiblity mode, though, in 16-color TTY mode. But don't expect to see anything close to what you see in the screenshot

EDIT: it's there on gslapt package manager. Since it's an official binary, if you encounter problem, please report directly to btop's author.

Only if it is felt to be useful and helpful. I only present the idea directed at those items related to system operation and behavior. We already have multiple utilities present in FD that individually produce helpful info. BTOP's only advantage is combining service information at a glance with some management capabilities.

So only consider it only if it is beneficial to development, administrators, and users. And of course if it is timely.

Edit: Is there a terminal recommendation?

Having tested, save-sessions, and overall system operations, this is fast and stable.

Great work.

Clarity wrote: ↑Tue Oct 19, 2021 6:20 am

Edit: Is there a terminal recommendation?

If you look at the github link I left for you, and you scroll down, the author gave a link to the terminal that supports 24-bit true colour output. It's not a recommendation, but more of what meets the requirements to run btop with 24-bit colour mode.

I copied the link here.

I booted this computer (currently running Fatdog64-811) into Fatdog v812RC1 with a new save folder. I have noticed two problems.
1) No ethernet connection (see images 1 &2)
2) executing Fatdog64 Set Default Sound Card generates image 3.
Machine specs for this box (Dell-Precision-Tower-3000-Series-3420) shown in image 4

superchook wrote:

I booted this computer (currently running Fatdog64-811) into Fatdog v812RC1 with a new save folder. I have noticed two problems.
1) No ethernet connection (see images 1 &2)
2) executing Fatdog64 Set Default Sound Card generates image 3.

Was that also the case before you created the savefolder?

Running fatdog-default-soundcard.sh from CLI could give more meaningful error messages.

Also, aplay -l to list the sound cards and find /sys/class/net/* for network interfaces.

Btw, is there any output from lsmod command?
And which kernel are you using (uname -r)?

Greetings!

Hi Jake,
Both problems have been solved. Posting from Fatdog64-812 on my main computer (Quadruple boot, Windows 11, Linux Mint, Fatdog64-811 and now Fatdog64-812)
The Linux Mint Grub 2 boot loader is used for booting and I had made an error in editing 40_custom which is read by grub-update when adding another OS.
I was loading the fatdog64-812 kernel but with the fatdog64-811 initrd. Oops!
Currently Fatdog64-811 is my day to day OS but I will move to this one if all continues to work OK

cheers,
Ken

Hi. I hope Clarity, and others, won't mind me adding another thank you post to this thread.
So far I have only tried Fatdog64-812rc live (without saves), using flash drives set up using the usb-boot-mbr.img (this time I had put the initrd and vmlinuz files in the top level of the second partition, as suggested in the Fatdog Help, rather than letting my counter-productive "in a directory" mindset get in the way ). One drive was already set up from Fatdog64-811, and one was set up using Fatdog64-812rc.
It has worked well on an AMD 3000G based system (CSM/Legacy), an MSI CUBI-N (Intel Pentium N4000 CPU) (UEFI), a Ryzen 5 1600AF based system (UEFI) and two laptops with 7th gen AMD processors, an A4 (UEFI) and an A9 (CSM/Legacy).
Thank you very much for making this available.
Mounting and un-mounting encrypted filesystems using the desktop drive icons was also tried, and worked well. Again, thank you. USB flash drives, one with a LUKS1 (I think) set up, and one with a LUKS2 set up, were tried. As was a hard drive based partition.
Of course, I had to get a bit carried away with this, and unintentionally tried to use it to access an encrypted LVM (I couldn't understand why it didn't work, for way too long, before realising what I was trying to do, D'oh. Just saw the encrypted symbol and went for it. Oh, I am an idiot!). A very big thank you, again, for saving me from my own stupidity. I have a suspicion that things could have ended up being a bit messy if it had attempted to open it.
Thanks again.

superchook wrote:

I was loading the fatdog64-812 kernel but with the fatdog64-811 initrd. Oops!

Yeah, I was suspecting something like that. Glad to hear it's ok now!
___________

baldronicus wrote:

Of course, I had to get a bit carried away with this, and unintentionally tried to use it to access an encrypted LVM (I couldn't understand why it didn't work, for way too long, before realising what I was trying to do, D'oh. Just saw the encrypted symbol and went for it. Oh, I am an idiot!). A very big thank you, again, for saving me from my own stupidity. I have a suspicion that things could have ended up being a bit messy if it had attempted to open it.

Alright, thanks for extensive testing!

As for the encrypted LVM, I've never dealt with LVM before, so it didn't even cross my mind to test this scenario.

Anyway, I think I might have fixed the issue.
I created a physical volume on /dev/sdc1, added two logical volumes to it, encrypted them with LUKS and formatted, and both mount and unmount correctly now.

As for the opposite scenario (LVM logical volumes on a LUKS encrypted partition), it already works, even without the fix, but after opening the LUKS partition I need to do 'vgchange -ay', so the volumes show up and 'vgchange -an' before closing.

If you care/dare to test, the attached tarball contains modified fatdog-drive-icon-frontend.sh and fatdog-drive-icon-action-handler.sh scripts. Both should go to /usr/sbin/.
Then you need to restart the frontend with:

fatdog-drive-icon-frontend.sh

I recommend testing it on a savefile-less system and some ad hoc, unimportant LVM volume.

Greetings!

Hi JakeSFR. Thank you for your efforts regarding this, and for the commands to access the LVM.

A fresh test installation of Debian 11 was set up with a separate boot partition and an encrypted LVM (on sda5). The LVM (volume group name is "atst") is on a LUKS encrypted filesystem, as per the second type of installation you mentioned above. There are three logical volumes, one of which is formatted as swap.
Fatdog64-812rc was booted live, without a savefile. The initial setup was run, and then the file with the scripts was unpacked, and the scripts copied to /usr/sbin, overwriting the existing ones.
The command fatdog-drive-icon-frontend.sh was run from a terminal. The icons appeared to refresh. (I had to miss this step first go, of course).
When the icon for sda5 (which, of course had a small lock icon associated with it) was clicked, the prompt for the passphrase came up, as expected. After this was entered, sda5 was unlocked. No new icons appeared at this stage. When the dmcrypt-sda5 icon in /dev/mapper was clicked a message came up "I don't know how to open /dev/mapper/dmcrypt-sda5".
The command vgchange -ay was then run in a terminal. Two lines came up with text along the lines of "File descriptor x (socket:[xxxx]) leaked on vgchange invocation. Parent PID xxxx :sh".
Then came "3 logical volume(s) in volume group "atst" now active".
Two new icons "dm-1" and "dm-2" had appeared. Clicking on each one accessed the relevant filesystem.
A check in /dev/mapper indicated that three new links with labels "atst-" and each respective logical volume name, were present, with the link targets being "../dm-1" through to "../dm-3". I suspect that "dm-3" didn't appear on the desktop as it was swap.

The green close boxes on the "dm-1" and "dm-2" were then clicked to unmount them, and then the command vgchange -an was run in the terminal. This resulted in more "leaked" messages, and then "0 logical volume(s) in volume group "atst" now active". The green close box for sda5 was then clicked to unmount the encrypted volume.

Please accept my apologies for the verbosity. Hopefully I haven't missed anything, put anything out of order, or mixed up the files.

I hope I haven't simply made more work for you. Although this post is already too long I should admit that if I had been "with it" I wouldn't have even made the attempt to open the encrypted LVM in the post above. However, once I had made the mistake, I thought I should mention it in case someone else wondered why things weren't working should they inadvertently attempt something similar. Whilst I would normally just access the encrypted LVM via the operating system associated with it, I realise that others might have different approaches to things. Your efforts have also opened my eyes to how useful Fatdog would be as a "fallback/rescue" option should a boot issue or something make the normal OS inaccessible. So thank you again.

baldronicus wrote:

Hi JakeSFR. Thank you for your efforts regarding this, and for the commands to access the LVM.

A fresh test installation of Debian 11 was set up with a separate boot partition and an encrypted LVM (on sda5). The LVM (volume group name is "atst") is on a LUKS encrypted filesystem, as per the second type of installation you mentioned above. There are three logical volumes, one of which is formatted as swap.
Fatdog64-812rc was booted live, without a savefile. The initial setup was run, and then the file with the scripts was unpacked, and the scripts copied to /usr/sbin, overwriting the existing ones.
The command fatdog-drive-icon-frontend.sh was run from a terminal. The icons appeared to refresh. (I had to miss this step first go, of course).
When the icon for sda5 (which, of course had a small lock icon associated with it) was clicked, the prompt for the passphrase came up, as expected. After this was entered, sda5 was unlocked. No new icons appeared at this stage. When the dmcrypt-sda5 icon in /dev/mapper was clicked a message came up "I don't know how to open /dev/mapper/dmcrypt-sda5".
The command vgchange -ay was then run in a terminal. Two lines came up with text along the lines of "File descriptor x (socket:[xxxx]) leaked on vgchange invocation. Parent PID xxxx :sh".
Then came "3 logical volume(s) in volume group "atst" now active".
Two new icons "dm-1" and "dm-2" had appeared. Clicking on each one accessed the relevant filesystem.
A check in /dev/mapper indicated that three new links with labels "atst-" and each respective logical volume name, were present, with the link targets being "../dm-1" through to "../dm-3". I suspect that "dm-3" didn't appear on the desktop as it was swap.

The green close boxes on the "dm-1" and "dm-2" were then clicked to unmount them, and then the command vgchange -an was run in the terminal. This resulted in more "leaked" messages, and then "0 logical volume(s) in volume group "atst" now active". The green close box for sda5 was then clicked to unmount the encrypted volume.

Please accept my apologies for the verbosity. Hopefully I haven't missed anything, put anything out of order, or mixed up the files.

Thanks again! I had the same experience (and messages, IIRC) with LVM on LUKS.
Yes, swap shouldn't and won't show up as a drive icon.
And being verbose while reporting or reproducing something is a feature, not a bug.

baldronicus wrote:

I hope I haven't simply made more work for you. Although this post is already too long I should admit that if I had been "with it" I wouldn't have even made the attempt to open the encrypted LVM in the post above. However, once I had made the mistake, I thought I should mention it in case someone else wondered why things weren't working should they inadvertently attempt something similar. Whilst I would normally just access the encrypted LVM via the operating system associated with it, I realise that others might have different approaches to things. Your efforts have also opened my eyes to how useful Fatdog would be as a "fallback/rescue" option should a boot issue or something make the normal OS inaccessible. So thank you again.

Not at all. Even although the issue in the first scenario wasn't the one you had faced, at least it propmted me to test it.
And fixing it was trivial. It was just a problem with two dm-* members in a path, what confused the script.
I didn't foresee the case where dm-* device (LUKS) is being opened from another dm-* device (LVM).

Greetings!

Upgrading to FATDOG v812RC1 from FATDOG v811

So far everything is working as expected.

Previously for my FATDOG v811 installation I had used licks that I found in ISO
LICK-1.3.4-win32.exe

For the FATDOGv812 install I extracted initrd and vmlinuz from the ISO,and dragged into my Fatdog64-811 folder, changed the name of folder to Fatdog64-812
I changed the path in grub's menu.lst and rebooted
Here is menu.lst ....

## start section Fatdog64-812
title Fatdog64 812
find --set-root --ignore-floppies /Fatdog64-812/vmlinuz
kernel /Fatdog64-812/vmlinuz pfix=fsck psubdir=Fatdog64-812 savefile=direct:device:sda3:/fd64save-812
initrd /Fatdog64-812/initrd
boot

My savefile folder is on a different partition but grub can find it.
Install booted very fast, only a few seconds on an old DELL i5 desktop

Old apps worked including supertuxcart found in fatdog repository
Blender, KRITA, Shotcut appimages worked.
_______________________________________________

Wifi Networking worked (external USB wifi stick), however I noticed one strange thing.
I believe I clicked (accidently) on Restart button --> see image
and a warning window popped up. I couldn't get rid of it until I rebooted. Nothing serious, just strange.
_______________________________________________________

a warning window popped up. I couldn't get rid of it until I rebooted. Nothing serious, just strange.

Thank you @don570, I think this is the symptom of a regression. I'm looking into this problem now...

Just a note...

Rox-Filer found in repository works in earlier versions of fatdog64.

I was successful installing rox-filer-jun7-2021.09-x86_64-1.txz in fatdog64-802

Just a simple right click install then restart X

https://distro.ibiblio.org/fatdog/packa ... 6_64-1.txz
or
https://distro.ibiblio.org/fatdog/packa ... 6_64-1.txz

step wrote: ↑Wed Oct 27, 2021 8:34 pm

a warning window popped up. I couldn't get rid of it until I rebooted. Nothing serious, just strange.

Thank you @don570, I think this is the symptom of a regression. I'm looking into this problem now...

Fixed for the next release.

Hi JakeSFR. It is probably redundant, but I thought I should let you know that I have finally attempted to emulate your LVM-LUKS test, as well as trying a separate one, with a LUKS partition on an LVM spanning two physical partitions (well, semi physical, as it was on an SSD). (I cheated and used the Debian installer to set up the LVMs ).
As expected, the results were similar, and, I think, the same as yours. Once an LVM was activated, using vgchange -ay, the icon/s for the encrypted logical volume/s appeared. Clicking on the icon would result in a passphrase prompt. Once entered, the volume would open, and if a filesystem was present on the encrypted logical volume/s, another icon would appear with the next available "dm-" number. Clicking on that icon would mount the filesystem so that it could be accessed. Clicking the respective green "close" mini-icons in turn would unmount the respective devices. Using vgchange -an to de-activate the respective LVMs would result in the icons disappearing from the desktop.
Again, probably redundant, but it was interesting trying it. Thanks again.

@baldronicus: Alright, thanks for the confirmation and the additional test!

Greetings!