What Puppy do you recommend for me?

[dimkr]

[ don't know about yours, but my machines are noticeably running harder and hotter when un-squashing and squashing system structure files in the background. The fans are much louder. So if the OS is clean in the ISO it was installed from it would be hard to hit if no save folder or file is used.

My Thinkpad X220 doesn't struggle with LZO. I wouldn't notice malware that unpacks adrv and re-packs it with LZO compression and persistent malware inside.

---

Some Puppy releases will boot from btrfs, but none support boot-time fsck for mounted btrfs partitions (through pfix=fsckp). Also, all Puppy kernels I looked at have CONFIG_DM_CRYPT=m (not =y) and the Puppy init script doesn't support volumes (LVM/btrfs subvolumes) or encryption (other than luks1 for save files).

[bigpup]

This is all very confusing, all the more because I have a 10-year-old machine that is still modern enough, and I am having problems with Puppy's concept of booting. It is very confusing.

I managed to install it on an old hard disk, but I didn't trust Puppy's bootloader installation so I just edited my existing Grub menu. I suppose Puppy would just overwrite my Grub and disable booting from the other OSes.

Now, the installation worked on sdb2 (very little free space) but failed on sda1.

https://0x0.st/XNh7.mp4
(MP4, 2MB, 25 seconds)

Do you know why it fails on sda1?

You need to understand one thing.

We only know what you tell us.

Nothing tells us what format sdb2 is.

Nothing in this original post says anything about getting it to work on sda2.

nothing in it tells us exactly what Puppy Linux version you did get to install and boot.

nothing about how you did the install.

S0, yes I took a guess that btrfs format could be the issue.

Now you have given more info that indicates that was not the cause.

you also need to know that this forum hosts some not Puppy Linux OS's.
sorry but I do not keep up with how they do stuff.

So how about just talking about one specific operating system version.

I have tried several Puppy versions tells us nothing useful.
Every operating system available on this forum does not work exactly the same.
Even different versions of it.
Because a different version could be the bug fix or improvements to it.

So we all know exactly what exact one you are trying to use.

[bigpup]

Well you are about the first person posting about using btrfs format.
So we are all learning some stuff about using it.

I would agree that some of the programs, that are in Puppy Linux, are coded to work for specific formats.
One being program that makes the Puppy save.
If it will allow a save file or save folder on the location selected.
Format determines this.
Save file any format.
Save folder for sure on ext formats, but not on fat, ntfs, exfat, and maybe others not checked.
Could also depend on what version of the save building process is in the specific Puppy version.
Puppy software changes over the years.

Example btrfs support in the Puppy version I am using right now.
.

Screenshot(8).jpg (91.68 KiB) Viewed 731 times

It is using Linux kernel 5.10.39

As shown it has none of the needed support files/programs for btrfs

Are you using BookwormPup64 10.0.6?
It has a series 6 Linux kernel and one of the newer ones.

[bigpup]

With BookwormPup64 10.0.6 being the latest version of Puppy Linux, that will be reported on DistroWatch.

I checked it to see what support it had for btrfs format.

First check it had the same info as the above image shows.
None.

After I installed the btrfs-progs.

It now shows this for support of btrfs.
.

Screenshot(3).jpg (52.17 KiB) Viewed 716 times

.
.

[dimkr]

Example btrfs support in the Puppy version I am using right now.

This doesn't indicate whether or not the kernel can mount btrfs partitions, you're confusing gparted's partition editing capabilities (through btrfs-progs) with the btrfs driver (which is part of the kernel).

What matters is zcat /proc/config.gz | grep ^CONFIG_BTRFS_FS - if it says y, you can boot from a btrfs partition. Pretty much any modern Puppy should have it.

[fredx181]

This is all very confusing, all the more because I have a 10-year-old machine that is still modern enough, and I am having problems with Puppy's concept of booting. It is very confusing.

I managed to install it on an old hard disk, but I didn't trust Puppy's bootloader installation so I just edited my existing Grub menu. I suppose Puppy would just overwrite my Grub and disable booting from the other OSes.

Now, the installation worked on sdb2 (very little free space) but failed on sda1.

https://0x0.st/XNh7.mp4
(MP4, 2MB, 25 seconds)

Do you know why it fails on sda1?

Confusing, yes, for the most because you mention 'Puppy's concept of booting' and "Puppy's bootloader installation" and members reply about that, but your video shows that it's not "Puppy" that you are trying to install, it's about a "DebianDog" test version (old stuff btw).
--------------------------------------------------------------------------------------------------------------------------------------------
New thread following up about this in the "Debiandogs" section here: viewtopic.php?t=11732 . Thanks Mike and Mike

[bigpup]

In BookwormPup64 10.0.6 I have been messing around with btrfs formatted partition.

It does seem to be supported for copy, move, delete, etc.... of data on it.

I assume this is Linux kernel btrfs driver providing this.

But I did need to install btrfs-progs to make a partition with btrfs format.
Be able to do any checks of the file system, etc......

So to me, it would not be correct to say btrfs is supported in the Puppy version, if it could not do anything with it using Gparted program.

Now it really needs some testing of all programs in BookwormPup64, to see if anything chokes on this format.

Update of a little testing.
Installed BookwormPup64 10.0.6 as frugal install on a btrfs format location.
Boot loader is on a fat32 format location.

Boots OK and generally seems workable.

1st issue is getting Rox file manager to display contents of btrfs formatted partition.
Click on desktop drive icon.
All that happens is Pmount opens. (all options are grayed out)
But the drive icon does show mount symbol on it. It does have save on it and is getting used.
Strange?
I can get Rox to display contents, if I use the desktop file icon, and navigate to /mnt/sdd2 (the btrfs partition).
Strange?

What I reported about Rox earlier, was using BookwormPup64 installed on a ext4 format, and booting from that.
Rox accessing btrfs formatted partition, seemed to work OK, by clicking the desktop drive icon for it.
Strange?

[Luluc]

Let me give you a little perspective.

My everyday machine was Debian 9 aka Stretch until February this year. With a 4.9.0 kernel. That machine was upgraded from Debian 8 aka Jessie. Stretch was released in 2017, Jessie in 2015. I still had Jessie when I formatted my disk with btrfs and have been using it since, including the boot/root partition. Not one problem at all.

Btrfs had or maybe still has a long standing problem with one specific RAID mode. Because of that, a lot of FUD has been spread around against btrfs. It kind of makes sense in an operating system that still treats desktop machines as second class citizens. Most corporate solutions rely heavily on RAID. But Puppy does not treat desktop machines as second class citizens. Please stop being afraid of btrfs or otherwise treating it like alien technology. It is very common, mature and awesome.

[Luluc]

One more thing, I can confirm that DebianDog can open a LUKS partition at boot time. It just needs a line in the /etc/crypttab file and another in the /etc/fstab file (which was empty, I don't understand that at all). Once that is done, DebianDog boots up and halts halfway through to prompt me for the password to open the partition. Then it proceeds and there it is, the partition is mounted and available.

[mikewalsh]

In BookwormPup64 10.0.6 I have been messing around with btrfs formatted partition.

It does seem to be supported for copy, move, delete, etc.... of data on it.

I assume this is Linux kernel btrfs driver providing this.

But I did need to install btrfs-progs to make a partition with btrfs format.
Be able to do any checks of the file system, etc......

So to me, it would not be correct to say btrfs is supported in the Puppy version, if it could not do anything with it using Gparted program.

Heh.

I found pretty much the same with ExFAT the other week.

It's basically supported by the kernel. However, with the exception of a few of the newest Puppies, you can't actually DO anything with it until a couple of small utility packages are installed first. THEN you can do pretty much anything you want.......so long as you don't mind using the terminal to do so.

(Because gParted still doesn't "see" it; even though the option is in the list, it remains greyed-out. Perhaps a newer build of gParted would "see" it? I need to investigate this....)

(*shrug....*)

Mike.

[bigpup]

Let me give you a little perspective.

My everyday machine was Debian 9 aka Stretch until February this year. With a 4.9.0 kernel. That machine was upgraded from Debian 8 aka Jessie. Stretch was released in 2017, Jessie in 2015. I still had Jessie when I formatted my disk with btrfs and have been using it since, including the boot/root partition. Not one problem at all.

Btrfs had or maybe still has a long standing problem with one specific RAID mode. Because of that, a lot of FUD has been spread around against btrfs. It kind of makes sense in an operating system that still treats desktop machines as second class citizens. Most corporate solutions rely heavily on RAID. But Puppy does not treat desktop machines as second class citizens. Please stop being afraid of btrfs or otherwise treating it like alien technology. It is very common, mature and awesome.

Because Puppy Linux is developed only by people volunteering to do any work on it.

It is slow to adopt new features.

If it is not broken, do not try to fix it, has worked well in developing Puppy Linux.

Plus doing good testing of something new in Puppy is slow, because the people on this forum are who has to volunteer to do the testing.

But just because something could be supported is not the best reason to support it.

Puppy Linux has never been developed based on the fact that other OS's do it, so Puppy needs to also do it.

I have shown that fully supporting btrfs requires adding more software to Puppy Linux.

Because Puppy Linux loads all of it's OS into memory. Keeping the size as small as possible is still a needed feature.

Sorry, but what feature of btrfs format does Puppy need, other than be able to maybe read/write to it?

Puppy only needs to support ntfs format, so a frugal install can be put on a Windows only setup computer, not having to reformat it.
So people can use Puppy to access data on a ntfs formatted location.
The frugal install of Puppy is a simple folder to the ntfs format.
But inside the frugal install folder is a complete Linux file system, in the different SFS files, and it is what Puppy operates in.
But ntfs format will not allow making a save folder only a save file.

But this only works well, because Puppy when booted, is now working in a Linux file system, not a ntfs file system.
The Puppy save is a Linux file system inside a save file.

[mikeslr]

You should try EasyOS, https://www.forum.puppylinux.com/viewforum.php?f=63. Maybe williwaw can point you to a download link. EasyOS is designed for security. It can run web-browsers, any application, even an entire Linux in a container. The last time I looked at it, flatpaks --which also run applications in containers-- could be installed.

I understand that you want to encrypt the volume on which the OS boots-from and require a password just to boot-up. But in the absence of that, would Zulu-encrypted directories be sufficient? Zulucrypt is available via Bookworm's synaptic package manager.

[Luluc]

You should try EasyOS, viewforum.php?f=63. Maybe williwaw can point you to a download link. EasyOS is designed for security. It can run web-browsers, any application, even an entire Linux in a container. The last time I looked at it, flatpaks --which also run applications in containers-- could be installed.

I understand that you want to encrypt the volume on which the OS boots-from and require a password just to boot-up. But in the absence of that, would Zulu-encrypted directories be sufficient? Zulucrypt is available via Bookworm's synaptic package manager.

Thank you but you don't understand the problem. I already can protect personal data. That is not the problem. The problem is I can't keep Puppy (actually Debian Dog) in an encrypted partition so the system is exposed and vulnerable to a physical attack.

[williwaw]

Thank you but you don't understand the problem. I already can protect personal data. That is not the problem. The problem is I can't keep Puppy (actually Debian Dog) in an encrypted partition so the system is exposed and vulnerable to a physical attack.

if you can download the system from a public server, why would it need to be encrypted? If you are concerned the unencrypted system could be altered after installation, one could easily figure a way to do a checksum on the sfs after booting.

Sorry, but what feature of btrfs format does Puppy need, other than be able to maybe read/write to it?

puppy doesnt "need" btrfs, but btrfs (and zfs) offer alternative ways to backup and recover files.
easier than restoring a frugal install from an ISO and copying a save backup

being a bit off topic to this thread tho, it would make for a good discussion in a different thread.

[rockedge]

The problem is I can't keep Puppy (actually Debian Dog) in an encrypted partition so the system is exposed and vulnerable to a physical attack.

physical attack as in a seized or stolen machine and able to directly access the partitions with various methods? I can see that in the "machine seized by authorities" scenario having the partitions with the OS and it's persistence mechanism encrypted would probably be an advantage.

Otherwise while the OS is running the merged layered file systems wouldn't be encrypted and could be open to attack over a network or of course physically accessed in a run state.

[dimkr]

The problem is I can't keep Puppy (actually Debian Dog) in an encrypted partition so the system is exposed and vulnerable to a physical attack.

AFAIK some things can't be encrypted (the MBR, ESP, ...) but Puppy doesn't have signed kernels or any kind of tampering protection, allowing these things to be used as an attack vector even if someone contributes encrypted partitions support to Puppy. Puppy and the Puppy-adjacent distros are probably not what you're looking for, if your threat model assumes physical access.

[mikeslr]

As soon as you go online a potential hacker has access to your computer's RAM. As soon as you decrypt anything in order to use it, it is in RAM and you've exposed it. What scenario are you considering where encryption of a partition provides greater protection to sensitive documents than merely encrypting the folder holding those documents?

If someone has physical access to your computer, what scenario do you think encrypting a partition provides greater protection than just encrypting a folder? True, encrypting the boot-partition should prevent booting the operating systems offered by the boot-loader. But AFAIK, it would not prevent altering Bios to give boot priority to a USB-port from which you can boot any Puppy; and Puppy running as Root/Administrator will have access to the hard-drives. Nor will such encryption prevent removal of the hard-drive from the computer and attaching it to a different computer.

The idea of encrypting operating systems wasn't to protect the User. It was to prevent piracy of copyrighted operating systems sold for profit.

The best defenses against hacking are a reputable VPNs and/or running web-facing applications in a container or a chroot. You'll find my post criticizing the Gramp's flatpak which requires 2.5 Gbs of framework and 1+Gbs of application to do the same thing as a 32Mb Gramps deb or pet; albeit, the Gramps flatpak runs in a container and does not have access to the rest of your system]. The only justification for flatpaks is their employment of containerization.

See my previous post for a link to EasyOS which can run anything in a container. You may also want to consider Puli, viewtopic.php?p=91395#p91395. I think version 8.1 is still 'binary compatible' to Ubuntu Focal Fossa; not sure if it's now a remaster of F96 or still fossapup64-9.5. Although it is best run from a USB-Key, it can be deployed to a hard-drive. What's significantly different about the 'Pulis' is that gjuhasz has builtin the capacity to sense attempted hacking and to take counter-measures against it. viewtopic.php?p=2555#p2555