Moderator: Forum moderators
Hi all. I seriously considered using Puppy early this year then I changed my mind and now I might change my mind again. But Puppy has so many spinoffs and I haven't kept up with it all so maybe you can help me? I would like these features:
- Complete Debian compatibility.
- Frugal install in a LUKS encrypted partition. MX/Antix claim to do that, but it doesn't really work.
Is there a puppy for me out there?
I believe neither suits my requirements. VanillaDpup doesn't even have a frugal installer and BookwormPup64 requires a FAT32 partition for a frugal installation. I only have a LUKS encrypted BTRFS partition.
BookwormPup64 requires a FAT32 partition for a frugal installation
Not sure where you got this idea.
The requirement is the bios the computer is using.
fat32 format is about the partition the boot loader is located on. The frugal install can go on any format.
Every computer bios (legacy or UEFI type) will be able to see and use a boot loader that is on a fat32 format partition, usually also flagged boot and esp.
UEFI bios is setup to look for a drive partition formatted fat32, flagged boot, esp, with the boot loader on it, as the boot partition.
It or another partition can have the frugal install on it.
Info we need.
What is the computer?
Make and model or specs if you know them?
What drive are you wanting to install on?
What partitions are on it and their format?
Does it have any other operating system on it?
Most people start by doing a live install of Puppy to a USB flash drive.
Boot with it to see how they like it.
Maybe try a few Puppy versions this way.
Some only boot Puppy this way.
But to do a good install to an internal drive, you need to use the installer programs in Puppy Linux.
So booting from Puppy on a USB provides that ability.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected 
AFAIK no Puppy supports this, Puppy only boots from "normal", unencrypted partition (no LVM, etc').
jafadmin worked on and published LUKS applications four years ago, https://oldforum.puppylinux.com/viewtop ... 1#p1049161. Should work with Puppys and debian dogs of that era, and especially FatDog. And I don't know if LotsaLuks only created encrypted directories.
I didn't see the need to explore it because of how Puppys work. Puppys boot from READ-ONLY file-systems. Their only exposure is the READ-WRITE SaveFile or Folder. And that can be replaced by a READ-Only adrv or ydrv (or both) if you use Bookworm or F-96: Menu>Utilities>nicOS-Utilities-Suite>Save2SFS*. The only things worth encrypting are your personal datafiles. And there are plenty of applications which can do that.
-=-=-=--
* amethyst withdrew the app when he left the forum but said anyone can still use it. FWIW, gnewpet, https://www.forum.puppylinux.com/viewto ... 211#p73211 can be used to obtain the app from Bookworm or F96.
I got this idea here (1.6MB, 1 minute and 20 seconds):
https://0x0.st/XNwO.mp4
It is required. There is a Linux installed there. The /boot directory is in it. Grub2 is in the MBR.
Some Puppy installers for doing live installs to only USB sticks, are setup to use fat32 format of the partition on it, because it works for any computer.
Plus manufactures usually have them already formatted fat 32. (until you get up into very large size USB sticks).
Your attachment is showing using Diskpup installer:
DiskPup
Does no partitioning or formating; The drive will need to already be partitioned and formatted.
Installs a single Puppy linux in a selected directory, and the boot loader (Grub2) in a selected "fat32" partition.
The Puppy linux directory can be on the same partition as the boot loader, or on a different partition.
The fat32 formatted partition is about providing a location for the boot loader files that any computer bios will see. (UEFI or Legacy bios type).
Your link is showing using Frugalpup Installer
If the drive is only going to have Puppy Linux frugal installs on it.
Yes the Frugalpup Installer is setup to want to do installs so that UEFI bios will boot correctly.
Most people now have computers using UEFI bios.
UEFI bios is setup to look for boot loaders installed on the first partition of a drive and it formatted fat 32.
But this also works on any very old legacy bios computers.
You need to understand that many versions of UEFI bios are in use by computers.
Older versions are not the same as newer versions.
Frugalpup Installer does not do any partitioning or formatting of a drive.
You have to first use Gparted program to do this.
This does require the drive to be setup with at least 2 partitions.
1st one small 100 to 300MB size, formatted fat32, flagged boot, esp
The boot loader is installed on it when installing the boot loader and asked where to place it.
2nd partition you use the rest of drive for.
Format it as what ever format you want.
But best to use a Linux format ext 3 or 4.
The Puppy version frugal install goes on it.
This is how I do any install to a drive, only having Puppy versions on it, using Frugalpup Installer:
(it is written for USB drives, but it works for any type drive)
viewtopic.php?t=11171
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
When you bring up this main window for Frugalpup Installer.
.
.
Click on help brings up an info page with much of what I am telling you.
.
Frugalpup Installer is more than one installer. iIt has others (stickpup ones are for USB flash drives) that is accessed from this:
.
.
The help on this also provides the info.
.
.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
Ah there is the problem. "Most people." The old problem rears its ugly head again.
By that logic, most people use Windows.
I still don't use a UEFI bios. A lot of people use old Linux on old computers especially Puppy users.
My mobo has it but I never enabled it. And I probably never will.
OK, so Puppy can't do what I need. OK. I had hopes. More and more distros offer the possibility of encrypting whole disk including root/boot. It's the right thing to do because security. If an attacker can tamper with your boot kernel or anything in your system, he can install malicious code and do anything he wants.
Maybe in the future? Who knows. See that the filesystem is LUKS and prompt for the password. Shouldn't be too difficult. I still hope.
Thank you for your time and attention.
You would be surprised how many people with computers that have very old versions of UEFI, have no idea it can be setup to run in legacy mode.
So it runs like the old legacy bios does.
Very new UEFI has option to run in CSM mode (same thing, just different name)
Frugalpup Installer can install a boot loader that works for any type bios.
Legacy or UEFI.
UEFI setup for legacy mode or CSM.
UEFI with secure boot enabled or disabled.
Even has option to install both types.
Good option, if you are installing to a USB drive, you want to be able to boot on any computer, no matter what type bios it has.
Also installing a boot loader to a drive using an msdos partition table that has an mbr area.
A drive using a gpt partition table (does not have an mbr area)
So it's boot loader installer covers all possible conditions the boot loader needs to be set up to support.
Some older legacy bios, do require the boot loader files to be on a fat32 format location, on the first partition of the drive, and it flagged boot, to tell the bios this is the location of the boot loader. Where the boot loader file is located that will takeover the boot process.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
I never had any such "older legacy bios," all computers I ever had booted from the MBR.
But OK, it's good that Puppy supports older legacy bios. No one left behind, I really like that. But is that a reason to completely reject the MBR option? How about just a Grub entry? I am actually booting off ISO images right from Grub here.
Please note you have mentioned "USB drive/stick" seven (7) times in this thread already. Which I never did. It doesn't apply to me.
MBR area of the drive has nothing to do with the bios.
MBR is an area on the drive that gets setup if the drive is using a msdos type partition table setup.
Older boot loaders always used this area, because drives always used the msdos partition table setup.
Now with drives using gpt partition table setup. Boot loaders had to adapt to what they provided for location of the boot loader files.
In frugalpup Installer it can install a boot loader for drives that have an mbr.
I am booting from one now, with a boot loader installed by Frugalpup Installer.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
If the frugalpup Installer can install a boot loader for drives that have an MBR, why does it keep complaining about the lack of a FAT32 partition? Because some old legacy bioses need that EVERYBODY has to do it that way? Is my understanding correct?
I keep talking about installing to a USB stick, because that is best way to try using Puppy Linux and making sure the version you select will work.
No single Puppy version will work on all possible computers.
That is why there are always several you could try.
Plus to do a good working install you need to be using programs in Puppy Linux to do it.
So a Puppy version, running from a USB, is how to do that.
There are Puppy versions that will not boot the computer I am using right now.
But they do work on older computer than it is.
---------------------------------------------------------------------------------------------------------------------------------------
The format of fat32 is used because any bios will see it as a possible location for the boot files.
Any type bios.
Legacy or UEFI.
UEFI bios requires a boot partition, formatted fat32 to find the boot loader files on.
All that complaining about the lack of a FAT32 partition, is so it has a place to put the boot loader, that will be found by the computers bios, boot process.
Frugalpup Installer is trying to do a good working install for any computer.
Install a boot loader that will work for any of them.
It gives 3 choices for boot loader.
UEFI
Legacy bios (mbr)
Both
Keep in mind that all bios legacy or UEFI are not the same.
Depending on what version it is.
It could work differently or even have bugs in it.
That is why there are updates to the computer bios, you could install to fix hardware support, or how it actually boots the computer.
I have a very old computer that has really old legacy bios.
If it does not see the first partition or the single partition on the drive formatted fat32, flagged boot, it does not even try to boot from it.
Even if the boot loader files are in the drives mbr area.
Get message no boot-able device found.
but if the first partition on the drive is formatted fat32, flagged boot.
The boot loader used, installs some stuff on the drives mbr area and the first partition. (this is normal for a msdos partition table setup drive)
It boots with no issues.
You know that computers started out using drives formatted fat16, then 32, then started using ntfs.
so the bios has to be coded to look for drives with a certain format to support to boot from.
Standard has been always support fat32.
That is why when Widows started using ntfs for a format. It still had a small 1st partition, formatted fat32, flagged boot, with the boot loader files on it.
All of Windows OS on the ntfs formatted partition(S).
-------------------------------------------------------------------------------------------------------------------------------------------
It is simple to make any drive properly partitioned and formatted to work in any computer any bios.
If you do not want all the drive one partition, formatted fat32.
Make two partitions on it.
1st one small size with just enough room for the boot loader files. Format fat32, flagged boot,esp.
2nd or more partition(S) any format you want.
Install the boot loader to the first partition.
The bios will see this first partition, find the boot loader file to turn over booting too, and the boot loader takes over completing the boot up of the OS.
The operating system on the 2nd or other partition(S).
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
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?
I suppose Puppy would just overwrite my Grub and disable booting from the other OSes
No, Puppy Linux will never overwrite an existing boot loader and Grub installation unless instructed too.
Puppy Linux, DebianDog and Kennel Linux variants are designed from scratch to work alongside all types of other Distros, even capable of sharing the same partition as Microsoft Windows without effecting Windows operations at all. 
there should be no problem adding a boot stanza to the existing grub.cfg to boot the DebianDog it appears that you want to use.
More and more distros offer the possibility of encrypting whole disk including root/boot. It's the right thing to do because security. If an attacker can tamper with your boot kernel or anything in your system, he can install malicious code and do anything he wants.
No not possible. Puppy Linux, DebianDog and Kennel Linux are assembled from always READ-ONLY squash file structures, It would take a super dedicated hacker and several types of scripts to modify any Puppy Linux root file system permanently.
The expert level hacker (which most are nothing but script kids) would certainly need time and energy to modify your system even without any encryption.
The popular media has you washed into thinking things will happen...but unless your machine is gateway to massive databases of peoples certain information or storing massive amounts of credit card and banking information or other data important for national security, I doubt any hacker would invest the work to be able to change your system. Even if your running system was altered a reboot into the clean system will fix that.
It would take physical contact and access too your machine to be able to really effectively alter you machine in a malicious way.
You shouldn't make claims without factual support or actual knowledge of what you are criticizing. Do not rely on others to form your opinion which you so freely share.
All of what I have been posting is to do only a Puppy version installed on a drive.
When a drive has some other Linux or Windows OS installed on it.
There is a completely different way to do the install.
Frugal install for Puppy, because a frugal can be installed anyplace, even inside another OS install.
Frugal install is all the Puppy files inside a folder.
Nothing in Puppy ever needs to be placed outside that folder.
But what boot loader the other operating system installs and needs to use could be anything.
So usually do a Puppy frugal install and do manual edit entry to whatever is used to provide the boot loader menu.
Puppy does have this boot loader that could be installed and used with multiple OS's.
viewtopic.php?t=3360
It tries to setup for all OS's it finds on the drive.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
Install failed on sda1 probably because it is using the btrfs file system (format).
no Puppy I know of has anything in it to support that btrfs format.
No reason for Puppy Linux to use it.
Puppy supports:
For sure these:
fat16 or 32
ntfs
ext 2, 3, or 4
linux swap
Some these also:
f2fs
exfat (maybe)
And this really depends on what Puppy version.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
So is sda2. But it worked on sda2.
The three Puppy I have tried can mount my BTRFS partitions. I would be VERY disappointed if they didn't. I've been using BTRFS without a single hitch for 8 years. It's hardly cutting edge tech.
No reason except it is the natural evolution of ext2,3,4 and it is fast and space efficient, has checksum checking, built-in compression and other very interesting features such as subvolumes and snapshots which have saved my day a couple of times.
This is weird. I'm used to getting in disagreements with other Linux users because they think my ideas are too antiquated. Now I get in a disagreement with you because apparently I am too modern using 10-year-old technology.
rockedge wrote: ↑Sat Jun 01, 2024 5:50 pmMore and more distros offer the possibility of encrypting whole disk including root/boot. It's the right thing to do because security. If an attacker can tamper with your boot kernel or anything in your system, he can install malicious code and do anything he wants.
No not possible. Puppy Linux, DebianDog and Kennel Linux are assembled from always READ-ONLY squash file structures, It would take a super dedicated hacker and several types of scripts to modify any Puppy Linux root file system permanently.
I am not booted into Puppy right now. I can access Puppy's changes directory which is in an unencrypted partition because it only works that way.
/live/changes/upperdir
Well, look at that. upperdir/usr/bin and upperdir/usr/sbin contain a lot of executables I installed recently. Replace any of them with a poisoned executable and there you go, I'm hacked.
Your concept of security is appalling. Hair standing on end appalling.
This is weird. I'm used to getting in disagreements with other Linux users because they think my ideas are too antiquated. Now I get in a disagreement with you because apparently I am too modern using 10-year-old technology.
Odd. BTRFS support is kernel specific. So if the kernel is configured to have the modules or support builtin the system can use BTRFS. To really fully exploit BTRFS the OS needs to be designed around it and have the kernel to support it.
Since Puppy Linux uses AUFS there has not been much attention to the functionality of BTRFS since it doesn't bring an advantage unless designed around using it.
BTRFS is not favored by some types of distros that are often found on USB flash drives because of the high levels of read-write operations BTRFS formatted partitions require. Reducing journal indexing operations helps but is not optimal since it is one of the main reasons of using it in the first place.
There's no distribution-specific considerations other than kernel version and btrfs-progs versions. With btrfs in the occasionally buggy state it's in, I would make sure to be on a recent kernel. There are some servers I oversee which I compile btrfs progs on because it's not available as an up-to-date package.
If you use openSUSE you'd probably get btrfs-related fixes before the general public as openSUSE contributes a lot to the btrfs driver and those patches get applied to the openSUSE kernel before they make it into mainline.
@BarryK is experimenting with using BTRFS for it's snapshot features among other things.
Encryption doesn't add much security, if the encrypted partition is unlocked and mounted, especially if you're running an outdated browser on top of an outdated OS full of CVEs and run this browser as root. Also, malware can infect your firmware, not files you can find on disk (Puppy doesn't have signed kernels and a hash database for tamper protection anyway), so the 'Puppy is read-only' argument is weak, very weak. Same about the 'I haven't seen malware in my Puppy system so I wasn't hacked' argument - if you don't do any auditing, don't expect to find anything, and don't expect attackers to notify you they're capturing your key strokes and stealing your credit card.
Let's not pretend that Puppy is a distro built by 100% professional developers and up to the highest code quality and security standards.
so the 'Puppy is read-only' argument is weak, very weak.
If it is about unsigned or signed kernels or any of these types of insurances I can point to the recent backdoor built into and successfully committed xz backdoor. A signed package I believe. If its coming through Firmware files then it's in every distro using those if the malicious firmware is inserted high enough upstream.
What I am saying is the squash file based OS is difficult to hack in place if no persistence is used. Takes a moment to get a key logger that phones home going, a reboot and it's poof unless it manages to infect the router or can flash itself into a device EPROM
I 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.
Same about the 'I haven't seen malware in my Puppy system so I wasn't hacked' argument - if you don't do any auditing
I do auditing once in awhile to check, Stuff has been interesting since the first worm and virus's in the MS-DOS days. Used to try to infect select isolated machines to observe how they work.....before any anti-virus programs existed. Remember the DOS "terminate and stay resident" software interrupts?
Luluc wrote: ↑Sat Jun 01, 2024 5:36 pmNow, 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?
I solved the mystery.
It turns out I am not booting off a CD or pen drive. I am booting off ISO images stored on sda1 right from Grub. That causes DebianDog to boot with sda1 mounted. Then I guess the installation script cannot understand that. When it tries to mount sda1 to copy the persistence data over, it certainly gets some error because sda1 is already mounted, and the script fails.
I solved it by moving the ISO image to sda2 and updating the Grub entry accordingly. Then DebianDog installed on sda1. Even though sda1 is BTRFS. Come on, people. BTRFS is nothing new. It's pretty awesome too.
Anyway, on the first boot it still booted into the sda2 persistence data! What in the world??!!
So I deleted the persistence data on sda2 and rebooted, and everything finally worked the way I wanted. Well, almost. I am still on a naked partition, no encryption. That sucks.
1. See my post on your thread about the problem of booting DebianDog-Bullseye-20201127 from sda1. As I pointed out there, DebianDogs aren't Puppies. It's interesting to know that they can boot from btfs partitions while Puppies can't. If you only have btfs partitions and are unwilling to create either a Linux, Fat32 or Ntfs partition, then you're initial instinct was right. Puppys aren't going to do what you want. Read no further.
2. What Puppys have you tried? My recommendations are the Mainline F96 or Bookworm64, or josejp2424's remaster of F96 named XFCE-Fusilli BETA, https://www.forum.puppylinux.com/viewtopic.php?t=10238, because they all contain the nicOS-Utilities-Suite with its Save2SFS module.
Using the Save2SFS module all settings, customizations and applications can be contained in a READ-ONLY file-system rather than the 'usual' READ-Write SaveFile or SaveFolder. They can hold even portable-web-browsers which were located in /opt. While dimkr is undoubtedly correct that there are theoretical vectors by which READ-ONLY file-systems can be compromised, rockedge is also correct that as a practical matter a hacker would have to have physical access to the computer to compromise a READ-ONLY file-system. Puppys operate in RAM, copying or mounting file-systems, which using Save2SFS are now READ-ONLY. RAM is wiped on shutdown.
A remaster of the core file-system, or the running of Save2SFS to modify an additional READ-ONLY SFS, deleting the core or additional SFS, substituting the 'new versions' all without your knowledge that this is taking place would have to happen.
If you operate only with READ-ONLY file-systems after boot-up from a USB-Key, you can unplug the Key. Hard to compromise an operating system which isn't there. After boot-up from a hard-drive it is dismounted. Puppys run as root,with access to all partitions. You can always copy the specific files you want from RAM to a different partition than that which Puppy booted from, never having to mount that partition. Exactly how can such system be compromised? Without your knowledge? By anyone other than a hacker dedicated to compromising your operating system?
Now add a reputable VPN to the mix so that your internet work is entirely encrypted during transmission from source to destination.
I have Bookworm64. It's OK, but I think DebianDog is a much better polished product. Are the others you mentioned Debian too? I began this thread saying that I need 100% Debian compatibility. I came to Puppy because 1. frugal install 2. it's so well polished and nice to use in comparison with other distros.
I find the whole Save2SFS confusing. Do you have a link to a good page that explains it all? For example, can I save the changes during a session? Programatically? How?
All of you who say that Puppy is secure seem to dismiss the possibility of physical attack. But that is my one concern. I am not afraid of the internet. I am afraid of having my machine stolen with personal data in it. As it is, Puppy is very much compromised. It's not secure at all. At all. Using it on a notebook is suicide.
Last, but not least, I don't believe in VPNs. They are not secure either.
Qv supports brtfs and can be installed frugally
not polished, its still in alpha
nor is it debian based
what kind of encryption do you have working on btrfs?
viewtopic.php?p=118240#p118240