Fossapup64_9.5 CD won't boot

[Governor]

I consider this to be very important since it could be a fatal programming flaw. I hope the right people will see this.

Once again, the fossapup64boot_9.5 CD would not boot my computer, but the Knoppix CD did. I took several photos during boot.

Here is the link to the CD only bootup sequence images. The images tell the story. This is a fatal error, which in this case, appears to be a cyclical programming trap that does not go anywhere.

https://digioh.com/em/3651/189550/bwbh6k7s7m

[rcrsn51]

Image 4204 shows the adrv sfs module NOT loading. I don't know what has caused this, but I suspect that it has then caused the Xorg Wizard to fail in 4205.

Is this a remastered ISO with the adrv removed?

[williams2]

FossaPup64 has the main pup.sfs, which is a small stripped down core,
and an adrv.sfs file comes with the pup.sfs file which contains most of the other files in the FossaPup file system.

FossaPup boots to xwindows whether the adrv.sfs file is included or not.

I said that I use an adrv.sfs file with my changes that would normally be in my save file,
because it is true, First, I renamed the FossaPup adrv.sfs to ydrv.sfs.
Then I created my own adrv.sfs file.

Normally, FossaPup64 loads the pup.sfs and the adrv.sfs files when it boots.

[mikeslr]

How did you create the CD? Using What program/application? under What operating system? Running on What computer? See bigpup's post here, https://www.forum.puppylinux.com/viewtopic.php?t=218

Please be precise. Tell us step by step. I know you may have given us some information before in other threads you've started. But I, for one, am not going to search for that information.

Also tell us what operating systems you can boot into from what computers. Give details. I'm just thinking ahead. Sometimes, rather than chasing one's tail trying to figure out why you can't catch it, it's better to stop, and --with a clear idea of where you want to end up-- start from scratch.

For what it's worth, I always recommend that the 1st Puppy be one you 'burn' to a USB-Key. With a functioning Puppy on a USB-Key you can (a) supposedly use it to create a CD -- I never have; (b) use it to deploy an other instance to a hard-drive; (c) since some burning programs prevent writing anything else to the Key, the Puppy on the first key can be used to create a Fully usable version on another Key; and (d) on either the first (if it is write-able) or 2nd Key, add to it another READ-ONLY file-system containing all your settings and user-installed-applications-- so that after boot-up the Key can be removed.

It's not likely anyone is going to take the time to fix a bug in fossapup64-9.5 if it can't be written to a CD. Many computers no longer have CD burning hardware. BarryK --creator of Puppy-- has recommended that the ISO packaging format needed by applications/programs which write to CDs be deprecated. dimkr --perhaps the dev working on woof who most frequently responds to posts on this Forum-- also doesn't like the ISO format but reluctantly uses it. Fossapup64-9.5 is 2 years old: Forum members are working on it's replacement.

[geo_c]

@Governor remember that I've been asking you what you did with nicOS-utilities, which re-writes puppy system files like adrvr.sfs.

Viewing these images it's apparent that your adrv is not loading. So that's why I recommended getting all the original iso files from the iso download. I suggested a way to test this theory and possibly eliminate some issues. It's all outlined here in the following topic link: viewtopic.php?p=73757#p73757

edit: I realize however that if you use my described method with your USB install and the adrv is not present, then copying the iso files to a new install folder and running grub4dos may still be a problem in that you'll basically be performing those operations from a crippled system.

It may be possible to simply copy the adrv using your knoppix boot. In that case boot into knopixx, and do the same copy proces outlined in the link above, meaning copy the iso files to your present USB puppy install folder, which you would not be booted into because you're copying while booted in knoppix. After that, see you if you can boot into that original puppy install with the new files in it, as it will now have the adrv and also the other necessary files. If it works that would be a good start. If you still have savefile issues on the USB stick from that point, we can look at the USB stick closer.

[geo_c]

Image 4204 shows the adrv sfs module NOT loading. I don't know what has caused this, but I suspect that it has then caused the Xorg Wizard to fail in 4205.

Is this a remastered ISO with the adrv removed?

@Governor mentioned in another post that he has used nicOSutilities for something, but did not specify exactly for what. I've been suspecting that all this time he is using an improperly remastered system.

[Governor]

@geo_c @rcrsn51 @williams2 @mikeslr
The CD I have booted with, but no longer can is one I burned [finalized ISO 9660] on a Windows computer about 1½ years ago. I don't remember what program I used to burn it with or which hardware, but the OS was Windows 7 Home Premium. It was not a remastered ISO, AFAIK, but I can't remember where I got it.

I booted with the Puppy successfully a few times, but then it failed to boot. Meanwhile, the Knoppix CD had no problem booting. I reformatted my internal SSD drive and the Puppy CD booted fine again after that. IMHO, this indicates a programming error on the Puppy CD, or an erroneous burn, or some physical error on the CD itself.

Another issue which may or may not be related to the aforementioned issue:
The BIOS on my computer recognizes the drives I have connected to it. When I start the computer and go into the BIOS setup, I can see all the drives listed, and I can choose the general boot order and I can choose which drive to boot from immediately.

I repartitioned and reformatted my internal SSD drive to ext4 because I was told it was the best option, I now have a 467GB and a 9.7Gb partition on this drive. I installed Puppy to the 467 partition. However, I am unable to boot from it! I removed all USB drives including my USB CD and rebooted. In the BIOS setup I made sure that the 467 drive was the boot drive. The boot fails, even though I could choose the 467 drive in the Puppy bootloader. So BIOS recognizes all the drives, but Puppy does not.

I think this is bizarre that Puppy only seems to recognize the drive it is successfully booting from. How are you supposed to mount a drive in order to boot from it when that is the only drive there is to boot from in the first place? So my bootable thumb drive is the only one that works right now. And it always shows as locked in pMount.

What I want is:
to have my internal 467Gb harddrive as the default boot drive. And my thumb drive as a boot drive which I can use as a backup or to boot on a different computer. I would also like to synchronize the setup configuration on both 467 and thumb boot drives, also if the configuration changes. I keep my personal files, documents, images, videos, music, etc on separate USB FAT32 drives so this arrangement is only for the OS.

How can I achieve this?

PS. I burned a new CD with a different ISO file and it seems to be working fine.

[geo_c]

PS. I burned a new CD with a different ISO file and it seems to be working fine.

@Governor, Great! That's a solid step forward.

I don't have much time this morning, just a few minutes, but I saw you mentioned using what is called a 'multi-session' cd. Back in the days of avid CD usuage, that was common, but I don't recommend going that route.

Now that you have a bootable CD, what I would do next Is repartition your USB thumb drive to ext4 using gparted, preferably to one large ext4 partition, flag it as the boot partition, and either use the puppy installer to install fossa on the thumb drive...

...or an alternate method would be create a /fossapup64 folder on it and copy these files from your cd, which if booted from the cd would be found in /mnt/home:

Then run grub4dos, you should be able to boot the thumb drive from that point and save your settings right there on the thumb drive, which would make life a lot easier when tackling the internal ssd drive boot issues.

[Governor]

@geo_c
I used a CD-R CD which is usually closed after writing, but a message popped up on my screen and said I could wait with closing the CD which would give me a chance to add files to it, and it didn't matter if it was a R or RW CD. So I figured it might be a good idea to include configuration files and extra programs on the CD and save myself a hassle if/when I boot the CD at a later point.

How do I save my current configuration and include it on the CD and on the thumb drive so I don't have to do the configuration over?

Thanks!

[geo_c]

@geo_c
I used a CD-R CD which is usually closed after writing, but a message popped up on my screen and said I could wait with closing the CD which would give me a chance to add files to it, and it didn't matter if it was a R or RW CD. So I figured it might be a good idea to include configuration files and extra programs on the CD and save myself a hassle if/when I boot the CD at a later point.

How do I save my current configuration and include it on the thumb drive so I don't have to do it over?

Thanks!

I have never transfered my saved settings from CD to another install because I have never used the CD that way in the past, but what you would be looking for is a pupsave folder or file on the CD that you can copy to the install directory on the thumb drive.

Another (preferred) method would be to do a pupsave-backup while booted from the CD and choose the location of the backup as the fossapup install folder on the thumb drive.

[mikeslr]

The technique of keeping a CD/DVD open and writing back to it was developed at least 16 human years ago -- that's like a century and a half in 'computer years'-- at a time when use of CD and CD burners was prevalent while use of USB-Keys was in its infancy. See, https://bkhome.org/archive/puppylinux/d ... works.html and note the date.

I'm not sure Puppys as recent as Fossapup can run under PupMode 77. I seem to recall someone else having had a problem. On the other hand, I also seem to recall at least one experienced Puppy user still employing that system; but I don't recall what Puppy was being used.

At any rate, the system works differently that PupModes 12 and 13. Under PuppyMode 12 (the default for hard-drives) content in memory is periodically written to the SaveFile/Folder over-writing any conflicting previous contents there. Under PupMode 13 (default for USB-Keys, but can be used with hard-drives) changes are initially written to a portion of RAM, later optionally written to Storage and at that time over-writing any conflicting previous content there.
Under PupMode 77, each new write to the CD/DVD is in its own 'folder'. On boot-up the folders are merged in RAM with the newest content having priority. That might permit deletion of a problem 'Save'. I'm not sure how well that works if the problem Save was somewhere in the middle rather than the last. But the technique creates the potential for two problems. The first is that unlike a READ-ONLY CD/DVD, since the CD/DVD can be written to it can also be corrupted and infected by malware. The second is that each Save uses more space on the media. After a number of Saves there will be no available space for further Saves. And I'd guess, if there was some space but not enough to write the current content in RAM to the CD you end up with an incomplete Save which, being the latest and having priority, would prevent a successful boot.
I've never used the technique. My guess is based on an analogy with the problem others and I have encountered when using SaveFiles. These also are of fixed size. Attempts to Save when the content in RAM exceeds their available space breaks them. Sometime after the invention of PupModes 12 and 13, code was added to provide an 'insufficient space' warning. I don't know if similar code was written for PupMode 77.

[geo_c]

@Governor,

Basically I would look at your bootable CD similar to a windows "System Installation Disk." Only it's so much better because it's actually the full running and installed OS on a CD.

But just because you can run from CD doesn't mean it's the most advantageous way to run the system.

That's why I suggest not making a bunch of changes while booted off the CD.

Instead use the CD to install the system USB, then the USB system can be used to install the system everywhere else, because just about every computer has USB and can boot from it, which isn't true of CD any more.

The CD is a nice tool to have around for computers with CD drives. I just think of it as a read only hard copy of the clean OS. You can run it, check to see that it works on a certain computer, and use it to install to that computer. And you can do the same with the USB, only the USB will have all your customized settings and applications, and you can keep writing save folders and backup saves until that drive eventually wears out.

So, to recap. Next use the CD boot to install to the USB thumb drive. Boot that and make a savefolder in the default location. Your settings will be saved and you can back them up in under a minute, experiment, even break things, and revert to the backup save just by rebooting and choosing the backup pupsave. That's the true power of the pup.

[geo_c]

@Governor,
Your settings will be saved and you can back them up in under a minute, experiment, even break things, and revert to the backup save just by rebooting and choosing the backup pupsave. That's the true power of the pup.

And here's the thing. There would have to be massive sun spot acitivity or full out EMP attack on the United States for me to somehow lose my configured system, because I literally have my pupsaves copied in 20 different places (5-7 computers, usb hard drives/thumb drives/ssd drives), and I have a library of the development of my system, something like this:

fossapup64save-2020-01-11-connections
fossapup64save-2020-02-01-browsers
fossapup64save-2020-03-11-commandlineapps
fossapup64save-2020-04-11-themes
etc...

So I run pupsave backup at least every other day. Delete a lot of them, but archive the ones that I may want to fall back to later, but almost never have to.

I might try some massive application or framework install, but before I do, I just run pupsave backup, takes a minute or two at the most depending on the write speed of the drive. My SSD drives take 10-15 seconds to backup my 2GB fully developed personal system. If I find my massive ill advised application install gums up the system or breaks something, I just re-boot and choose the backup pupsave. Then I delete the broken one.

So the sooner you get an install where you can quickly backup and play, the more fun you are going to have.

My two cents of course. There are lots of ways to train a pup, because it's versatile.

[Governor]

@geo_c @mikeslr
I can see that a USB drive is the way to go. I just like the idea of having a permanent boot/install where files cannot be erased or tampered with. Is there a way to lock a USB drive?

I am trying to understand what is happening when booting from a CD. The boot device is unmounted and not available to the file manager. This is normal, right?

When I booted this session from my newly burned CD, I had the option of 0, 1, or 2. Are options 1 and 2 configuration files saved during previous shutdowns?

Can the files in the boot options be on separate devices, and if so are these devices not mounted, or are they mounted automatically on boot, or if mounted, is only the device hosting the chosen boot file that is mounted?

How do I know the location of the boot (saved) file? In my case I think it is on my small ext4 partition on my internal SSD drive because the large partition was not mounted.

How do I know if the boot file option I choose is successful? I can see that some of my previous settings were restored with this session, and I chose boot option 2. I did not see any warnings, so I am thinking option 2 was successful. How do I make sure the device which contains the saved file I want to use is accessible on boot? Is there a way to choose a saved file on boot that is not in the bootloader menu during boot? How can I see now which saved boot file was used for this session?

I did have a big obstacle in that the screen canvas was oversized and I could not see the taskbar or any icons at all, even though the settings were correct in the screen wizard. This could be enough for people to think Linux is not working for them, and just give up. Luckily, I surmised that it could be a glitch, so I first resized the screen to 800x600 and then back to 1280x1024 and that fixed it.

Sorry for all the questions, but if I ask one question at a time, it will take years and I am counting on learning the basics in a few months.

Thanks!

[geo_c]

@geo_c @mikeslr
How do I know the location of the boot (saved) file? In my case I think it is on my small ext4 partition on my internal SSD drive because the large partition was not mounted.
Thanks!

Once you're booted go to the System menu and look for Pup-SysInfo information. Once there use the Sys-Files menu and choose PupState, and you will get a read out that looks like this:

Notice the highlighted pupsave info which tells you what pupsave you are currently booted into and where it's located. Mine is called 'jackalpup' because it's an audio/multimedia focused remaster of fossapup.

I use this utility all the time especially late at night when I can't see straight and I'm about to rename or delete a pupsave, and I'm not sure what I'm booted into at the moment.

edit: It might be good to take a screenshot of this to give us a better idea of your system layout.

[geo_c]

@geo_c @mikeslr
I am trying to understand what is happening when booting from a CD. The boot device is unmounted and not available to the file manager. This is normal, right?

When you boot from CD I'm pretty sure the system is running in RAM, the system meaning the fossapup base OS files, not your save file or folder. That's why it's unmounted, it loads the system and then runs it from RAM. You can mount the CD and look at it though.

If you're booted into a savefile, that partition will be mounted. You DON'T want to unmount that partition while running from it.

[geo_c]

@geo_c @mikeslr
I can see that a USB drive is the way to go. I just like the idea of having a permanent boot/install where files cannot be erased or tampered with. Is there a way to lock a USB drive?

I would suggest that what you want with a hard copy install, is a completely stable system, meaning, that while you are figuring out how to use fossapup effectively, it would be time and effort effective to tweak it on a usb install.

If you're comprehending what I'm saying about pupsave folders and backing them up, then consider the idea that as you create stable and customized pupsaves, they can be written to any medium, including a CD, so that you reburn the CD and add the save (or multiple saves) to it once you have things setup to your liking.

Then only thing you really need to do to insure your data doesn't get lost is copy it to other places. If your working save is altered, then grab one of these backed up saves and your good to go.

[geo_c]

@geo_c @mikeslr
When I booted this session from my newly burned CD, I had the option of 0, 1, or 2. Are options 1 and 2 configuration files saved during previous shutdowns?

Can the files in the boot options be on separate devices, and if so are these devices not mounted, or are they mounted automatically on boot, or if mounted, is only the device hosting the chosen boot file that is mounted?

If options 1 & 2 are listing the names of your pupsave folders or files then those are your saved configurations. Option 0 is booting without a pupsave.

They can be on separate devices, but sometimes the boot process needs extra help finding them. Again, if options 1 & 2 are your pupsaves then the boot sequence is finding them. If not, there are solutions.

That's another reason why a USB install with the pupsave in the /home directory is the simplest way to find your current settings. It will look there first.

[geo_c]

I did have a big obstacle in that the screen canvas was oversized and I could not see the taskbar or any icons at all, even though the settings were correct in the screen wizard. This could be enough for people to think Linux is not working for them, and just give up. Luckily, I surmised that it could be a glitch, so I first resized the screen to 800x600 and then back to 1280x1024 and that fixed it.
Thanks!

If you are changing monitors, or using dual monitors then you may have to do what you described and run the wizard again. Fossapup's dual montior utility often hides the taskbar if it's on monitor 1, and monitor 2 is taller than monitor 1. It's not really bug, I'd call it a quirk. There are some quirks, but they almost all can be remedied. Some of the newer pups have different desktop environments and utilities. These are some of the factors that drive people's pup distro choices.

If for some reason you can't see the taskbar, you can right-click on the desktop and the applications menu appears.

[Governor]

@geo_c

Code: Select all

Thanks for the responses, It is a great help. Although I am still confused about what drives are mounted or not mounted on boot. 
Is PUP_HOME, the OS files?
Is '/mnt/dev_save' in RAM?

Pupstate below.

▶—— /etc/rc.d/PUPSTATE ——◀

 • PUPMODE=12
 • PDEV1='nvme0n1p1'
 • DEV1FS='ext4'
 • PUPSFS='nvme0n1p1,ext4,/puppy_fossapup64_9.5.sfs'
 • PUPSAVE='nvme0n1p1,ext4,/fossapup64save.4fs'
 • PMEDIA='cd'

ATADRIVES is all internal ide/pata/sata drives, excluding optical, excluding usb...
 • ATADRIVES='nvme0n1 '

ATAOPTICALDRIVES is list of non-usb optical drives...
 • ATAOPTICALDRIVES=''

These directories are unionfs/aufs layers in /initrd...
 • RW_LAYER='/pup_rw'
 • SAVE_LAYER='/pup_rw'
 • PUP_LAYER='/pup_ro2'

The partition that has the fossapup64save file is mounted here...
 • PUP_HOME='/mnt/dev_save'
(in /initrd) ...note, /mnt/home is a link to it.

This file has extra kernel drivers and firmware...
 • ZDRV='nvme0n1p1,ext4,/zdrv_fossapup64_9.5.sfs'
 • FDRV='nvme0n1p1,ext4,/fdrv_fossapup64_9.5.sfs'
 • ADRV='nvme0n1p1,ext4,/adrv_fossapup64_9.5.sfs'
 • YDRV=''

Partition no. override on boot drive to which session is (or will be) saved...
 • PSAVEMARK=''
 • PSAVEPART=''
 • PSAVEDIR=''
 • PSUBDIR=''
 • PUNIONFS='aufs'
 • DOIMODS='yes'
 • DOMIBS='no'

[geo_c]

@geo_c

Thanks for the responses, It is a great help. Although I am still confused about what drives are mounted or not mounted on boot.
Is PUP_HOME, the OS files?
Is '/mnt/dev_save' in RAM?

Pupstate below.

▶—— /etc/rc.d/PUPSTATE ——◀

• PUPMODE=12
• PDEV1='nvme0n1p1'
• DEV1FS='ext4'
• PUPSFS='nvme0n1p1,ext4,/puppy_fossapup64_9.5.sfs'
• PUPSAVE='nvme0n1p1,ext4,/fossapup64save.4fs'
• PMEDIA='cd'

ATADRIVES is all internal ide/pata/sata drives, excluding optical, excluding usb...
• ATADRIVES='nvme0n1 '

ATAOPTICALDRIVES is list of non-usb optical drives...
• ATAOPTICALDRIVES=''

These directories are unionfs/aufs layers in /initrd...
• RW_LAYER='/pup_rw'
• SAVE_LAYER='/pup_rw'
• PUP_LAYER='/pup_ro2'

The partition that has the fossapup64save file is mounted here...
• PUP_HOME='/mnt/dev_save'
(in /initrd) ...note, /mnt/home is a link to it.

This file has extra kernel drivers and firmware...
• ZDRV='nvme0n1p1,ext4,/zdrv_fossapup64_9.5.sfs'
• FDRV='nvme0n1p1,ext4,/fdrv_fossapup64_9.5.sfs'
• ADRV='nvme0n1p1,ext4,/adrv_fossapup64_9.5.sfs'
• YDRV=''

Partition no. override on boot drive to which session is (or will be) saved...
• PSAVEMARK=''
• PSAVEPART=''
• PSAVEDIR=''
• PSUBDIR=''
• PUNIONFS='aufs'
• DOIMODS='yes'
• DOMIBS='no'

These three lines here:
• PUPSFS='nvme0n1p1,ext4,/puppy_fossapup64_9.5.sfs'
• PUPSAVE='nvme0n1p1,ext4,/fossapup64save.4fs'
• PMEDIA='cd'

Pup HOME is where the system files are running from. PUPSFS (the pup root file system) and PUPSAVE appear to be on the same partition, nvme0mp1. Is that your external CD drive? If so, they appear to both be on the CD.

@mikeslr, am I reading that right? Just checking.

[TerryH]

@geo_c

Thanks for the responses, It is a great help. Although I am still confused about what drives are mounted or not mounted on boot.
Is PUP_HOME, the OS files?
Is '/mnt/dev_save' in RAM?

Pupstate below.

▶—— /etc/rc.d/PUPSTATE ——◀

• PUPMODE=12
• PDEV1='nvme0n1p1'
• DEV1FS='ext4'
• PUPSFS='nvme0n1p1,ext4,/puppy_fossapup64_9.5.sfs'
• PUPSAVE='nvme0n1p1,ext4,/fossapup64save.4fs'
• PMEDIA='cd'

ATADRIVES is all internal ide/pata/sata drives, excluding optical, excluding usb...
• ATADRIVES='nvme0n1 '

ATAOPTICALDRIVES is list of non-usb optical drives...
• ATAOPTICALDRIVES=''

These directories are unionfs/aufs layers in /initrd...
• RW_LAYER='/pup_rw'
• SAVE_LAYER='/pup_rw'
• PUP_LAYER='/pup_ro2'

The partition that has the fossapup64save file is mounted here...
• PUP_HOME='/mnt/dev_save'
(in /initrd) ...note, /mnt/home is a link to it.

This file has extra kernel drivers and firmware...
• ZDRV='nvme0n1p1,ext4,/zdrv_fossapup64_9.5.sfs'
• FDRV='nvme0n1p1,ext4,/fdrv_fossapup64_9.5.sfs'
• ADRV='nvme0n1p1,ext4,/adrv_fossapup64_9.5.sfs'
• YDRV=''

Partition no. override on boot drive to which session is (or will be) saved...
• PSAVEMARK=''
• PSAVEPART=''
• PSAVEDIR=''
• PSUBDIR=''
• PUNIONFS='aufs'
• DOIMODS='yes'
• DOMIBS='no'

These three lines here:
• PUPSFS='nvme0n1p1,ext4,/puppy_fossapup64_9.5.sfs'
• PUPSAVE='nvme0n1p1,ext4,/fossapup64save.4fs'
• PMEDIA='cd'

Pup HOME is where the system files are running from. PUPSFS (the pup root file system) and PUPSAVE appear to be on the same partition, nvme0mp1. Is that your external CD drive? If so, they appear to both be on the CD.

@mikeslr, am I reading that right? Just checking.

nvme0n1 is an internal nvme solid state drive, the p1 suffix is the 1st partition. The pmedia=cd in this instance is incorrect, the correct value for this type of drive should be pmedia=ataflash. This may be related to the save issues being encountered. pmedia-ataflash should be included on the kernel line in the boot stanza.

Maybe if Governor posts the boot stanza being used to boot would assist helping sorting out the issues.

[geo_c]

nvme0n1 is an internal nvme solid state drive, the p1 suffix is the 1st partition. The pmedia=cd in this instance is incorrect, the correct value for this type of drive should be pmedia=ataflash. This may be related to the save issues being encountered. pmedia-ataflash should be included on the kernel line in the boot stanza.

Maybe if Governor posts the boot stanza being used to boot would assist helping sorting out the issues.

I don't know what to think about that. But I did try to alert @Governor to the idea of having system files in so many places, and eliminating those variables.

So it appears that perhaps he is booting from his hard drive this entire time.

I can only guess as to how his adrv suddenly came back when it was not loading previously. Perhaps it's still not loading.

What we now need is a screenshot of /mnt/home, to see what's in there. And that means checking Pup-SysInfo first to see that his /home drive is still nvme0n1, then making a screenshot of /mnt/home to see that his pup install has all the necessary system files.

But is it possible that he copied an "iso" img to the hard drive, and that's why pmedia=cd?

In that case he would need to instruct his computer to boot from the cd for real, and try installing again to the hard drive using the pup installer.

@Governor how did you do the ssd internal drive install, what method?

[Governor]

@geo_c
I took a screenshot og mnt/home, but the image upload to the forum trashed. When I boot from the CD, it looks like the file used is on the SSD internal drive just as @TerryH said. Also in pMount it looks like that drive is mounted, and I cannot unmount it so I presume that is because the OS is running from there. I think the system file being used file is /mnt/home/fossapup64save.4fs.

BTW, the last time I shut down, I was not given an option to save anything - could that have anything to so with the mounting/unmounting of drives?.

It took me 5 minutes this time after boot to get the screen right, and about 4 minutes to get the computer clock to show the correct time via internet sync.

PS. Good news, I successfully created a backup. This was the first time it worked.

[geo_c]

@geo_c
I took a screenshot og mnt/home, but the image upload to the forum trashed. When I boot from the CD, it looks like the file used is on the SSD internal drive just as @TerryH said. Also in pMount it looks like that drive is mounted, and I cannot unmount it so I presume that is because the OS is running from there. I think the system file being used file is /mnt/home/fossapup64save.4fs.

BTW, the last time I shut down, I was not given an option to save anything - could that have anything to so with the mounting/unmounting of drives?.

It took me 5 minutes this time after boot to get the screen right, and about 4 minutes to get the computer clock to show the correct time via internet sync.

PS. Good news, I successfully created a backup. This was the first time it worked.

The missing piece is understanding how you did the install to the SSD drive. If you're SSD install is running in the correct pupmode and there is only one save file, then it will be saved automatically or written to on the fly, I think, I'm not sure as I haven't used a savefile for a number of years. I always use save folders on ext3 or ext4 partitions. If you're having to constantly reset the clock, I would imagine you are not booting into a savefile.

Like I said above, is it possible that you installed some kind of an iso boot on the SSD, and so the pup is running in a mode similar to a CD boot?

For an experiment: run grub4dos on the SSD and try to boot without the CD, because from what I can tell, your CD is booting the install on the SSD drive, which it definitely can do, but there is no need to do it that way when you can put the bootloader on the SSD.

The forum doesn't handle image files very well. I use this site: https://postimages.org/ and get the hotlink for forums and paste into the post. Works great, been using it for a long time, and you don't need to sign up for an account or anything

[williams2]

I shut down, I was not given an option to save anything - could that have anything to so with the mounting/unmounting of drives?.

The way a big mainstream distro works,
it's file system is a mounted file system in a partition,
and anything written to the file system
is written directly and immediately to that mounted file system.

The standard way that Puppy works is just the same.
Puppy has a file system in a partition or in a dir in a partition,
or in the mounted file system that is in a save file.

It does not matter whether Puppy's file system is in a partition or in a save file, or where it is,
the file system in each case is absolutely identical.
The file system in the save file is not compressed,
it is byte-for-byte identical to the Linux file system in a partition.

The standard way that Puppy works is mode 12.
mode 12 works exactly the same way that the big mainstream distro works.
Everything written to the file system of the big distro is written directly to the hard drive.
Everything written to the Puppy file system is written directly to the hard drive. immediately.

(ignoring ram buffers, of course.)

When writing to the file system,
the standard way that Puppy works
is to write changes immediately and directly to the hard drive.
The same way any big mainstream distro does.

Not really very complicated.

[Governor]

@geo_c @TerryH @williams2

Ok, I tied to use grub4dos on the SSD drive - since Puppy is apparently booting from partition 1 on the SSD (via the CD).
I got a message "no supported file systems found" on the SSD drive.

I installed Puppy on the SSD drive with the Puppy Installer in the Menu. I chose the 3rd option "Installer". I specifically did not choose "FrugalPup" because I did not want a minimal version of the OS that takes as little space as possible. I have since learned that is not the meaning. IMO that is a misnomer and I believe it will be misunderstood by most people.

Anyway, I am not sure if I was booted from my thumb drive or CD when I installed Puppy to the SSD.
I tried to install Puppy to another thumb drive but it would not boot at all.

What I want is:
To have my internal SSD internal drive as the default boot drive. And my thumb drive as a boot drive which I can use as a backup boot drive (or to boot on a different computer). I would also like to synchronize the setup configuration on both SSD and thumb boot drives, also if the configuration changes. I keep my personal files, documents, images, videos, music, etc on separate USB FAT32 drives so this arrangement is only for the OS.

How can I achieve this?

[geo_c]

@geo_c @TerryH @williams2
Ok, I tied to use grub4dos on the SSD drive - since Puppy is apparently booting from partition 1 on the SSD (via the CD).
I got a message "no supported file systems found" on the SSD drive.

I'm trying to piece that together, and I do notice that although we both have SSD drives as internal hard drives, mine is numbered sda1 rather than nvme, which I don't have a good explanation for, and it may be above my pay grade. However your SSD is formatted ext4, so I'm not exactly why you're getting that message. Hopefully someone else might have an idea. I'm usually able to install grub4dos on a drive that I'm running puppy from, as long as no reformatting of the partitions are involved.

I installed Puppy on the SSD drive with the Puppy Installer in the Menu. I chose the 3rd option "Installer". I specifically did not choose "FrugalPup" because I did not want a minimal version of the OS that takes as little space as possible. I have since learned that is not the meaning. IMO that is a misnomer and I believe it will be misunderstood by most people.

This has been an ongoing discussion on the forum, renaming the "Frugal" install. The bottom line is you're not the first to think that 'frugal' somehow infers limited in some way, quite the opposite, the 'frugal install' is the preferred, easiest to manipulate, and the most versatile install method. @rockedge tried to remedy the situation by including this section of the forum: viewtopic.php?t=6953

So what method did you choose? Because if your save is in the form of a file, I have always been under the impression that it would necessarily have to be a frugal install.

Anyway, I am not sure if I was booted from my thumb drive or CD when I installed Puppy to the SSD. I tried to install Puppy to another thumb drive but it would not boot at all.

We would have to walk through that and see what's missing. First format the usb thumb drive to ext4 using gparted, flag the partition where you want the bootloader with a 'boot' flag, and then run the puppy installer like you did before.

These three different installs being in play make it difficult to ascertain what's happening and when. First of all I would recommend that you set your computer's bios to the boot order: CD, USB, SSD. If the order is set that way, you should be able to test each install, and to be doubly safe, remove the media that you are not trying to boot. So you can test the CD by taking out any USB drives. Although I'm still confused, because in previous posts it's appearing that your CD is booting your SSD internal install, and puppy thinks it's running from a CD, because PupSys-Info is reporting PMEDIA=CD. The CD should boot from itself first, unless the CD boot parameters are only looking for sr0 optical drives, and not USB CD drives, which is quite possible, so that the CD bootloader is finding the first available install and booting that instead.

All of what I just mentioned suggests that even though your only known working install is on SSD, it may need to be reinstalled. Before attempting a re-install on SSD I would check the boot order first, because the reinstall might be done most effectively by repartitioning that SSD drive with gparted, and you'll need to make sure that you can boot from some other medium, like your external CD drive.

What I want is:
To have my internal SSD internal drive as the default boot drive. And my thumb drive as a boot drive which I can use as a backup boot drive (or to boot on a different computer). I would also like to synchronize the setup configuration on both SSD and thumb boot drives, also if the configuration changes. I keep my personal files, documents, images, videos, music, etc on separate USB FAT32 drives so this arrangement is only for the OS.

How can I achieve this?

Not only is the possible, but it's how I run my daily drivers. All computers boot systems installed on the internal drive, and I have USB installs on external thumb and hard drives, both ATA and SSD, to which I copy or backup my internal-install pupsaves to, so that all my systems are in sync, essentially exactly the same.

I keep data in sync by using rsync, or grsync which is a sync utility gui version of rsync. So it's like I'm operating a single computer on many different devices, from many different drives.

In order to do this you first have to get booting from your internal SSD sorted out, and then installing to USB figured out.

I mentioned configuring the boot order in your computer's bios, but is this machine setup and capable of legacy boot, or is it UEFI?

[one]

[...]
I'm trying to piece that together, and I do notice that although we both have SSD drives as internal hard drives, mine is numbered sda1 rather than nvme, which I don't have a good explanation for, and it may be above my pay grade. [...]

Hi @geo_c,

read this about the differences between SSD and NVMe - and why they are identified as different devices:

https://www.storagepoint.net/nvme-vs-ssd/

peace

[geo_c]

Hi @geo_c,

read this about the differences between SSD and NVMe - and why they are identified as different devices:

https://www.storagepoint.net/nvme-vs-ssd/

peace

The only difference in these two types of drives that I see that could be affecting grub4dos failing to recognize the filesystem is perhaps the fact that nvme is encrypted. But I don't know if that's a real factor or not.