About Crypt Save, Grub4DOS and ext2/3/4

[Luluc]

I hope you don't mind I pack three different questions into one thread.

1. In Bookworm Debian Dog, menu Accessories (Openbox), there is an entry called Crypt Save Utility. I am sure I didn't install it. When I click it, a terminal window opens and that's it. Nothing happens. But it's not any of the lame terminal applications that every maintainer likes to pre-install. It's the cool terminal I use (configured as default terminal in Openbox). What do you people know about that menu entry?

2. I have been doing some experimenting with an old BusterDog on a VM and have a problem with Grub4DOS. BusterDog can't find my changes at boot. I need to edit the boot menu accordingly. But how do I do that with Grub4DOS? Puppies usually provide a GUI for these things but looks like there isn't any this time. Bookworm Dog works for me because it's on bare metal, sharing a partition with another Linux where I can install and configure regular Grub2.

3. The VM where BusterDog is installed had a BTRFS partition and BusterDog refused to create the "changes" directory there. It worked after I formatted the partition as ext2. That was by design and has been fixed in later versions, right? Bookworm Dog doesn't seem to mind my choice of BTRFS partitions.

[fredx181]

I hope you don't mind I pack three different questions into one thread.

1. In Bookworm Debian Dog, menu Accessories (Openbox), there is an entry called Crypt Save Utility. I am sure I didn't install it. When I click it, a terminal window opens and that's it. Nothing happens. But it's not any of the lame terminal applications that every maintainer likes to pre-install. It's the cool terminal I use (configured as default terminal in Openbox). What do you people know about that menu entry?

2. I have been doing some experimenting with an old BusterDog on a VM and have a problem with Grub4DOS. BusterDog can't find my changes at boot. I need to edit the boot menu accordingly. But how do I do that with Grub4DOS? Puppies usually provide a GUI for these things but looks like there isn't any this time. Bookworm Dog works for me because it's on bare metal, sharing a partition with another Linux where I can install and configure regular Grub2.

3. The VM where BusterDog is installed had a BTRFS partition and BusterDog refused to create the "changes" directory there. It worked after I formatted the partition as ext2. That was by design and has been fixed in later versions, right? Bookworm Dog doesn't seem to mind my choice of BTRFS partitions.

No positive answers at all from me, sorry
1) : the Crypt Save Utility (from package "move-in-crypt", FYI, it's for to modify an encrypted savefile) was once made by a ex co-developer, it is not maintained anymore (I will remove "move-in-crypt" soon from the (some) mklive configs).
2) and 3) : Busterdog isn't maintained anymore (at least not by me) and TBH I cannot answer, as I don't know much about VM's and BTRFS.

[fredx181]

@Luluc
Saw your post here: viewtopic.php?p=136425#p136425 , it is confusing (and off-topic) as the screenshot shows not an "old puppy" (it's probably "old doggy" )
Anyway, about move-on-crypt, as I said, it's obsolete, but here's a script for to edit contents of an encrypted save-file (requires one argument e.g. /path/to/encrypted-savefile):
edit: and requires "cryptsetup" in PATH
edit2: similar as option 3 in move-on-crypt

Code: Select all

#!/bin/bash
echo "usage: $(basename $0) /path/to/encrypted-savefile"
[ -z "$1" ] && exit
SAVEFILENAME="$1"
P=${SAVEFILENAME%/*}
F=${SAVEFILENAME##*/}
echo "Enter the password for $P/$F and press Enter."
losetup /dev/loop6 $P/$F
cryptsetup luksOpen /dev/loop6 crpt
mkdir /mnt/temp
mount /dev/mapper/crpt /mnt/temp
echo -e "Open filemanager in /mnt/temp \nAnd edit things to your heart's content."
read -s -n 1 -p "Press any key to continue . . ."
echo
umount /mnt/temp
rm -fr /mnt/temp
cryptsetup luksClose crpt
losetup -d /dev/loop6
echo "Done. $P/$F unmounted."

[Luluc]

"Old doggy," yes, OK I guess. It was obtained in this canine community so I referred to it as a "old puppy" as shorthand.
(It's Bullseye BTW.)

Sorry if my post was confusing. But so is the entire issue of encryption in puppies and doggies.

You share a script to edit contents of an encrypted save-file. OK. Thanks. But I still don't understand:

1. Is 01-filesystem.squashfs a save file? Can I encrypt it? How?
2. Can the "changes" directory be encrypted?
3. Your script edits contents of an encrypted save-file. But how does one create an encrypted save-file?
4. Can we convert an unencrypted save-file into an encrypted save-file?
5. Are adjustements necessary for a puppy and a doggy to boot correctly or read an encrypted save-file?
6. If it is possible to encrypt a save-file, why is that topic discussed so seldom? There isn't a lot of information in the forum. Why is such an important feature left out of all frugal installers? It's pretty out of character for a community that pays so much attention to detail. Encryption is like personal hygiene.

[fredx181]

@Luluc You could have seen in the Menu or elsewhere "Create Save ... " or something.

EDIT:
1. 01-filesystem.squash is not a savefile
2. Not for use with booting, only with encrypted save-file
3. In Menu > Create SaveFile and check "Encrypt the savefile"
4. Yes, by mounting both and copy content from unencrypted > encrypted
5. Point changes=/... to the savefile in the boot stanza, e.g. changes=/live/changes.dat or changes=/live/saveme according to the name you gave it
(edit: will be detected if it's encrypted and will ask for password)
6. Probably not very popular

EDIT2: Mmmm... just tested booting with encrypted savefile on FossaDog and it doesn't work, perhaps has to do with the newer kernel I use (5.15), dont know.

[mikewalsh]

6. If it is possible to encrypt a save-file, why is that topic discussed so seldom? There isn't a lot of information in the forum. Why is such an important feature left out of all frugal installers? It's pretty out of character for a community that pays so much attention to detail. Encryption is like personal hygiene.

@Luluc :-

I can't speak for the "Dogs". But as far as Puppies are concerned, the option is NOT provided at install time.....rather, it's offered at first shutdown, when the "save" is normally created. Why would you offer the option to encrypt something that doesn't yet exist? Remember, Puppies/Dogs/etc offered on this Forum are almost all intended to be run as 'frugal' systems; taking up minimum space, co-existing happily on the same partition as another OS. Our systems are not the same as a mainstream distro - invariably, a FULL install to a dedicated partition, where everything needs to be set up AT install time - and our installers reflect this singular difference.

The way that OSs offered on this forum are built & designed to work, they're the closest thing to a single-use, disposable OS you will ever find......IF the user wishes to run them in such a manner.

As for 'personal hygiene', well; I can't say anything about that, either. Encryption IS very much a personal choice, it's true.....but I DO know that, over the years, many have tried that option. And almost to a man, those individuals have found it to be more trouble than it's worth.

You can take security/privacy TOO far. The only truly SECURE computer is one that's unplugged/disconnected from the mains and the 'net, encased in a block of concrete and chucked in the bottom of a deep lake. And you never, ever go anywhere near it.

Drastic? Yes. Practical? Mmm.....not very. But it serves to illustrate just how interconnected the world is.....and the lengths one has to go to in order to truly NOT be a part of it.

(*shrug...*)

Mike.

[fredx181]

@Luluc

@Luluc You could have seen in the Menu or elsewhere "Create Save ... " or something.

Apologies , I see now that "Create Savefile" isn't always appearing in the Menu (at least it's not on FossaDog).

EDIT2: Mmmm... just tested booting with encrypted savefile on FossaDog and it doesn't work, perhaps has to do with the newer kernel I use (5.15), dont know.

Couldn't stand that so did some digging and found that it works ok when the SaveFile creator makes an encrypted savefile with luks version 1 (default version 2 failed booting with it).
To fix on FossaDog, install new version (0.0.8) of package porteusbootscripts : apt update; apt install porteusbootscripts (has updated script /usr/local/bin/mk-save.gtkdlg for to create save)
After that run; mk-save.gtkdlg from terminal for to create savefile (encrypted (select checkbox) or not).

EDIT:

I can't speak for the "Dogs". But as far as Puppies are concerned, the option is NOT provided at install time.....rather, it's offered at first shutdown, when the "save" is normally created.

In the "Dogs", it's handled for both (option offered at shutdown if booted without save and by running createsave (mk-save.gtkdlg) in the middle of a session.

[Luluc]

@fredx181

Thanks!

But I'm still confused.

You talk about "booting with encrypted savefile on FossaDog."
What exactly is "savefile" in this context?

As a FossaDogger, I only know
k-5.4.0-53-generic.squashfs
01-filesystem.squashfs
changes directory

You previously said that 01-filesystem.squashfs is not a savefile.
What is this savefile you mention then? Where does it fit in the FossaDog scheme? How exactly can I benefit from it?

[Luluc]

The only truly SECURE computer is one that's unplugged/disconnected from the mains and the 'net, encased in a block of concrete and chucked in the bottom of a deep lake. Drastic? Yes. Practical? Mmm.....not very. But it serves to illustrate just how interconnected the world is.....and the lengths one has to go to in order to truly NOT be a part of it.

@mikewalsh

Encryption isn't supposed to protect a machine from the internet. It's supposed to protect the machine - or rather the data in the machine - from physical theft. It is especially important for notebooks but also applies to desktops.

[fredx181]

Thanks!

But I'm still confused.

You talk about "booting with encrypted savefile on FossaDog."
What exactly is "savefile" in this context?

As a FossaDogger, I only know
k-5.4.0-53-generic.squashfs
01-filesystem.squashfs
changes directory

You previously said that 01-filesystem.squashfs is not a savefile.
What is this savefile you mention then? Where does it fit in the FossaDog scheme? How exactly can I benefit from it?

You have two options for save storage, boot with a save-folder (as you have now, "changes directory") or with a save-file (a savefile works also if located on e.g. FAT32 formatted partition and can be encrypted, a save folder not),
edit: so, you can possibly benefit by using encrypted savefile.
A savefile must be created first and specified on the boot command line, if it's named changes.dat (default), e.g. changes=/casper/changes.dat (edit: this for FossaDog, Debiandog has "live' instead of 'casper')
As opposed for a save-folder, it would be just changes=/casper/ (the 'changes' folder will be automatically created there)

EDIT: Writing and updating documentation isn't my strongest talent
All this stuff has been much discussed though in the (old) forum in the past and some info can be found in "Examples-boot-codes.txt" in any DD ISO.

[dancytron]

So you can only encrypt the changes.dat file and not 01-filesystem.squashfs?

[fredx181]

So you can only encrypt the changes.dat file and not 01-filesystem.squashfs?

Maybe you can encrypt 01-filesystem.squashfs (don't know) but then cannot be used to boot with AFAIK.
edit: to encrypt changes.dat is more of importance I'd say, as it may contain personal stuff like remembered passwords from e.g. browser etc.. or whatever secret.

[mikewalsh]

The only truly SECURE computer is one that's unplugged/disconnected from the mains and the 'net, encased in a block of concrete and chucked in the bottom of a deep lake. Drastic? Yes. Practical? Mmm.....not very. But it serves to illustrate just how interconnected the world is.....and the lengths one has to go to in order to truly NOT be a part of it.

@mikewalsh

Encryption isn't supposed to protect a machine from the internet. It's supposed to protect the machine - or rather the data in the machine - from physical theft. It is especially important for notebooks but also applies to desktops.

Oh, I know exactly what encryption is for, AND what it does. Perhaps I should have worded the statement "unplugged from the mains (if a desktop), unplugged from mains & battery removed (if a laptop), AND disconnected from the 'net".....if you're pernickety enough to insist on everything being worded precisely and exactly correct.

The object being - of course - to render said machine totally inert and incapable of functioning. And THEN encasing it in concrete.....and THEN throwing it in said lake. I assumed - perhaps wrongly - that most members here would know what I meant, and what I was getting at. I guess it all depends on how much you enjoy hair-splitting & nit-picking.

Mike.

[fredx181]

The only truly SECURE computer is one that's unplugged/disconnected from the mains and the 'net, encased in a block of concrete and chucked in the bottom of a deep lake. Drastic? Yes. Practical? Mmm.....not very. But it serves to illustrate just how interconnected the world is.....and the lengths one has to go to in order to truly NOT be a part of it.

@mikewalsh

Encryption isn't supposed to protect a machine from the internet. It's supposed to protect the machine - or rather the data in the machine - from physical theft. It is especially important for notebooks but also applies to desktops.

Oh, I know exactly what encryption is for, AND what it does. Perhaps I should have worded the statement "unplugged from the mains (if a desktop), unplugged from mains & battery removed (if a laptop), AND disconnected from the 'net".....if you're pernickety enough to insist on everything being worded precisely and exactly correct.

The object being - of course - to render said machine totally inert and incapable of functioning. And THEN encasing it in concrete.....and THEN throwing it in said lake. I assumed - perhaps wrongly - that most members here would know what I meant, and what I was getting at. I guess it all depends on how much you enjoy hair-splitting & nit-picking.

Mike.

It seems that you are talking about encryption / security in general.
The subject is IMO just about encrypted save, which may have the good purpose that someone using your computer to boot Puppy/Dog needs to enter password to have access to your (personal) save storage.
edit: and about security in general, sure, very talented hackers can possibly compromise (or whatever) your system, but that doesn't mean that you should 'not at all' be concerned about security.

[Luluc]

So you can only encrypt the changes.dat file and not 01-filesystem.squashfs?

Thank you for saving me a question!

about security in general, sure, very talented hackers can possibly compromise (or whatever) your system, but that doesn't mean that you should 'not at all' be concerned about security.

Hear, hear!

edit: to encrypt changes.dat is more of importance I'd say, as it may contain personal stuff like remembered passwords from e.g. browser etc.. or whatever secret.

On that I have to disagree with you. Everything in changes/ or changes.dat will end up in 01-filesystem.squashfs after a remaster (which I do often). BOTH are extremely privacy-sensitive.

You have two options for save storage, boot with a save-folder (as you have now, "changes directory") or with a save-file (a savefile works also if located on e.g. FAT32 formatted partition and can be encrypted, a save folder not)

OK, I'm interested.
Would you happen to know some technical details on the save file? What kind of file is it, a loopback device? It has to have a file system, right? What is it? Is it faster or slower than a save directory? Is it compressed in any way? Am I annoying you with too many questions?

[fredx181]

edit: to encrypt changes.dat is more of importance I'd say, as it may contain personal stuff like remembered passwords from e.g. browser etc.. or whatever secret.

On that I have to disagree with you. Everything in changes/ or changes.dat will end up in 01-filesystem.squashfs after a remaster (which I do often). BOTH are extremely privacy-sensitive.

Yes, that's right after remastering, I was talking about a "pristine" 01-filesystem.squashfs
Btw, there is a way to create an uncommon setup by copying all from 01-filesystem.squashfs into a (huge) changes.dat container and disable 01-filesystem.squashfs by renaming to 01-filesystem.squashfs.bak. So then in fact you boot with the contents of changes.dat (or whatever it's named) (that will break the purpose of quick-remaster of course).
EDIT: Then it's sort of a "pseudo full install". See related: viewtopic.php?p=115490#p115490 (but that is with a directory (no encryption) and for newest Debiandog only)
But I'd suggest that you first boot using the common setup with savefile.

You have two options for save storage, boot with a save-folder (as you have now, "changes directory") or with a save-file (a savefile works also if located on e.g. FAT32 formatted partition and can be encrypted, a save folder not)

Would you happen to know some technical details on the save file? What kind of file is it, a loopback device? It has to have a file system, right? What is it? Is it faster or slower than a save directory? Is it compressed in any way? Am I annoying you with too many questions?

It's a container with a Linux filesystem inside, not compressed and can be loop mounted (read-write). edit: booting with encrypted save increases boot time as it takes time to continue after entering password.
Unencrypted changes.dat:

Code: Select all

# file changes.dat
changes.dat: Linux rev 1.0 ext4 filesystem data, UUID=733af854-304a-4c65-9e79-8974054c82ec (extents) (huge files)

Encrypted changes.dat:

Code: Select all

# file changes.dat
changes.dat: LUKS encrypted file, ver 1 [aes, xts-plain64, sha256] UUID: ac6d71ab-53ad-4199-a0ba-bb78ca5a0ef1, at 0x1000 data, 32 key bytes, MK digest 0xa05dcac656883d774f741679190c6f8e184ed886, MK salt 0x1442613ff40a9870dc9c789b9dd985533b8906b4782a19d31a67d4122cdf5a48, 631250 MK iterations; slot #0 active, 0x8 material offset

Am I annoying you with too many questions?

Depends on my mood Sometimes I think you can research or try things yourself first instead of asking.

[Luluc]

Sometimes I think you can research or try things yourself first instead of asking.

If one can research, it's only because questions have been asked and answered publicly. Without those, there would be no content for research.

[fredx181]

Sometimes I think you can research or try things yourself first instead of asking.

If one can research, it's only because questions have been asked and answered publicly. Without those, there would be no content for research.

Well, ok, ask ahead, however the results that you can accomplish from the info I gave would be good to share though, otherwise it's just some written info from me, but that's okay also.

[Luluc]

Thanks!

I just booted with a brand new encrypted changes.dat file. I feel more hygienic already! It takes longer to boot up, but it's worth it.

Two new questions:

1. Hypothetically, suppose I make my changes.dat file with a certain size and I fear it may be too small. And I want to resize it. But it's in use. Can that be done on the fly?

2. Do you suppose we could use another file system type for the changes.dat file? I am strongly partial to btrfs.

I have this on my 'df -h':
/dev/mapper/crypt 2.4G 21M 2.2G 1% /mnt/live/memory/changes

Man, I just booted and there is only 21MB of data in it. Obviously, ext4 is taking up 200MB of it! It's their default 10% reserved to journaling, isn't it? Wasteful. This is one of the reasons why I ditched ext3 and 4 a long time ago.

Their journaling system is overrated anyway. I've lost data on ext3/4 half a dozen times. Only once with btrfs.

Even xfs would be better. I've never seen xfs lose data. Of course it happens. I've had an entire partition go corrupt. Incredibly, I managed to recover it entirely with help from their official mailing list, but it was such a scary experience (although I had backups) that I hit the road and never looked back. But I consider it good enough for a save file since I remaster very frequently. Btrfs would the best though.

Puppies and Doggies are usually so stingy with storage space. Sometimes, I even disagree with it. (The aggressive "cleaning" in quick-remaster.) We shouldn't be wasting so much space on journaling with old, obsolete file systems. Will you please think about it?

I see that mk-save.gtkdlg is a script. I'm examining it. There seems to be an XML part for the GUI that would maybe let the user choose the file system type. But there is no such option in the GUI when I run it. Is that removed on purpose?

It seems that $FS is the variable that defines the file system type, but I can't find the line where FS is set.

Well, I guess I can hack (and hardcode) the line that establishes ext4, but can you foretell any problems or incompatibilities if I change it to btrfs?

[Luluc]

Hey, that was fast.

.
.
.
Upon reboot...
.
.

.
.
Ah, the joys of ext3/4. Yes, that's exactly how I remember it.

[Luluc]

I hacked the script to use btrfs. There were errors during the save file creation, the tool definitely expects ext2/3/4, but looks like it worked. It boots and seems to hold changes across reboots. Also:

/dev/mapper/crypt 2.5G 28M 2.5G 2% /mnt/live/memory/changes

Much better space use too.

[fredx181]

@Luluc

I see that mk-save.gtkdlg is a script. I'm examining it. There seems to be an XML part for the GUI that would maybe let the user choose the file system type. But there is no such option in the GUI when I run it. Is that removed on purpose?

The function mk_save() { ... is for when booted using live-boot, isn't used on FossaDog
The function mk_pfile() { ... is for porteus-boot (initrd1.xz) that you use.

Looking at your screenshots:
No idea where the dpkg problem (read-only filesystem) comes from.
I use the 5.15 kernel on Fossadog (you 5.4) (perhaps that could make a difference ) and haven't had problems with the changes.dat containing ext4

I hacked the script to use btrfs. There were errors during the save file creation, the tool definitely expects ext2/3/4, but looks like it worked. It boots and seems to hold changes across reboots.

I did the same to test, didn't see errors during creation (btw, I installed btrfsprogs, replaced in the script mkfs.ext4 with mkfs.btrfs and also e2fsck -f with btrfsck --repair).
At boot, although it does work ok with btrfs, it fails to do the filesystem check (skipped), the initrd doesn't support that.

[Luluc]

Looking at your screenshots:
No idea where the dpkg problem (read-only filesystem) comes from.

The file system got corrupted mid flight and rolled into a ball like an armadillo, i.e. it went into read-only mode. The ext4 fs does that.

[fredx181]

Looking at your screenshots:
No idea where the dpkg problem (read-only filesystem) comes from.

The file system got corrupted mid flight and rolled into a ball like an armadillo, i.e. it went into read-only mode. The ext4 fs does that.

And if you use save-folder on what filesystem is that ?
And would ext2 be better in your opinion ?

[Luluc]

My changes save directory was on a btrfs partition. I always use btrfs, never use ext2/3/4 for anything.
Technically, btrfs is kind of an ext5. But it's a lot better. Some FUD has been spread about it so many people are still reluctant to use it. But it was all about a very specific RAID problem. It's better.

[fredx181]

@Luluc

I did the same to test, didn't see errors during creation (btw, I installed btrfsprogs, replaced in the script mkfs.ext4 with mkfs.btrfs and also e2fsck -f with btrfsck --repair)

Really don't know much about btrfs. So now I'm asking you questions
I've read that --repair for btrfs is not recommended, do you think it's needed to check (and possibly repair) at creation time of the savefile ?

At boot, although it does work ok with btrfs, it fails to do the filesystem check (skipped), the initrd doesn't support that.

Had a look how to change that but don't know how, is it a problem that it skips checking the btrfs .dat container ?

[Luluc]

So now I'm asking you questions

Good for a change.

I've read that --repair for btrfs is not recommended, do you think it's needed to check (and possibly repair) at creation time of the savefile ?

is it a problem that it skips checking the btrfs .dat container ?

I'm not an expert, but I never do that checking, even on regular mounting. Might be a good idea for mounting, I will have a look at that myself. But not for creation, no. I know this much, on 'man btrfsck' the --repair option is listed under DANGEROUS OPTIONS. I am going to find out why. We should probably not use it.

BTW, while you're reading up on btrfs, check out subvolumes. It's good stuff and may be relevant to canine interests. Beware of compression though. I think it's a little slow.

[Luluc]

New problem: quick-remaster is not working anymore.
It runs, it says it's going to do the deed, one second later it says it's done and offers to reboot.
But the new squashfs file is not created.
I am running it from the command line to capture the output. But there are no errors in the output.

I am not sure, but this may be the first I time I remaster since I changed from a "changes" directory to a changes.dat file. Which is encrypted. And formatted as btrfs.
Do you have any idea why it's failing?

- changes.dat file
- encrypted
- btrfs
One of these things is tripping quick-remaster up.

I can see I have a lot of update data in /mnt/live/memory/changes but no /mnt/live/memory/images/changes-exit directory, which the script seems to expect.

I can't see any reason in the script for encryption to be a problem. The content is fully unencrypted at runtime.

I also don't see any assumptions pertaining to the file system type.

I'm stumped.

[fredx181]

@Luluc
I tested with btrfs encrypted savefile and found that quick-remaster fails in case aufs is being used: mount -t aufs -o br:"$BRANCH":tmp1 none tmpa/
That should be only when you boot with extra modules, besides the kernel module and chose for not merge extra modules. (did you?)

I suspect that aufs doesn't support adding a btrfs filesystem layer, anyway not compiled in the kernel to support it, don't know exactly.

Solution can be: Boot without the extra modules or if you do, choose for to merge the extra modules (will be except kernel module).

Newer Debiandog systems use overlayfs instead of aufs. Perhaps it does support btrfs, didn't test.

Edit: Ooops... wasn't thinking straight, on second thought I wondered why btrfs works with aufs to add the changes layer from init stage and not with quick-remaster.
And found that changing the line in quick-remastergui: mount -t aufs -o br:"$BRANCH":tmp1 none tmpa/ to:
mount -t aufs -o nowarn_perm,xino=/mnt/live/memory/xino/.aufs.xino,br:"$BRANCH":tmp1 aufs tmpa
fixes it from what I tested (can't really explain though, just experimented with similar from what's in the init script).

[Luluc]

It worked. Thank you again!