Created a fossapup64_9.5 boot USB memory stick with e3StickPup

[Governor]

The standard FrugalPup failed, but I had success with e3StickPup.
Created a fossapup64_9.5 boot USB memory stick with e3StickPup. I booted from it. How can I tell if it really did boot from the thumb drive and not some other location?

None of my drives in pMount have a lock icon. That strikes me as odd. I only worked a short time so far, but the GUI seems faster than before.

Ok, it looks like I answered my own question.
The UUID: "bb0ff474-57ff-4e7a-84b3-17c2ffb8a21e" matches the UUID of the drive listed in blkid, so it looks like it really did boot from the thumb drive.
Amazing, and all I did was run the program after installing the PET. Go figure.

I was told that I would be offered a chance to save my configuration settings on shutdown. How can I confirm this? I was told I could save my settings manually without shutdown or reboot, does that apply here?
Thanks!

[bigpup]

e3StickPup
Formats and installs a single Puppy to a usb stick, in a small "fat32" partition and a large Linux "ext3" partition.

This makes two partitions on the drive.

Have you tried to shutdown and see if it offers to make a save and offers the USB drive as the place to put it?

It may give you a selection of different locations to place the save.
Different drives (partitions) it sees on the computer.
The partitions of the USB stick will be one of them.
(usually it auto highlights the USB stick partition to select) But still make sure it is correct one.

What you want to select is the 2nd partition on the USB drive. The ext3 formatted one.
This allows making a save folder on it, because it is a Linux format.

Before shutting down.

Look on the desktop drive icons for the ones for the USB stick you are booting from.

If only one USB drive is plugged into the computer. Usually it is sdb drive.

If you have other USB drives or internal drives. You will need to figure out what their desktop drive icons are, so you know it is not that one.

Example may be sdb1 and sdb2 for the USB stick.

sdb2 would be the one to select to place the save on.

-------------------------------------------------------------------------------------------------------------------------------------------------
First time you boot with the USB install.
It will not lock the drive partition, because there is nothing being used, that is still on the partition.
It is all in memory.

After you place a save on the USB stick.
Boot using the save.
The partition the save is on will be locked and not able to UN-mount.

[bigpup]

I was told I could save my settings manually without shutdown or reboot, does that apply here?

Must do this first.
After you do first shutdown and make a save.
Boot using it.

You should have a save icon on the desktop.

Clicking it at anytime, will manually update the save, with anything that has been changed.

In menu ->System ->Puppy event Manager ->Save Session
It gives options for how you want the save to update.

[bigpup]

If you are seeing options in the boot menu to boot RAM only.
Example: menuentry "fossapup64 9.5 - RAM only"
Do not use this entry.
That tells the boot process to never use the save.

The first boot menu entry should be a normal boot.
Use it.

Puppy always loads everything into RAM when it boots.
Except the save. It only loads into the file system.

A boot menu entry that uses nocopy option, does not load into memory anything but what actually needs to be in memory, to run Puppy.

[williwaw]

How can I confirm this? I was told I could save my settings manually without shutdown or reboot, does that apply here?
Thanks!

yes, but not on your first boot, only on subsequent boots.

https://forum.puppylinux.com/viewtopic.php?t=5484

Boot parameters:
pmedia=<atahd|ataflash|usbhd|usbflash|cd>
Indicates the type of boot device.
If it's "cd" then the partitions are searched for a save layer file, the only situation that triggers such a search.*
If the first 3 characters are "usb", then any searching is restricted to only usb devices.
If the last 5 characters are "flash" the top layer in the stack remains the tmpfs in memory, otherwise any found save layer becomes the top layer in the stack.
This boot parameter should always be provided.

once you are booted......
on the first partition of your thumbdrive, in grub.cfg, line 18. change pmedia=usbhd to pmedia=usbflash and you will see a new save icon on the desktop on subsequent boots

* concerning CD boots......
its not a bug, its a documented feature!

[Governor]

* concerning CD boots......
its not a bug, its a documented feature!

Yes, I have been informed of this perspective (which is shared by many). One man's bug is another man's feature. It is what it is.
Cheers!

[Governor]

How can I confirm this? I was told I could save my settings manually without shutdown or reboot, does that apply here?
Thanks!

yes, but not on your first boot, only on subsequent boots.

https://forum.puppylinux.com/viewtopic.php?t=5484

Boot parameters:
pmedia=<atahd|ataflash|usbhd|usbflash|cd>
Indicates the type of boot device.
[/size][/b]

8<-------snipped--------

If the first 3 characters are "usb", then any searching is restricted to only usb devices.
If the last 5 characters are "flash" the top layer in the stack remains the tmpfs in memory, otherwise any found save layer becomes the top layer in the stack.
This boot parameter should always be provided.

once you are booted......
on the first partition of your thumbdrive, in grub.cfg, line 18. change pmedia=usbhd to pmedia=usbflash and you will see a new save icon on the desktop on subsequent boots
8<-------snipped--------

Thanks. Did that. If there is another USB that is mounted and has system files on it, will the files from the second USB be loaded instead of the system files on the boot USB (CD behavior)? I just want to make sure.

[bigpup]

You seem to have the setup that actually tests all this.

USB booting should only look on the USB stick booting from for files.

About the CD booting and using files from another location than the CD.

Any of these other (drives) locations you have the Fossapup64 9.5 SFS files.

Are the SFS files just on a drives partition or are they in a directory or folder?

[Governor]

You seem to have the setup that actually tests all this.

USB booting should only look on the USB stick booting from for files.

About the CD booting and using files from another location than the CD.

Any of these other (drives) locations you have the Fossapup64 9.5 SFS files.

Are the SFS files just on a drives partition or are they in a directory or folder?

A funny thing, I tried booting from my closed CD and it failed.

On the thumb drive, I changed "pmedia=usbflash" back to "pmedia=usbhd" and rebooted, but there is no change in the locked external USB drives, or Thunderbird behavior.

Save folders:
/mnt/nvme0n1p2/fossapup64save-2024_06_02_pupsave (time stamp 22.42:15)
/mnt/nvme0n1p2/fossapup64save-2024_06_02_pupsave.BKP-2024.06.03-19.41 (time stamp 14.49:01)
/mnt/nvme0n1p2/fossapup64initmodules.txt

I found this,and I don't know how it got there:
/mnt/nvme0n1p1/zz_initrd_tmp

Found this:
/mnt/nvme0n1p3/lost+found

How does the boot process select which folder to use? If it is the first physical location where system files are found, how do I replicate that in Rox?
I know from experience that the sort in Rox does not sort correctly by alph-numeric.

[geo_c]

You seem to have the setup that actually tests all this.

USB booting should only look on the USB stick booting from for files.

I'm not clear as to why you had him change pmedia to flash, was that so he has a save icon?

Seems to me @Governor should have it writing as it goes, not needing to do anything to make a save.

If he was getting saved settings on the USB to begin with, he should stick with that, and then delete all those files on his other drives and begin a solid internal drive install.

This is the sidetrack that keeps happening since day one, to which my advice has always been run only ONE OS from the USB and examine how it saves on that install partition and in it's own directory, then configure a second boot internally, and learn how to move that save to the internal install, or use pupsave backup to put his save on the internal drive.

Slowly....with ordered steps.

and @Governor, it's very simple to test whether you have a save. Make a blank text file, put in a location like /root/Documents, shutdown and reboot. If on reboot the file is still there, you are saving your changes.

If you want to see where they are saved then navigate to /mnt/home/[pupinstall-folder-name] and you should see a folder (or sfs file -- hopefully not a file, but rather a folder) called fossapup64save-{something or other]. That's your save, and that's what can be eventually copied to a brand new clean install of fossapup64 on your nvme.

[Governor]

You seem to have the setup that actually tests all this.

USB booting should only look on the USB stick booting from for files.

I'm not clear as to why you had him change pmedia to flash, was that so he has a save icon?

Seems to me @Governor should have it writing as it goes, not needing to do anything to make a save.

If he was getting saved settings on the USB to begin with, he should stick with that, and then delete all those files on his other drives and begin a solid internal drive install.

This is the sidetrack that keeps happening since day one, to which my advice has always been run only ONE OS from the USB and examine how it saves on that install partition and in it's own directory, then configure a second boot internally, and learn how to move that save to the internal install, or use pupsave backup to put his save on the internal drive.

Slowly....with ordered steps.

and @Governor, it's very simple to test whether you have a save. Make a blank text file, put in a location like /root/Documents, shutdown and reboot. If on reboot the file is still there, you are saving your changes.

If you want to see where they are saved then navigate to /mnt/home/[pupinstall-folder-name] and you should see a folder (or sfs file -- hopefully not a file, but rather a folder) called fossapup64save-{something or other]. That's your save, and that's what can be eventually copied to a brand new clean install of fossapup64 on your nvme.

Fine for me to start with the thumb drive.

I would like the save folder to be saved to the thumb drive I am booting from, so it is independent of the internal drive, and portable, so I can boot from a different computer. Plus, I would like to have the option of booting into RAM.only mode. For both options, I would like to be able to save on demand and save on shutdown/reboot. I really don't want automatic saves. I can decide that for myself.

How do I set that up? I only have 14GB on the ext format, but that should be enough to get started.
Thanks..

[geo_c]

Fine for me to start with the thumb drive.

I would like the save folder to be saved to the thumb drive I am booting from, so it is independent of the internal drive, and portable, so I can boot from a different computer. Plus, I would like to have the option of booting into RAM.only mode. For both options, I would like to be able to save on demand and save on shutdown/reboot. I really don't want automatic saves. I can decide that for myself.

How do I set that up? I only have 14GB on the ext format, but that should be enough to get started.
Thanks..

Will need to see the present boot stanzas on the USB drive. Since it's a thumb drive and it looks like the pmedia=usbflash should be right.

But honestly, I would to have put fossapup64_9.5 on two different drives and test it to really know where this is happening, and that still wouldn't replicate your setup.

I have some ideas, but not enough info.

So what I'd need is the USB boot stanzas, a screenshot or even just copying the terminal text of your directory structure of all connected drives, something like

nvme
......./fossapup64_9.5
................adrv.sfs
................ydrv.sfs
................initrd
................whatever else is here
fossapup64save-whatever_name

In other words all the files at least one level deep on that drive presently and the same for the other drives. You might have a screenshot of that already buried in a topic.

Then the boot stanzas on the USB, and any information about other boot partitions you might have like on the nvme. Are you certain from the boot messages that it's booting from USB?

But there is another option you could try:

One thing I still don't understand: If booting from USB is acceptable for you, why keep fossapup system files on the other drives? You could boot into RAM using USB, move the saves you have on the internal drive to your USB stick, but create folders and put them a couple of levels deep where they won't be found on boot, like /mnt/home/filesystems/f95/gov-saves/internal-drive/archive/fossapup64save-govs_save

Or better yet, after moving them, rename those files also with a prefix so they don't get loaded: BKP_fossapup64save-govs_save

And then delete all those puppy.sfs files, the initrd, the pdrv.sfs and any other puppy system files from nvme, so that there are no other files for the USB boot to load.

And of course detach any other external drives that have these files on them.

Then reboot and see what happens.

And if you really want to eliminate the confusion, erase the boot partition from your nvme, so we know that somehow it's not doing the actual booting.

This is the goal, reconfiguring your computer's internal drive so it's truly useful again. If that's not your goal, and you want to boot from USB with the nvme loaded with puppy system files, it's gonna take a lot of careful fiddling to set up a circumstance where you get a predictable boot.

Somehow you have to figure out how to use process of elimination to get to the boot you want.

[Governor]

Fine for me to start with the thumb drive.

I would like the save folder to be saved to the thumb drive I am booting from, so it is independent of the internal drive, and portable, so I can boot from a different computer. Plus, I would like to have the option of booting into RAM.only mode. For both options, I would like to be able to save on demand and save on shutdown/reboot. I really don't want automatic saves. I can decide that for myself.

How do I set that up? I only have 14GB on the ext format, but that should be enough to get started.
Thanks..

Will need to see the present boot stanzas on the USB drive. Since it's a thumb drive and it looks like the pmedia=usbflash should be right.

But honestly, I would to have put fossapup64_9.5 on two different drives and test it to really know where this is happening, and that still wouldn't replicate your setup.

I have some ideas, but not enough info.

So what I'd need is the USB boot stanzas, a screenshot or even just copying the terminal text of your directory structure of all connected drives, something like

nvme
......./fossapup64_9.5
................adrv.sfs
................ydrv.sfs
................initrd
................whatever else is here
fossapup64save-whatever_name

In other words all the files at least one level deep on that drive presently and the same for the other drives. You might have a screenshot of that already buried in a topic.

Then the boot stanzas on the USB, and any information about other boot partitions you might have like on the nvme. Are you certain from the boot messages that it's booting from USB?

But there is another option you could try:

One thing I still don't understand: If booting from USB is acceptable for you, why keep fossapup system files on the other drives? You could boot into RAM using USB, move the saves you have on the internal drive to your USB stick, but create folders and put them a couple of levels deep where they won't be found on boot, like /mnt/home/filesystems/f95/gov-saves/internal-drive/archive/fossapup64save-govs_save

Or better yet, after moving them, rename those files also with a prefix so they don't get loaded: BKP_fossapup64save-govs_save

And then delete all those puppy.sfs files, the initrd, the pdrv.sfs and any other puppy system files from nvme, so that there are no other files for the USB boot to load.

And of course detach any other external drives that have these files on them.

Then reboot and see what happens.

And if you really want to eliminate the confusion, erase the boot partition from your nvme, so we know that somehow it's not doing the actual booting.

This is the goal, reconfiguring your computer's internal drive so it's truly useful again. If that's not your goal, and you want to boot from USB with the nvme loaded with puppy system files, it's gonna take a lot of careful fiddling to set up a circumstance where you get a predictable boot.

Somehow you have to figure out how to use process of elimination to get to the boot you want.

After my last boot, I was unable to unmount internal drive 4 where I keep my portable programs, ie. Firefox, Thunderbird, LibreOffice, Palemoon, Brave, VLC, Audacity. There was a hidden process running.

Unable to unmount nvme0n1p4.png (522.82 KiB) Viewed 412 times

I removed all system files on internal partitions, and rebooted from the thumb drive. The first 3 internal drive partitions have no files at all.
My external drives can mount in pMount, but are not writable, just as before. So no change there.

[Governor]

Will need to see the present boot stanzas on the USB drive. Since it's a thumb drive and it looks like the pmedia=usbflash should be right.
.....
So what I'd need is the USB boot stanzas, a screenshot or even just copying the terminal text of your directory structure of all connected drives, something like

nvme
......./fossapup64_9.5
................adrv.sfs
................ydrv.sfs
................initrd
................whatever else is here
fossapup64save-whatever_name

In other words all the files at least one level deep on that drive presently and the same for the other drives. You might have a screenshot of that already buried in a topic.

Then the boot stanzas on the USB, and any information about other boot partitions you might have like on the nvme. Are you certain from the boot messages that it's booting from USB?

Here is my BLKID output:

Code: Select all

/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/nvme0n1p1: UUID="0444-3DB8" TYPE="vfat" PARTLABEL="Primary_boot" PARTUUID="b6d29dd8-b4e8-494d-9c93-67f6b7c99557"
/dev/nvme0n1p2: LABEL="ext4rootMX23" UUID="492a310a-74af-4127-9159-afa17b6702e9" TYPE="ext4" PARTLABEL="puppyinstall" PARTUUID="e9b97f54-0ba4-4ff9-9e06-730900b8f08b"
/dev/nvme0n1p3: LABEL="ext3boot" UUID="b242c9da-fe12-440c-9ba8-10b581c2fe61" TYPE="ext3" PARTLABEL="nvme-ext3" PARTUUID="8a791e82-a418-40ed-8e44-bddbb957a440"
/dev/nvme0n1p4: LABEL="ext4-backup" UUID="52d8efaf-bdf6-4281-aeea-871217161d5c" TYPE="ext4" PARTUUID="385429a0-db55-4ce2-a8b9-88650005821f"
/dev/nvme0n1p5: LABEL="ext4-downloads2" UUID="774e807b-c247-4c3f-8181-164459de7173" TYPE="ext4" PARTUUID="e64ee91d-a089-4142-ac88-f24dc8e105b2"
/dev/nvme0n1p6: LABEL="ext3downloads" UUID="96415f7e-7b92-43fd-9f57-fcf09523fb6e" TYPE="ext3" PARTLABEL="ext3 downloads" PARTUUID="0325422a-00fd-4c7e-a04c-6d8762622dd2"
/dev/sda1: LABEL_FATBOOT="dosd992288c" LABEL="dosd992288c" UUID="8FB0-0686" TYPE="vfat" PARTUUID="d992288c-01"
/dev/sda2: LABEL="lind992288c" UUID="bb0ff474-57ff-4e7a-84b3-17c2ffb8a21e" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="d992288c-02"
/dev/sdb1: LABEL="T7" UUID="F00F-1D48" TYPE="exfat" PARTUUID="ea6d421c-01"
/dev/sdc1: LABEL="c-drv+I-bak" UUID="F67A373A7A36F6C9" TYPE="ntfs" PTTYPE="atari" PARTUUID="b4871312-01"
/dev/sdc2: LABEL="Win+Linux_bak" UUID="0840718640717B70" TYPE="ntfs" PARTUUID="b4871312-02"

My puppy boot thumb has 2 partitions: sda1 and sda2. I put blkid.txt there.

Thumb drive sda1 and sda2 (boot).png (227.38 KiB) Viewed 398 times

GRUB.CFG

Code: Select all

set default=0
set timeout=10

set menu_color_normal='yellow/blue'
set menu_color_highlight='black/cyan'

if [ $grub_platform = 'efi' ]; then
  loadfont /boot/grub/fonts/DejaVuSansMono18.pf2
  set gfxmode=auto
  terminal_output gfxterm
fi

menuentry "Puppy fossapup64 9.5" {
  insmod ext2
  search --no-floppy --fs-uuid --set=root bb0ff474-57ff-4e7a-84b3-17c2ffb8a21e
  echo "Loading vmlinuz"
  linux /pups/fossapup64/vmlinuz net.ifnames=0 pmedia=usbhd  pdrv=lind992288c psubdir=/pups/fossapup64 pfix=fsck,fsckp TZ=XXX1
  if [ -e /pups/fossapup64/local-initrd.gz ]; then
    set local_rd=/pups/fossapup64/local-initrd.gz
  else
    set local_rd=
  fi
  if [ -e /pups/fossapup64/ucode.cpio ]; then
    set ucode_rd=/pups/fossapup64/ucode.cpio
    echo "Loading ucode.cpio and initrd.gz"
  else
    set ucode_rd=
    echo "Loading initrd.gz"
  fi
  initrd $ucode_rd /pups/fossapup64/initrd.gz $local_rd
}
if [ $grub_platform = 'efi' ]; then
  menuentry "System BIOS setup" {
    fwsetup
  }
fi
menuentry "Shutdown computer" {
  halt
}
menuentry "Reboot computer" {
  reboot
}

MENU.1ST

Code: Select all

timeout 0
default 0

title grub2
  kernel /boot/grub/i386-pc/core.img

[Governor]

Will need to see the present boot stanzas on the USB drive. Since it's a thumb drive and it looks like the pmedia=usbflash should be right.
..........
So what I'd need is the USB boot stanzas, a screenshot or even just copying the terminal text of your directory structure of all connected drives,
.........

sda1 file list:

Code: Select all

.:
total 222
drwxr-xr-x  4 root root   1024 Jan  1  1970 .
drwxr-xr-x 19 root root    200 Jun  7 10:17 ..
-rwxr-xr-x  1 root root   1517 Jun  7 10:06 blkid.txt
drwxr-xr-x  3 root root    512 Oct 20  2019 boot
drwxr-xr-x  3 root root    512 Feb  3  2020 EFI
-rwxr-xr-x  1 root root 220049 Mar 29  2015 grldr
-rwxr-xr-x  1 root root   1078 Jun  6 16:53 grub.cfg
-rwxr-xr-x  1 root root      0 Jun  7 11:10 ls.txt
-rwxr-xr-x  1 root root     75 Feb  1  2020 menu.lst
-rwxr-xr-x  1 root root    774 Jan  7  2020 puppy.cer

./boot:
total 2
drwxr-xr-x 3 root root  512 Oct 20  2019 .
drwxr-xr-x 4 root root 1024 Jan  1  1970 ..
drwxr-xr-x 4 root root  512 Oct 29  2019 grub

./boot/grub:
total 23
drwxr-xr-x 4 root root   512 Oct 29  2019 .
drwxr-xr-x 3 root root   512 Oct 20  2019 ..
drwxr-xr-x 2 root root   512 Oct 29  2019 fonts
-rwxr-xr-x 1 root root    66 Nov 13  2018 grub.cfg
-rwxr-xr-x 1 root root  1024 Oct 28  2019 grubenv
drwxr-xr-x 2 root root 19968 Oct 29  2019 i386-pc

./boot/grub/fonts:
total 111
drwxr-xr-x 2 root root    512 Oct 29  2019 .
drwxr-xr-x 4 root root    512 Oct 29  2019 ..
-rwxr-xr-x 1 root root 112585 Nov 25  2019 DejaVuSansMono18.pf2

./boot/grub/i386-pc:
total 1989
drwxr-xr-x 2 root root  19968 Oct 29  2019 .
drwxr-xr-x 4 root root    512 Oct 29  2019 ..
-rwxr-xr-x 1 root root  10688 Oct 28  2019 acpi.mod
-rwxr-xr-x 1 root root   1392 Oct 28  2019 adler32.mod
-rwxr-xr-x 1 root root   5720 Oct 28  2019 affs.mod
-rwxr-xr-x 1 root root   6264 Oct 28  2019 afs.mod
-rwxr-xr-x 1 root root  15828 Oct 28  2019 ahci.mod
-rwxr-xr-x 1 root root    704 Oct 28  2019 all_video.mod
-rwxr-xr-x 1 root root   1104 Oct 28  2019 aout.mod
-rwxr-xr-x 1 root root   3008 Oct 28  2019 archelp.mod
-rwxr-xr-x 1 root root   5704 Oct 28  2019 ata.mod
-rwxr-xr-x 1 root root   4248 Oct 28  2019 at_keyboard.mod
-rwxr-xr-x 1 root root   1712 Oct 28  2019 backtrace.mod
-rwxr-xr-x 1 root root   6916 Oct 28  2019 bfs.mod
-rwxr-xr-x 1 root root   4732 Oct 28  2019 biosdisk.mod
-rwxr-xr-x 1 root root   2320 Oct 28  2019 bitmap.mod
-rwxr-xr-x 1 root root   3816 Oct 28  2019 bitmap_scale.mod
-rwxr-xr-x 1 root root   2124 Oct 28  2019 blocklist.mod
-rwxr-xr-x 1 root root    512 Oct 28  2019 boot.img
-rwxr-xr-x 1 root root   2500 Oct 28  2019 boot.mod
-rwxr-xr-x 1 root root  30584 Oct 28  2019 bsd.mod
-rwxr-xr-x 1 root root   2476 Oct 28  2019 bswap_test.mod
-rwxr-xr-x 1 root root  18592 Oct 28  2019 btrfs.mod
-rwxr-xr-x 1 root root   2212 Oct 28  2019 bufio.mod
-rwxr-xr-x 1 root root   2984 Oct 28  2019 cat.mod
-rwxr-xr-x 1 root root   4100 Oct 28  2019 cbfs.mod
-rwxr-xr-x 1 root root   3672 Oct 28  2019 cbls.mod
-rwxr-xr-x 1 root root   2596 Oct 28  2019 cbmemc.mod
-rwxr-xr-x 1 root root   1200 Oct 28  2019 cbtable.mod
-rwxr-xr-x 1 root root   2928 Oct 28  2019 cbtime.mod
-rwxr-xr-x 1 root root   3548 Oct 28  2019 chain.mod
-rwxr-xr-x 1 root root   3140 Oct 28  2019 cmdline_cat_test.mod
-rwxr-xr-x 1 root root   1288 Oct 28  2019 cmosdump.mod
-rwxr-xr-x 1 root root   1940 Oct 28  2019 cmostest.mod
-rwxr-xr-x 1 root root   2064 Oct 28  2019 cmp.mod
-rwxr-xr-x 1 root root   4740 Oct 28  2019 cmp_test.mod
-rwxr-xr-x 1 root root   3809 Oct 28  2019 command.lst
-rwxr-xr-x 1 root root   2336 Oct 28  2019 configfile.mod
-rwxr-xr-x 1 root root  26523 Oct 29  2019 core.img
-rwxr-xr-x 1 root root   2844 Oct 28  2019 cpio_be.mod
-rwxr-xr-x 1 root root   2776 Oct 28  2019 cpio.mod
-rwxr-xr-x 1 root root   1796 Oct 28  2019 cpuid.mod
-rwxr-xr-x 1 root root   1728 Oct 28  2019 crc64.mod
-rwxr-xr-x 1 root root  10216 Oct 28  2019 cryptodisk.mod
-rwxr-xr-x 1 root root    936 Oct 28  2019 crypto.lst
-rwxr-xr-x 1 root root   5008 Oct 28  2019 crypto.mod
-rwxr-xr-x 1 root root   3952 Oct 28  2019 cs5536.mod
-rwxr-xr-x 1 root root   1888 Oct 28  2019 ctz_test.mod
-rwxr-xr-x 1 root root   1860 Oct 28  2019 datehook.mod
-rwxr-xr-x 1 root root   2256 Oct 28  2019 date.mod
-rwxr-xr-x 1 root root   1316 Oct 28  2019 datetime.mod
-rwxr-xr-x 1 root root  10708 Oct 28  2019 diskfilter.mod
-rwxr-xr-x 1 root root   2480 Oct 28  2019 disk.mod
-rwxr-xr-x 1 root root   1100 Oct 28  2019 div.mod
-rwxr-xr-x 1 root root   5724 Oct 28  2019 div_test.mod
-rwxr-xr-x 1 root root   1916 Oct 28  2019 dm_nv.mod
-rwxr-xr-x 1 root root   5448 Oct 28  2019 drivemap.mod
-rwxr-xr-x 1 root root   2028 Oct 28  2019 echo.mod
-rwxr-xr-x 1 root root   6356 Oct 28  2019 efiemu32.o
-rwxr-xr-x 1 root root   9784 Oct 28  2019 efiemu64.o
-rwxr-xr-x 1 root root  24296 Oct 28  2019 efiemu.mod
-rwxr-xr-x 1 root root  16316 Oct 28  2019 ehci.mod
-rwxr-xr-x 1 root root   4220 Oct 28  2019 elf.mod
-rwxr-xr-x 1 root root   1516 Oct 28  2019 eval.mod
-rwxr-xr-x 1 root root   5460 Oct 28  2019 exfat.mod
-rwxr-xr-x 1 root root   1536 Oct 28  2019 exfctest.mod
-rwxr-xr-x 1 root root   6280 Oct 28  2019 ext2.mod
-rwxr-xr-x 1 root root   4620 Oct 28  2019 extcmd.mod
-rwxr-xr-x 1 root root   6456 Oct 28  2019 f2fs.mod
-rwxr-xr-x 1 root root   5572 Oct 28  2019 fat.mod
-rwxr-xr-x 1 root root  17296 Oct 28  2019 file.mod
-rwxr-xr-x 1 root root  10320 Oct 28  2019 font.mod
-rwxr-xr-x 1 root root   2728 Oct 28  2019 freedos.mod
-rwxr-xr-x 1 root root   3048 Oct 28  2019 fshelp.mod
-rwxr-xr-x 1 root root    219 Oct 28  2019 fs.lst
-rwxr-xr-x 1 root root  34416 Oct 28  2019 functional_test.mod
-rwxr-xr-x 1 root root   1744 Oct 28  2019 gcry_arcfour.mod
-rwxr-xr-x 1 root root   8292 Oct 28  2019 gcry_blowfish.mod
-rwxr-xr-x 1 root root  34208 Oct 28  2019 gcry_camellia.mod
-rwxr-xr-x 1 root root  16552 Oct 28  2019 gcry_cast5.mod
-rwxr-xr-x 1 root root  10744 Oct 28  2019 gcry_crc.mod
-rwxr-xr-x 1 root root  19380 Oct 28  2019 gcry_des.mod
-rwxr-xr-x 1 root root   2352 Oct 28  2019 gcry_dsa.mod
-rwxr-xr-x 1 root root   3016 Oct 28  2019 gcry_idea.mod
-rwxr-xr-x 1 root root   3244 Oct 28  2019 gcry_md4.mod
-rwxr-xr-x 1 root root   3864 Oct 28  2019 gcry_md5.mod
-rwxr-xr-x 1 root root   2592 Oct 28  2019 gcry_rfc2268.mod
-rwxr-xr-x 1 root root  19300 Oct 28  2019 gcry_rijndael.mod
-rwxr-xr-x 1 root root   8316 Oct 28  2019 gcry_rmd160.mod
-rwxr-xr-x 1 root root   2172 Oct 28  2019 gcry_rsa.mod
-rwxr-xr-x 1 root root  15484 Oct 28  2019 gcry_seed.mod
-rwxr-xr-x 1 root root  17080 Oct 28  2019 gcry_serpent.mod
-rwxr-xr-x 1 root root   8020 Oct 28  2019 gcry_sha1.mod
-rwxr-xr-x 1 root root   4420 Oct 28  2019 gcry_sha256.mod
-rwxr-xr-x 1 root root   9296 Oct 28  2019 gcry_sha512.mod
-rwxr-xr-x 1 root root  12760 Oct 28  2019 gcry_tiger.mod
-rwxr-xr-x 1 root root  37348 Oct 28  2019 gcry_twofish.mod
-rwxr-xr-x 1 root root  24960 Oct 28  2019 gcry_whirlpool.mod
-rwxr-xr-x 1 root root  25308 Oct 28  2019 gdb.mod
-rwxr-xr-x 1 root root   5996 Oct 28  2019 geli.mod
-rwxr-xr-x 1 root root   4980 Oct 28  2019 gettext.mod
-rwxr-xr-x 1 root root  39368 Oct 28  2019 gfxmenu.mod
-rwxr-xr-x 1 root root   2960 Oct 28  2019 gfxterm_background.mod
-rwxr-xr-x 1 root root   5092 Oct 28  2019 gfxterm_menu.mod
-rwxr-xr-x 1 root root  10092 Oct 28  2019 gfxterm.mod
-rwxr-xr-x 1 root root   3900 Oct 28  2019 gptsync.mod
-rwxr-xr-x 1 root root   8880 Oct 28  2019 gzio.mod
-rwxr-xr-x 1 root root   4556 Oct 28  2019 halt.mod
-rwxr-xr-x 1 root root   5292 Oct 28  2019 hashsum.mod
-rwxr-xr-x 1 root root   6700 Oct 28  2019 hdparm.mod
-rwxr-xr-x 1 root root   1276 Oct 28  2019 hello.mod
-rwxr-xr-x 1 root root   2664 Oct 28  2019 help.mod
-rwxr-xr-x 1 root root   3236 Oct 28  2019 hexdump.mod
-rwxr-xr-x 1 root root   7108 Oct 28  2019 hfs.mod
-rwxr-xr-x 1 root root   3100 Oct 28  2019 hfspluscomp.mod
-rwxr-xr-x 1 root root   7888 Oct 28  2019 hfsplus.mod
-rwxr-xr-x 1 root root   5628 Oct 28  2019 http.mod
-rwxr-xr-x 1 root root   2928 Oct 28  2019 iorw.mod
-rwxr-xr-x 1 root root   8648 Oct 28  2019 iso9660.mod
-rwxr-xr-x 1 root root   6168 Oct 28  2019 jfs.mod
-rwxr-xr-x 1 root root   6376 Oct 28  2019 jpeg.mod
-rwxr-xr-x 1 root root   5080 Oct 28  2019 keylayouts.mod
-rwxr-xr-x 1 root root   2044 Oct 28  2019 keystatus.mod
-rwxr-xr-x 1 root root   6608 Oct 28  2019 ldm.mod
-rwxr-xr-x 1 root root  30052 Oct 28  2019 legacycfg.mod
-rwxr-xr-x 1 root root  14536 Oct 28  2019 legacy_password_test.mod
-rwxr-xr-x 1 root root   5704 Oct 28  2019 linux16.mod
-rwxr-xr-x 1 root root  13228 Oct 28  2019 linux.mod
-rwxr-xr-x 1 root root   5848 Oct 28  2019 loadenv.mod
-rwxr-xr-x 1 root root   3056 Oct 28  2019 loopback.mod
-rwxr-xr-x 1 root root   4872 Oct 28  2019 lsacpi.mod
-rwxr-xr-x 1 root root   2352 Oct 28  2019 lsapm.mod
-rwxr-xr-x 1 root root   1940 Oct 28  2019 lsmmap.mod
-rwxr-xr-x 1 root root   3980 Oct 28  2019 ls.mod
-rwxr-xr-x 1 root root   4928 Oct 28  2019 lspci.mod
-rwxr-xr-x 1 root root   6820 Oct 28  2019 luks.mod
-rwxr-xr-x 1 root root   6808 Oct 28  2019 lvm.mod
-rwxr-xr-x 1 root root   5188 Oct 28  2019 lzopio.mod
-rwxr-xr-x 1 root root   3316 Oct 28  2019 macbless.mod
-rwxr-xr-x 1 root root   7624 Oct 28  2019 macho.mod
-rwxr-xr-x 1 root root   2124 Oct 28  2019 mda_text.mod
-rwxr-xr-x 1 root root   2084 Oct 28  2019 mdraid09_be.mod
-rwxr-xr-x 1 root root   2012 Oct 28  2019 mdraid09.mod
-rwxr-xr-x 1 root root   2036 Oct 28  2019 mdraid1x.mod
-rwxr-xr-x 1 root root   2092 Oct 28  2019 memdisk.mod
-rwxr-xr-x 1 root root   2920 Oct 28  2019 memrw.mod
-rwxr-xr-x 1 root root   3544 Oct 28  2019 minicmd.mod
-rwxr-xr-x 1 root root   3984 Oct 28  2019 minix2_be.mod
-rwxr-xr-x 1 root root   3820 Oct 28  2019 minix2.mod
-rwxr-xr-x 1 root root   3920 Oct 28  2019 minix3_be.mod
-rwxr-xr-x 1 root root   3788 Oct 28  2019 minix3.mod
-rwxr-xr-x 1 root root   3852 Oct 28  2019 minix_be.mod
-rwxr-xr-x 1 root root   3756 Oct 28  2019 minix.mod
-rwxr-xr-x 1 root root   8620 Oct 28  2019 mmap.mod
-rwxr-xr-x 1 root root   5563 Oct 28  2019 moddep.lst
-rwxr-xr-x 1 root root   2455 Oct 28  2019 modinfo.sh
-rwxr-xr-x 1 root root   2468 Oct 28  2019 morse.mod
-rwxr-xr-x 1 root root  27764 Oct 28  2019 mpi.mod
-rwxr-xr-x 1 root root   2528 Oct 28  2019 msdospart.mod
-rwxr-xr-x 1 root root   2084 Oct 28  2019 mul_test.mod
-rwxr-xr-x 1 root root  15620 Oct 28  2019 multiboot2.mod
-rwxr-xr-x 1 root root  14160 Oct 28  2019 multiboot.mod
-rwxr-xr-x 1 root root   4240 Oct 28  2019 nativedisk.mod
-rwxr-xr-x 1 root root  48632 Oct 28  2019 net.mod
-rwxr-xr-x 1 root root   3032 Oct 28  2019 newc.mod
-rwxr-xr-x 1 root root   6744 Oct 28  2019 nilfs2.mod
-rwxr-xr-x 1 root root 107180 Oct 28  2019 normal.mod
-rwxr-xr-x 1 root root   4460 Oct 28  2019 ntfscomp.mod
-rwxr-xr-x 1 root root   9948 Oct 28  2019 ntfs.mod
-rwxr-xr-x 1 root root   2620 Oct 28  2019 ntldr.mod
-rwxr-xr-x 1 root root   2840 Oct 28  2019 odc.mod
-rwxr-xr-x 1 root root   1584 Oct 28  2019 offsetio.mod
-rwxr-xr-x 1 root root  10504 Oct 28  2019 ohci.mod
-rwxr-xr-x 1 root root   1740 Oct 28  2019 part_acorn.mod
-rwxr-xr-x 1 root root   1968 Oct 28  2019 part_amiga.mod
-rwxr-xr-x 1 root root   2220 Oct 28  2019 part_apple.mod
-rwxr-xr-x 1 root root   2852 Oct 28  2019 part_bsd.mod
-rwxr-xr-x 1 root root   1848 Oct 28  2019 part_dfly.mod
-rwxr-xr-x 1 root root   1564 Oct 28  2019 part_dvh.mod
-rwxr-xr-x 1 root root   2460 Oct 28  2019 part_gpt.mod
-rwxr-xr-x 1 root root    111 Oct 28  2019 partmap.lst
-rwxr-xr-x 1 root root   2416 Oct 28  2019 part_msdos.mod
-rwxr-xr-x 1 root root   1876 Oct 28  2019 part_plan.mod
-rwxr-xr-x 1 root root   1600 Oct 28  2019 part_sun.mod
-rwxr-xr-x 1 root root   1692 Oct 28  2019 part_sunpc.mod
-rwxr-xr-x 1 root root     17 Oct 28  2019 parttool.lst
-rwxr-xr-x 1 root root   4712 Oct 28  2019 parttool.mod
-rwxr-xr-x 1 root root   1960 Oct 28  2019 password.mod
-rwxr-xr-x 1 root root   2896 Oct 28  2019 password_pbkdf2.mod
-rwxr-xr-x 1 root root   4824 Oct 28  2019 pata.mod
-rwxr-xr-x 1 root root   1544 Oct 28  2019 pbkdf2.mod
-rwxr-xr-x 1 root root   2248 Oct 28  2019 pbkdf2_test.mod
-rwxr-xr-x 1 root root   2548 Oct 28  2019 pcidump.mod
-rwxr-xr-x 1 root root   1464 Oct 28  2019 pci.mod
-rwxr-xr-x 1 root root  11452 Oct 28  2019 pgp.mod
-rwxr-xr-x 1 root root   6520 Oct 28  2019 plan9.mod
-rwxr-xr-x 1 root root   2608 Oct 28  2019 play.mod
-rwxr-xr-x 1 root root   7528 Oct 28  2019 png.mod
-rwxr-xr-x 1 root root   1628 Oct 28  2019 priority_queue.mod
-rwxr-xr-x 1 root root   2728 Oct 28  2019 probe.mod
-rwxr-xr-x 1 root root   2448 Oct 28  2019 procfs.mod
-rwxr-xr-x 1 root root   2276 Oct 28  2019 progress.mod
-rwxr-xr-x 1 root root   2732 Oct 28  2019 pxechain.mod
-rwxr-xr-x 1 root root   3908 Oct 28  2019 pxe.mod
-rwxr-xr-x 1 root root   1488 Oct 28  2019 raid5rec.mod
-rwxr-xr-x 1 root root   2372 Oct 28  2019 raid6rec.mod
-rwxr-xr-x 1 root root   2876 Oct 28  2019 random.mod
-rwxr-xr-x 1 root root   1980 Oct 28  2019 rdmsr.mod
-rwxr-xr-x 1 root root   1516 Oct 28  2019 read.mod
-rwxr-xr-x 1 root root   1788 Oct 28  2019 reboot.mod
-rwxr-xr-x 1 root root  51484 Oct 28  2019 regexp.mod
-rwxr-xr-x 1 root root   9124 Oct 28  2019 reiserfs.mod
-rwxr-xr-x 1 root root  14960 Oct 28  2019 relocator.mod
-rwxr-xr-x 1 root root   4248 Oct 28  2019 romfs.mod
-rwxr-xr-x 1 root root   4820 Oct 28  2019 scsi.mod
-rwxr-xr-x 1 root root   3184 Oct 28  2019 search_fs_file.mod
-rwxr-xr-x 1 root root   3240 Oct 28  2019 search_fs_uuid.mod
-rwxr-xr-x 1 root root   3188 Oct 28  2019 search_label.mod
-rwxr-xr-x 1 root root   3756 Oct 28  2019 search.mod
-rwxr-xr-x 1 root root   7216 Oct 28  2019 sendkey.mod
-rwxr-xr-x 1 root root   7796 Oct 28  2019 serial.mod
-rwxr-xr-x 1 root root    708 Oct 28  2019 setjmp.mod
-rwxr-xr-x 1 root root   1772 Oct 28  2019 setjmp_test.mod
-rwxr-xr-x 1 root root   5424 Oct 28  2019 setpci.mod
-rwxr-xr-x 1 root root   5236 Oct 28  2019 sfs.mod
-rwxr-xr-x 1 root root   2644 Oct 28  2019 shift_test.mod
-rwxr-xr-x 1 root root   6544 Oct 28  2019 signature_test.mod
-rwxr-xr-x 1 root root   2196 Oct 28  2019 sleep.mod
-rwxr-xr-x 1 root root   2372 Oct 28  2019 sleep_test.mod
-rwxr-xr-x 1 root root   2156 Oct 28  2019 spkmodem.mod
-rwxr-xr-x 1 root root   7152 Oct 28  2019 squash4.mod
-rwxr-xr-x 1 root root   2288 Oct 28  2019 strtoull_test.mod
-rwxr-xr-x 1 root root  17368 Oct 28  2019 syslinuxcfg.mod
-rwxr-xr-x 1 root root   3384 Oct 28  2019 tar.mod
-rwxr-xr-x 1 root root    202 Oct 28  2019 terminal.lst
-rwxr-xr-x 1 root root   4416 Oct 28  2019 terminal.mod
-rwxr-xr-x 1 root root  12072 Oct 28  2019 terminfo.mod
-rwxr-xr-x 1 root root   1408 Oct 28  2019 test_blockarg.mod
-rwxr-xr-x 1 root root   2772 Oct 28  2019 testload.mod
-rwxr-xr-x 1 root root   5100 Oct 28  2019 test.mod
-rwxr-xr-x 1 root root   2396 Oct 28  2019 testspeed.mod
-rwxr-xr-x 1 root root   5440 Oct 28  2019 tftp.mod
-rwxr-xr-x 1 root root   4536 Oct 28  2019 tga.mod
-rwxr-xr-x 1 root root   1580 Oct 28  2019 time.mod
-rwxr-xr-x 1 root root   1764 Oct 28  2019 trig.mod
-rwxr-xr-x 1 root root   2468 Oct 28  2019 tr.mod
-rwxr-xr-x 1 root root   3632 Oct 28  2019 truecrypt.mod
-rwxr-xr-x 1 root root   1276 Oct 28  2019 true.mod
-rwxr-xr-x 1 root root   8532 Oct 28  2019 udf.mod
-rwxr-xr-x 1 root root   5836 Oct 28  2019 ufs1_be.mod
-rwxr-xr-x 1 root root   5484 Oct 28  2019 ufs1.mod
-rwxr-xr-x 1 root root   5548 Oct 28  2019 ufs2.mod
-rwxr-xr-x 1 root root   6664 Oct 28  2019 uhci.mod
-rwxr-xr-x 1 root root   3912 Oct 28  2019 usb_keyboard.mod
-rwxr-xr-x 1 root root  10632 Oct 28  2019 usb.mod
-rwxr-xr-x 1 root root   7164 Oct 28  2019 usbms.mod
-rwxr-xr-x 1 root root   2112 Oct 28  2019 usbserial_common.mod
-rwxr-xr-x 1 root root   2428 Oct 28  2019 usbserial_ftdi.mod
-rwxr-xr-x 1 root root   2760 Oct 28  2019 usbserial_pl2303.mod
-rwxr-xr-x 1 root root   1608 Oct 28  2019 usbserial_usbdebug.mod
-rwxr-xr-x 1 root root   3668 Oct 28  2019 usbtest.mod
-rwxr-xr-x 1 root root   9944 Oct 28  2019 vbe.mod
-rwxr-xr-x 1 root root   2564 Oct 28  2019 verifiers.mod
-rwxr-xr-x 1 root root   5144 Oct 28  2019 vga.mod
-rwxr-xr-x 1 root root   2252 Oct 28  2019 vga_text.mod
-rwxr-xr-x 1 root root   5768 Oct 28  2019 video_bochs.mod
-rwxr-xr-x 1 root root   6184 Oct 28  2019 video_cirrus.mod
-rwxr-xr-x 1 root root   5760 Oct 28  2019 video_colors.mod
-rwxr-xr-x 1 root root  21200 Oct 28  2019 video_fb.mod
-rwxr-xr-x 1 root root   4048 Oct 28  2019 videoinfo.mod
-rwxr-xr-x 1 root root     33 Oct 28  2019 video.lst
-rwxr-xr-x 1 root root   6168 Oct 28  2019 video.mod
-rwxr-xr-x 1 root root   2452 Oct 28  2019 videotest_checksum.mod
-rwxr-xr-x 1 root root   4336 Oct 28  2019 videotest.mod
-rwxr-xr-x 1 root root   1572 Oct 28  2019 wrmsr.mod
-rwxr-xr-x 1 root root   7532 Oct 28  2019 xfs.mod
-rwxr-xr-x 1 root root  27488 Oct 28  2019 xnu.mod
-rwxr-xr-x 1 root root   2208 Oct 28  2019 xnu_uuid.mod
-rwxr-xr-x 1 root root   2084 Oct 28  2019 xnu_uuid_test.mod
-rwxr-xr-x 1 root root  15748 Oct 28  2019 xzio.mod
-rwxr-xr-x 1 root root   5652 Oct 28  2019 zfscrypt.mod
-rwxr-xr-x 1 root root   6712 Oct 28  2019 zfsinfo.mod
-rwxr-xr-x 1 root root  40656 Oct 28  2019 zfs.mod
-rwxr-xr-x 1 root root  46044 Oct 28  2019 zstd.mod

./EFI:
total 2
drwxr-xr-x 3 root root  512 Feb  3  2020 .
drwxr-xr-x 4 root root 1024 Jan  1  1970 ..
drwxr-xr-x 2 root root  512 Feb 27  2020 boot

./EFI/boot:
total 10347
drwxr-xr-x 2 root root     512 Feb 27  2020 .
drwxr-xr-x 3 root root     512 Feb  3  2020 ..
-rwxr-xr-x 1 root root 1065120 Jun  9  2019 bootia32.efi
-rwxr-xr-x 1 root root 1322936 Jun  9  2019 bootx64.efi
-rwxr-xr-x 1 root root      66 Nov 13  2018 grub.cfg
-rwxr-xr-x 1 root root 2514424 Feb  1  2020 grubia32.efi
-rwxr-xr-x 1 root root 3420152 Feb  1  2020 grubx64.efi
-rwxr-xr-x 1 root root 1008808 May  8  2019 mmia32.efi
-rwxr-xr-x 1 root root 1261192 May  8  2019 mmx64.efi

sda2 file list:

Code: Select all

.:
.
..
lost+found
ls.txt
mnt
pups

./lost+found:
.
..

./mnt:
.
..
sd2a

./mnt/sd2a:
.
..
pups

./mnt/sd2a/pups:
.
..
fossapup64

./mnt/sd2a/pups/fossapup64:
.
..
fossapup64initmodules.txt

./pups:
.
..
fossapup64

./pups/fossapup64:
.
..
adrv_fossapup64_9.5.sfs
AUTOSAVE
extra_boot_parameters.txt
fdrv_fossapup64_9.5.sfs
initrd.gz
puppy_fossapup64_9.5.sfs
SAVEMARK
vmlinuz
zdrv_fossapup64_9.5.sfs

[geo_c]

After my last boot, I was unable to unmount internal drive 4 where I keep my portable programs, ie. Firefox, Thunderbird, LibreOffice, Palemoon, Brave, VLC, Audacity. There was a hidden process running.
Unable to unmount nvme0n1p4.png

I removed all system files on internal partitions, and rebooted from the thumb drive. The first 3 internal drive partitions have no files at all.
My external drives can mount in pMount, but are not writable, just as before. So no change there.

So do I have this correct? nvme is writeable but these 3 below are not? (sdc1 should not be because it's a cd drive)

Code: Select all

/dev/sdb1: LABEL="T7" UUID="F00F-1D48" TYPE="exfat" PARTUUID="ea6d421c-01"
/dev/sdc1: LABEL="c-drv+I-bak" UUID="F67A373A7A36F6C9" TYPE="ntfs" PTTYPE="atari" PARTUUID="b4871312-01"
/dev/sdc2: LABEL="Win+Linux_bak" UUID="0840718640717B70" TYPE="ntfs" PARTUUID="b4871312-02"

These USB partitions below are your boot/install drive and it appears both partitions are writeable since you moved a text file to the boot partition.

Code: Select all

/dev/sda1: LABEL_FATBOOT="dosd992288c" LABEL="dosd992288c" UUID="8FB0-0686" TYPE="vfat" PARTUUID="d992288c-01"
/dev/sda2: LABEL="lind992288c" UUID="bb0ff474-57ff-4e7a-84b3-17c2ffb8a21e" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="d992288c-02"

The running process on your one nvme portable partion could be a lot of things, I run into this often when some application still has some process accessing it, but it could be a clue. It would be good to figure out what applications/processes/OS tools you were using prior to getting that condition.

I'm not super fluent in grub.cfg, but I have to wonder what's on those exfat/ntfs drives since those appear to be the only drives that aren't writeable. Either it could be something to do with the fact that these are exfat, ntfs, or I'm also wondering about the search statement in grub.cfg, setting the local_rd, if somehow searching for it it locked those drives. Just documenting this thought, and it might be nothing. OR do you possibly have pup system files on the any of the ntfs/exfat partitions

Can you check the write permissions of the exfat/ntfs partions? You could mount them, navigate to them in rox and view with details list, like this: My /sda1 shows read/write/execute permissions for /root

So my observations so far:
1) The install drive wasn't setup like this
/sda2/fossapup64
and instead it was setup like this:
/sda2/pups/fosspup64
-- did you create it that way? or did the tool you used to create the thumb drive boot set it up that way for you?

2) best I can tell, everything is writeable (your nvme, your sda1 and sda2 boot drive) except for the 2 drives with exfat/ntfs partitions.

3) SINCE we aren't talking about SAVE FOLDERS yet, this might be a premature observation, BUT, I'm now wondering about the SAVEMARK and AUTOSAVE files in your install directory in light of this frugalpup installer update: viewtopic.php?p=27339#p27339

now you used e3StickPup, and I know NOTHING about that tool. Hopefully somone who does will see this.

So, I'm still not at solution stage here yet, just clarifying the picture as much as possible. Whatever you can add to this observation list would help us figure out where to look next.

[geo_c]

As a followup to my previous post, I'm just noticing this in one of your posts above:

I found this,and I don't know how it got there:
/mnt/nvme0n1p1/zz_initrd_tmp

Now that you erased all the files from nvme, do you get this again after booting the fossapup thumb drive?

Also noticing that your /sda2 drive has a folder called /mnt. How did that get there? I don't think that should be there.

[Governor]

After my last boot, I was unable to unmount internal drive 4 where I keep my portable programs, ie. Firefox, Thunderbird, LibreOffice, Palemoon, Brave, VLC, Audacity. There was a hidden process running.
Unable to unmount nvme0n1p4.png

I removed all system files on internal partitions, and rebooted from the thumb drive. The first 3 internal drive partitions have no files at all.
My external drives can mount in pMount, but are not writable, just as before. So no change there.

So do I have this correct? nvme is writeable but these 3 below are not? (sdc1 should not be because it's a cd drive)

Code: Select all

/dev/sdb1: LABEL="T7" UUID="F00F-1D48" TYPE="exfat" PARTUUID="ea6d421c-01"
/dev/sdc1: LABEL="c-drv+I-bak" UUID="F67A373A7A36F6C9" TYPE="ntfs" PTTYPE="atari" PARTUUID="b4871312-01"
/dev/sdc2: LABEL="Win+Linux_bak" UUID="0840718640717B70" TYPE="ntfs" PARTUUID="b4871312-02"

These USB partitions below are your boot/install drive and it appears both partitions are writeable since you moved a text file to the boot partition.

Code: Select all

/dev/sda1: LABEL_FATBOOT="dosd992288c" LABEL="dosd992288c" UUID="8FB0-0686" TYPE="vfat" PARTUUID="d992288c-01"
/dev/sda2: LABEL="lind992288c" UUID="bb0ff474-57ff-4e7a-84b3-17c2ffb8a21e" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="d992288c-02"

Yes, I can write to the USB thumb drive I booted from which is sda1/sda2, and I thought I could not write to the remaining external USB drives, but that was incorrect. My CD drive is not plugged in. And here is what I just confirmed:

On the sdc1/sdc2 drive which is a USB hdd (NTFS), only the sdc2 partition is writable.

If I try to write a file to sdc1, I get an error message: "ERROR: Read-only file system" I also can't change any permissions on that drive, and get the same message.

ERROR - Read-only file system.png (240.98 KiB) Viewed 319 times

The sdd1 drive which is a USB hdd (vfat) is writable.

The sde1 drive which is a USB sdd (exfat) is writable.

All internal drives are writable. And all external drives show a lock symbol in pMount.

The running process on your one nvme portable partion could be a lot of things, I run into this often when some application still has some process accessing it, but it could be a clue. It would be good to figure out what applications/processes/OS tools you were using prior to getting that condition.

I'm not super fluent in grub.cfg, but I have to wonder what's on those exfat/ntfs drives since those appear to be the only drives that aren't writeable. Either it could be something to do with the fact that these are exfat, ntfs, or I'm also wondering about the search statement in grub.cfg, setting the local_rd, if somehow searching for it it locked those drives. Just documenting this thought, and it might be nothing. OR do you possibly have pup system files on the any of the ntfs/exfat partitions

Can you check the write permissions of the exfat/ntfs partions? You could mount them, navigate to them in rox and view with details list, like this: My /sda1 shows read/write/execute permissions for /root

So my observations so far:
1) The install drive wasn't setup like this
/sda2/fossapup64
and instead it was setup like this:
/sda2/pups/fosspup64
-- did you create it that way? or did the tool you used to create the thumb drive boot set it up that way for you?

I used e3stickpup to create the 2 partitions and install the boot files on the thumb drive. Everything was done automatically. I believe it created the pups directory, so the user can add other puppy versions.

2) best I can tell, everything is writeable (your nvme, your sda1 and sda2 boot drive) except for the 2 drives with exfat/ntfs partitions.

Yes, I have confirmed that the sdc1 partition which is a USB hdd (NTFS) is not writable.

3) SINCE we aren't talking about SAVE FOLDERS yet, this might be a premature observation, BUT, I'm now wondering about the SAVEMARK and AUTOSAVE files in your install directory in light of this frugalpup installer update: viewtopic.php?p=27339#p27339

now you used e3StickPup, and I know NOTHING about that tool. Hopefully somone who does will see this.

So, I'm still not at solution stage here yet, just clarifying the picture as much as possible. Whatever you can add to this observation list would help us figure out where to look next.

[geo_c]

You say that all external drives have a lock symbol in pmount.

The lock symbol usually means they can't be removed because system files are being accessed from them. It should not mean they can't be written to. So we expect the USB thumbdrive partitions to be locked because you're booting from that drive, so you can't remove it while running or it'll crash of course.

However the exfat and vfat shouldn't be locked. And that's why we need to know what's on those drives if there are possibly system files on them.

So still these important questions to answer:
1) Now that you erased all the files from nvme, does this file show up again after booting the fossapup thumb drive?

I found this,and I don't know how it got there:
/mnt/nvme0n1p1/zz_initrd_tmp

2) Your /sda2 drive has a folder called /mnt. How did that get there? Is there anything in it?

EDIT: Just received an answer to question 1 and 2: the zz_intrd_tmp is a log file, and the /mnt directory appears to be some kind of artifact left from I believe the installer. If there's nothing in it, I would remove it.

Still, if you haven't done this below, go ahead and test it:
3) Have you tried booting with only the USB boot thumbdrive plugged in and not the other two vfat/exfat drives? If not, try that and then see what happens. Check to see if the above file showed up on nvme again. If not, then plug your exfat/vfat drives in and see if they are writeable.

[bigpup]

Using e3stickpup program to do an install of a Puppy Linux version on a USB stick.

It is setup to make a boot menu entry in grub.cfg file on the USB, that will make the USB boot, so the Puppy OS will be running in pupmode 12.
This makes the save update as anything changes. Exactly when the change is made.
(I think this was for new Puppy users, so they would not have to make choices of saving updates to the save)

But running in pupmode 13 provides save choices.

To get Puppy to run in pupmode 13 that will allow options for how the save is updated.

You have to make a manual change to the entry in the grub.cfg file on the USB stick.

Anyplace in the entry that has pmedia=usbhd

Change it to pmedia=usbflash

@Governor change this line in the grub.cfg file on the USB stick

Code: Select all

linux /pups/fossapup64/vmlinuz net.ifnames=0 pmedia=usbhd  pdrv=lind992288c psubdir=/pups/fossapup64 pfix=fsck,fsckp TZ=XXX

Now when it boots it will run in pupmode13
After making a save, making sure you selected to place it on the 2nd partition of the USB stick, and rebooting using the save from that location.
There will be a save icon on the desktop.
Save options to select in Puppy event manager ->Save sessions

[bigpup]

@Governor

How about doing something to help all of us.

Make a new complete install of BookwormPup64 10.0.6 Puppy version, to a USB stick, using e3stickpup installer.

Try booting with it.

What happens?????

Hopefully your computer will boot it OK.

This should eliminate anything getting used that is on some other drive, because you have never used BookwormPup64 (I hope).
The only place it can get needed files will be from the USB stick install.
Plus BookwormPup64 has many new improvements, to everything, that are not going to be in Fossapup64 9.5, and never will be.

When you do the first shutdown and make a save.
Make sure to select to place it on the 2nd partition of the USB stick.
Make sure you know by looking at the drive icons on the desktop, what this 2nd partition is labeled. sd what?

It will boot in pupmode 12

So if you want it to boot in pupmode 13 and provide options for how the save works.
The grub.cfg file (on the USB stick) edit of pmedia= to pmedia=usbflash, will need to be done.

[geo_c]

@bigpup I appreciate the suggestion, and it's a sensible and good one,

however, before we add a whole new process of downloading and configuring a boot, I think it would go a long way to simply have @Governor boot his current fossapup USB without his exfat drives attached and check on the results FIRST.

If in doing that he finds the nvme seems to be funcitnonally normally at least for basic reads and writes, and the fossapup USB install is running well, he could even make a save of fossapup settings on his USB.

Then, he could plug in his exfat drives AFTER he is booted and running fossa, and see if they are then writeable. I just don't see how they could be locked at that point unless fossapup is simply deficient in some kind of drivers to write to them, or somehow the usb hub is interfering, which is a real possibility.

Because best I can tell, at this point @Governor does have a working USB fossapup, he just can't write to his exfat partitions that are showing up locked. If we eliminate those drives at boot, see if they function hotplugged, it might eliminate a few nagging questions, and then he could move in a new direction.

My two cents.

[Governor]

You say that all external drives have a lock symbol in pmount.

....

EDIT: Just received an answer to question 1 and 2: the zz_intrd_tmp is a log file, and the /mnt directory appears to be some kind of artifact left from I believe the installer. If there's nothing in it, I would remove it.

I had already removed it along with every system file on all internal partitions. I also deleted the extra mnt folder on the thumb drive.

Still, if you haven't done this below, go ahead and test it:
3) Have you tried booting with only the USB boot thumbdrive plugged in and not the other two vfat/exfat drives? If not, try that and then see what happens. Check to see if the above file showed up on nvme again. If not, then plug your exfat/vfat drives in and see if they are writeable.

I booted the thumb drive with no other USB drives. They got locked afterward when I plugged them in.

Here is something new. I took my NTFS USB hdd to a Windows computer and did a chkdsk /f on it and no errors were found. When I returned it to my laptop with fossapup, the drive was no longer locked and I could write to it. Go figure.

A little off-topic sidebar: Windows updates itself automatically even if you turn off updates every which way from Sunday. I wrote a little batch file for the Windows computer that runs in the background and terminates the update program every 30 seconds. Take that, Microsoft!

[Governor]

@bigpup I appreciate the suggestion, and it's a sensible and good one,

however, before we add a whole new process of downloading and configuring a boot, I think it would go a long way to simply have @Governor boot his current fossapup USB without his exfat drives attached and check on the results FIRST.

If in doing that he finds the nvme seems to be funcitnonally normally at least for basic reads and writes, and the fossapup USB install is running well, he could even make a save of fossapup settings on his USB.

Then, he could plug in his exfat drives AFTER he is booted and running fossa, and see if they are then writeable. I just don't see how they could be locked at that point unless fossapup is simply deficient in some kind of drivers to write to them, or somehow the usb hub is interfering, which is a real possibility.

Because best I can tell, at this point @Governor does have a working USB fossapup, he just can't write to his exfat partitions that are showing up locked. If we eliminate those drives at boot, see if they function hotplugged, it might eliminate a few nagging questions, and then he could move in a new direction.

My two cents.

I will try Bookworm, I think, to see what happens. If the external USB drives still show a locked symbol, then wouldn't that likely mean it is not the OS that is directly causing it? Here is a screenshot of pMount:

Pmount - locked external USB drives.jpg (79.27 KiB) Viewed 269 times

The boot drive is not locked, but the two USD hdd drives are, I have no idea why. I plugged them in after boot.

EDIT: I found the monitor setting for monitor support.
Hmm. I think I may have booted Bookworm once from my Ventoy thumb drive, but I'm not sure. If Bookworm does not support an external monitor, then I can't use it. I quickly tried a few of the pups where I could not find support for my monitor, and that is a deal breaker.

[Governor]

Using e3stickpup program to do an install of a Puppy Linux version on a USB stick.

It is setup to make a boot menu entry in grub.cfg file on the USB, that will make the USB boot, so the Puppy OS will be running in pupmode 12.
This makes the save update as anything changes. Exactly when the change is made.
(I think this was for new Puppy users, so they would not have to make choices of saving updates to the save)

But running in pupmode 13 provides save choices.

To get Puppy to run in pupmode 13 that will allow options for how the save is updated.

You have to make a manual change to the entry in the grub.cfg file on the USB stick.

Anyplace in the entry that has pmedia=usbhd

Change it to pmedia=usbflash

@Governor change this line in the grub.cfg file on the USB stick

Code: Select all

linux /pups/fossapup64/vmlinuz net.ifnames=0 pmedia=usbhd  pdrv=lind992288c psubdir=/pups/fossapup64 pfix=fsck,fsckp TZ=XXX

Now when it boots it will run in pupmode13
After making a save, making sure you selected to place it on the 2nd partition of the USB stick, and rebooting using the save from that location.
There will be a save icon on the desktop.
Save options to select in Puppy event manager ->Save sessions

Ok, I changed pmedia=usbhd to pmedia=usbflash and I changed nothing else.
I will have to do the boot later, and report back on it.

[Governor]

You say that all external drives have a lock symbol in pmount.

....

EDIT: Just received an answer to question 1 and 2: the zz_intrd_tmp is a log file, and the /mnt directory appears to be some kind of artifact left from I believe the installer. If there's nothing in it, I would remove it.

I had already removed it along with every system file on all internal partitions. I also deleted the extra mnt folder on the thumb drive.

Still, if you haven't done this below, go ahead and test it:
3) Have you tried booting with only the USB boot thumbdrive plugged in and not the other two vfat/exfat drives? If not, try that and then see what happens. Check to see if the above file showed up on nvme again. If not, then plug your exfat/vfat drives in and see if they are writeable.

I booted the thumb drive with no other USB drives. They got locked afterward when I plugged them in.

Here is something new. I took my NTFS USB hdd to a Windows computer and did a chkdsk /f on it and no errors were found. When I returned it to my laptop with fossapup, the drive was no longer locked and I could write to it. Go figure.

A little off-topic sidebar: Windows updates itself automatically even if you turn off updates every which way from Sunday. I wrote a little batch file for the Windows computer that runs in the background and terminates the update program every 30 seconds. I was happy to see the batch is still running. Take that, Microsoft!

[geo_c]

Here is something new. I took my NTFS USB hdd to a Windows computer and did a chkdsk /f on it and no errors were found. When I returned it to my laptop with fossapup, the drive was no longer locked and I could write to it. Go figure.

A little off-topic sidebar: Windows updates itself automatically even if you turn off updates every which way from Sunday. I wrote a little batch file for the Windows computer that runs in the background and terminates the update program every 30 seconds. I was happy to see the batch is still running. Take that, Microsoft!

Wait a minute....

What's happening is Windows is accessing it and it's probably not being removed cleanly. Or it's mounting it during the update, something like that, and you are breaking it off mid stream with your script. And you say this is "off-topic?"

You are telling us only now that you have written a script to keep windows from updating, one that terminates the update program every thirty seconds, and you are attaching these drives to that tampered version of windows, and all this time you've been asking the PUPPY FORUM why these drives are locked??

Okay chew on that for awhile and mark this topic SOLVED

Nothing is stopping you from making a save folder now. And you can probably write your own script to do it.

funny. I can't say I've ever to talked to an ordinary Joe User who would even think of writing a script to break off a Microsoft install. I'm not even sure an ordinary Joe User would even understand the concept.

I think Microsoft should provide a "user-friendly" menu to choose what drives get locked when the update gets borked by a user script....

[geo_c]

@bigpup I appreciate the suggestion, and it's a sensible and good one,

however, before we add a whole new process of downloading and configuring a boot, I think it would go a long way to simply have @Governor boot his current fossapup USB without his exfat drives attached and check on the results FIRST.

Hey @bigpup, you see what I was saying there?

Here is something new. I took my NTFS USB hdd to a Windows computer and did a chkdsk /f on it and no errors were found. When I returned it to my laptop with fossapup, the drive was no longer locked and I could write to it. Go figure.

A little off-topic sidebar: Windows updates itself automatically even if you turn off updates every which way from Sunday. I wrote a little batch file for the Windows computer that runs in the background and terminates the update program every 30 seconds. I was happy to see the batch is still running. Take that, Microsoft!

[williwaw]

@Governor

Is this the same computer you have been having issues with, you have talked about in other topics?
If yes.

Unless you can tell us, that some specific operating system can run the computer, with no problem.

I think the computer is having hardware issues.
Hardware that is not always working correctly.

You know you could be right, I wonder if it is a hardware failure. This laptop I am using came with Windows 10 pre-installed. I used that for about 1½ years.
When Windows crashed the last time, I was unable to resurrect it with any recovery methods including rescue CD or Macrium Reflect. The only other option I had available was to boot a Linux CD and that is how I got here.

lol.
I wonder how Windows got borked on the NVMe?

Deleting the visible files may not be enough, or even repartitioning the disk, if remnants of previous partition tables and boot code still exist, especially GPT tables at the end of the disk. Sometimes easiest to just overwrite the whole drive and start from scratch when e2fsprogs reports....

Either the superblock or the partitiontable is likely to be corrupt!

viewtopic.php?t=11508

......... if the drive is corrupted. you will want to copy all files you desire to keep to an external drive
wipe the drive with dd if=/dev/zero of=/dev/nvme0n1 status=progress (this may take a long time)
prepare to use diskpup by planing your new partition arrangement carefully before using gparted
http://www.fishprogs.software/puppy/fru ... index.html

[geo_c]

lol.
I wonder how windows got borked on the NVMe? or if windows borked the NVMe?

I knew there was a reason @Governor never answered me when I asked him 2 years ago what lead to his windows install being tanked to the point of not booting.

The phrase "atypical Windows user" comes to mind.