Puppy Linux Discussion Forum

I am in the process of making a multi-use, multi-OS, bootable USB stick.
I intend that the final product will be able to boot Fatdog64-812 and several of the Puppies (e.g. friendly-fossa64, AtomicPupXXII, dpup-stretch-7.5,
s57-2018, and even some older pups).

As this USB stick may be used on any arbitrary computer it is important that the boot loader does not find other instances of any of these systems or load any savefiles or folders from the hard drive(s). The method I have used so far follows the item in the Fatdog Help i.e. “How to install Fatdog64 to a flash drive that works for both BIOS and UEFI machines” see below.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Bootable USB Installation
Foreword
This is an alternative installation to install Fatdog64 to a USB flash drive. It will work for both BIOS and (U)EFI machines.
The installation process will destroy the existing content of the flash drive, so either do this on a new USB flash drive or use one that you don't mind erasing.
The installation process requires the use of “dd” command (equivalent on Windows is Win32DiskImager or similar). If you are not familiar with “dd” command, then stop now because the wrong usage of “dd” can cause data loss of your system. (There is a reason why “dd” is sometimes called as “disk destroyer”).
This installation will work from Fatdog64 811 onwards. It requires some files which is only distributed in Fatdog64 ISO from version 811 onwards. It would also work on older Fatdogs if you get the necessary files from newer Fatdogs.
-----------------------
Installation
The installation files required for this method can be found in the “usb-boot” folder on the Fatdog ISO.
There are two files: README, and boot-images.tar.xz. It is the latter which is important.
boot-image.tar.xz contains two files, called
• usb-boot-mbr.img (for USB flash drive less than 2TB in size, using MBR partition), and
• usb-boot-gpt.img (for any size, not limited to 2TB, uses GPT partition).
Each one of them expands to about 530MB when extracted. They work identically so this guide will explain how to use the MBR variant. To use the GPT variant, read the supplied README.
First, extract the usb-boot-mbr.img.
Then, use “dd” or Win32DiskImager or similar tools, and write it to your USB flash drive. In Linux this can be done as
dd if=usb-boot-mbr.img of=/dev/sdd bs=4k
Assuming that your USB flash drive is at /dev/sdd.
Note: Choosing the wrong target can destroy your harddisk and causes data loss, if you are not sure where the USB flash drive is located, then STOP NOW AND DO NOT CONTINUE WITH THIS PROCESS.
Note that you need to write to the USB disk itself, not its partition, i.e. you need to write to /dev/sdd and not to
/dev/sdd1, for example.
Once the “dd” is done, you will end up with two partitions on the USB flash drive. Ignore the first partition (16 MB FAT partition labelled “ESP”), and only look at the second partition (labelled “OS”).
The second partition will have the size of 512MB and is formatted as ext4. There are already files stored in this partition, but they are examples only to get your started.
To boot Fatdog, you just need to copy the following files from Fatdog ISO:
• vmlinuz
• initrd
• initrd-nano (optional, only if you have slow BIOS, usually if you run ancient motherboard)
And that's it.
--------------------------------------
FAQ
Q: But 512MB is too small! A: Sure. Grab the files, resize the partition using gparted or your other favourite partition tool and copy the files back.
Q: I don't like ext4. A: Sure. Grab the files, re-format the partition with the filesystem that you like, and copy the files back.
Q: There are only two partitions? A: Yes. Feel free to create the 3rd, 4th and other partitions as you wish.
Q: Can I edit the example files? For example, can I edit grub.cfg to add other entries? A: Definitely. Keep a copy in case you mess up, though.
Q: Can I boot other Puppies with this too? Multiple puppies? A: Sure, if you know the command line parameters that you need to pass, and if you know how to edit grub.cfg to do that.
Q: There are multiple configuration files! I see menu.lst on the “ESP” partition. Which one I should edit? A: You only need to edit grub.cfg on the “OS” partition. Do not touch anything else. The primary boot loader is grub2.
Q: Can I put OS files in other partition other than “OS”? E.g. Can I create a 3rd partition and put multiple versions of Fatdogs there? A: Yes you can, but it's better that you re-size “OS” to make it fit to contain all the OS you want to put. Leave the 3rd partition for your data.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
My usb stick has four partitions. Gparted shows that the first partition labelled ESP is a 16.00 MiB fat16 partition with the boot flag set. The second with the OS label is a 12.00 GiB ext4 partition. The third with the label STORAGE is also of 12.00 GiB but formatted as ext3 as it will also contain some older Pups. The final partition with the SNEAKER label takes up the remaining 4.89 GiB it is formatted as fat32. The file grub.cfg found in the OS partition was originally as shown below.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
insmod png
background_image /fatdog.png
set timeout=10
menuentry "Start Fatdog64" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs
initrd /initrd
echo Booting ...
}
menuentry "Fatdog64 with savefile in USB device" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs waitdev=5
initrd /initrd
echo Booting ...
}
menuentry "Fatdog64 with multisession support" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs savefile=direct:multi:sr0
initrd /initrd
echo Booting ...
}
menuentry "Fatdog64 with LVM and mdadm support" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs withlvm withmdadm
initrd /initrd
echo Booting ...
}
menuentry "Fatdog64 without savefile" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs savefile=none
initrd /initrd
echo Booting ...
}
menuentry "Fatdog64 without graphical desktop" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs pfix=nox
initrd /initrd
echo Booting ...
}

menuentry "---" { true; }
menuentry "Use larger font" {
loadfont /terminus24.pf2
terminal_output console
terminal_output gfxterm
}

menuentry "---" { true; }
menuentry "For problematic Radeon cards - disable radeon driver" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs blacklist=radeon
initrd /initrd
echo Booting ...
}
menuentry "For problematic Nvidia cards - disable nouveau driver" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs blacklist=nouveau
initrd /initrd
echo Booting ...
}

submenu "More options for machines with severe video problems" {
menuentry "Set video resolution to 640x480" {
terminal_output console
set gfxmode=640x480
set gfxpayload=keep
terminal_output gfxterm
}
menuentry "Set video resolution to 800x600" {
terminal_output console
set gfxmode=800x600
set gfxpayload=keep
terminal_output gfxterm
}
menuentry "Set video resolution to 1024x768" {
terminal_output console
set gfxmode=1024x768
set gfxpayload=keep
terminal_output gfxterm
}
menuentry "List all supported video resolution" {
videoinfo
echo "Press Enter to continue ..."
read
}
menuentry "Use video resolution not listed in this menu" {
echo "Enter video resolution (WxH e.g. 800x600), press Enter to abort."
read gfxmode
terminal_output console
set gfxpayload=keep
terminal_output gfxterm
}
menuentry "Start Fatdog64 with the chosen resolution" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs nomodeset pfix=xorgwizard savefile=none
initrd /initrd
echo Booting ...
}
}

menuentry "---" { true; }
menuentry "Firmware configuration" {
fwsetup
}
menuentry "Shutdown" {
halt
}
menuentry "Reboot" {
reboot
}

menuentry "Fatdog64 for slow BIOS and bootloaders" {
echo Loading ...
linux /vmlinuz rootfstype=ramfs mergeinitrd1=local:/initrd waitdev=3
initrd /initrd-nano
echo Booting ...
}
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The above file needs to be modified to enable the booting of any of the puppies installed and also to allow the Fatdog64 files to be moved to a directory in this partition.

The OS partition now contains the directories, AtomicPupXXII, dpup-stretch-7.5, Fatdog64-812, friendly-fossa64 and lost+found as well as the files fatdog.png, grub.cfg terminus24.pf2 and UUID. The file UUID contains a copy of the uuid of the partition for reference. The STORAGE partition contains the directories, lost+found, PLOP, s57-2018, someone_else and someone_local and a file UUID. The last partition SNEAKER is currently unused containing only the System Volume Information directory.

The modified grub.cfg file is now as shown in the file below.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
insmod png
background_image /fatdog.png
set timeout=10
menuentry "someone_local Fatdog64 with savefile in USB device" {
search --no-floppy --set=root --fs-uuid 0284e81b-569f-40a6-89c6-de69334c4d9d
echo Loading ...
linux /Fatdog64-812/vmlinuz rootfstype=ramfs waitdev=5
savefile=ram:uuid:0284e81b-569f-40a6-89c6-de69334c4d9d:Fatdog64-812/fd64save-someone_local
initrd /Fatdog64-812/initrd
echo Booting ...
}
menuentry "test Fatdog64 with savefile in USB device" {
search --no-floppy --set=root --fs-uuid 0284e81b-569f-40a6-89c6-de69334c4d9d
echo Loading ...
linux /Fatdog64-812/vmlinuz rootfstype=ramfs waitdev=5
savefile=direct:device:sdd2:Fatdog64-812/fd64save-test
initrd /Fatdog64-812/initrd
echo Booting ...
}

menuentry "friendly-fossa64" {
search --no-floppy --set=root --fs-uuid 0284e81b-569f-40a6-89c6-de69334c4d9d
echo Loading ...
linux /friendly-fossa64/vmlinuz psubdir=/friendly-fossa64
pmedia=usbflash pfix=fsck pupsfs=/friendly-fossa64/puppy_fossapup64_9.5.sfs
initrd /friendly-fossa64/initrd.gz
echo Loading
}
menuentry "AtomicPupXXII" {
search --no-floppy --set=root --fs-uuid 0284e81b-569f-40a6-89c6-de69334c4d9d
echo Loading ...
linux /AtomicPupXXII/vmlinuz psubdir=/AtomicPupXXII
pmedia=usbflash pfix=fsck pupsfs=/AtomicPupXXII/puppy_slacko_7.0.sfs
initrd /AtomicPupXXII/initrd.gz
echo Loading
}
menuentry "dpup-stretch-7.5" {
search --no-floppy --set=root --fs-uuid 0284e81b-569f-40a6-89c6-de69334c4d9d
echo Loading ...
linux /dpup-stretch-7.5/vmlinuz psubdir=/dpup-stretch-7.5
pmedia=usbflash pfix=fsck pupsfs=/dpup-stretch-7.5/puppy_stretch_7.5.sfs
initrd /dpup-stretch-7.5/initrd.gz
echo Loading
}
menuentry "s57-2018" {
search --no-floppy --set=root --fs-uuid 12bb610b-85c2-412b-992c-a9009f9baacd
echo Loading ...
linux /s57-2018/vmlinuz psubdir=/s57-2018
pmedia=usbflash pfix=fsck pupsfs=/s57-2018/puppy_slacko_5.7.sfs
initrd /s57-2018/initrd.gz
echo Loading
}
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

With this modified grub.cfg in the root of the OS partition it is possible to boot into any of the four puppies but although you can boot into Fatdog64-812, make some changes and save them the save folder is not found on subsequent boots. The second of the two Fatdog menu entries contains the line

savefile=direct:device:sdd2:/Fatdog64-812/fd64save-test

suggested in an error message. This did not help and would not have been a satisfactory fix in any case as as the usb stick would probably have been
seen as sdx on a different computer.

So now to my question. What should the menuentry be for Fatdog? (and for the other puppies are the other menu entries correct or are they working despite the changes that have been made?)

TIA
Ken
PS My apologies for embedding three long text files in my post but I got into a tangle trying to attach them.

I now believe the savefile bit should have been

savefile=ram:uuid:0284e81b-569f-40a6-89c6-de69334c4d9d:/Fatdog64-812/

i.e. the name of the save folder should not have been at the end.

I have now created a new usb stick using the limine bootloader from easyOS
edited 220802.

Could I also put in a related question...

I am working on Limine Installer, a GUI for the Limine bootloader. Works on both legacy-BIOS and UEFI computers.

It is currently detecting frugally-installed pups, and also detects frugally-installed Fatdogs.
But it is only passing commandline options that would suit the pups, a line of code from the script:

KERNEL_CMDLINE=psubdir=${iPATH} pmedia=${PMEDIA}

where PMEDIA is either "atahd" for hdd, or "ataflash" for ssd.

Would this be enough for Fatdog also?
What about that "rootfstype=ramfs"?

Note also, Limine specifies full URI of vmlinuz and initrd like this:

    KERNEL_PATH=guid://${iPARTUUID}/${iVMLINUZ}
    MODULE_PATH=guid://${iPARTUUID}/${iINITRD}

where $iVMLINUZ and $iINITRD include the path, ex: /fatdog/811/vmlinuz

Various ways to specify the URI, by f.s. label also:

    KERNEL_PATH=fslabel://${iLABEL}/${iVMLINUZ}
    MODULE_PATH=fslabel://${iLABEL}/${iINITRD}

Limine Installer currently detects a frugally-installed Fatdog by looking for vmlinuz and a big initrd, like this:

   ###find fatdog###
   INITRDS="$(find ${MOUNTPOINT} -mindepth 2 -maxdepth 4 -type f -name initrd | sed -e "s%^${MOUNTPOINT}%%")"
   for bINITRD in $INITRDS
   do
    [ "$bINITRD" == "" ] && continue
    bPATH="${bINITRD%/*}"
    [ -d ${MOUNTPOINT}${bPATH}/.session ] && continue #easyos
    [ -f ${MOUNTPOINT}${bPATH}/easy.sfs ] && continue #easyos
    [ ! -f ${MOUNTPOINT}${bPATH}/vmlinuz ] && continue
    #fatdog has a big initrd, with sfs inside...
    bSIZE=$(stat -c %s ${MOUNTPOINT}${bPATH}/initrd) #size in bytes.
    [ $bSIZE -lt 145125632 ] && continue #ex size: 445125632 (fatdog 811)
    echo "Found Fatdog"
    echo "NAME='Fatdog'
VERSION=''
VMLINUZ='${bPATH}/vmlinuz'
INITRD='${bPATH}/initrd'" > /tmp/limine-installer/i-fatdog-${fdCNT}

...is that a valid assumption? Do all versions of Fatdog have the sfs inside initrd?

Ken, for a stick that can be booted across different computers you should substitute "device:sdd2", which ties the savefile location to a PC hardware property thus to a specific PC, with "uuid:XXX" or label:YYY", which ties the savefile location to a property of your USB stick. You can find a comprehensive description of fatdog savefile parameters in Fatdog's help (both the question mark icon on the desktop or the online help version). Which mechanism between uuid or label you decide to use is a matter of convenience but do it right. The uuid is given by the system at partitioning time, while the label is given by you on or after partitioning the stick. The uuid is practically truly unique, so it identifies _that_ stick and no other. The label can be unique if you take care of choosing a unique label, e.g. not "STICK" or "USB128MB" and the like but "2207220317" like current date+time or some other suitable labelling scheme. To determine the XXX or YYY values of label or partition uuid run lsblk -o name,fstype,label,partuuid,size,vendor,model in a terminal or use Gparted.

PS. I didn't have time to look at the details of your attached configuration files, sorry.

BarryK wrote: ↑Fri Jul 22, 2022 9:10 am

Code: Select all

KERNEL_CMDLINE=psubdir=${iPATH} pmedia=${PMEDIA}

where PMEDIA is either "atahd" for hdd, or "ataflash" for ssd.

Would this be enough for Fatdog also?

No.

What about that "rootfstype=ramfs"?

No. There's an online resource that should be very helpful - Fatdog's primer for Puppy Linux users http://distro.ibiblio.org/fatdog/web/fa ... index.html. It covers boot options near the top of the page.

BarryK wrote: ↑Fri Jul 22, 2022 9:17 am

...is that a valid assumption?

Sure. it's good as a starting point.

Do all versions of Fatdog have the sfs inside initrd?

versionsinstallations: No but my guess is that most do. Users with slow BIOS can choose to extract the base sfs from initrd or to boot with the so called nano initrd. In both cases initrd's size will be small. We don't know the percentage of users with this type of setup - but I'm one of those

Further to my original questions, how does grub2 find the grub.cfg file in the second partition of the USB stick. The label is, by default "OS" and the uuid is often "0284e81b-569f-40a6-89c6-de69334c4d9d". This depends on whether the second partition was merely re-sized or deleted and re-created. For my application I want to be sure that when booting from the usb stick grub does not find any other grub.cfg which might exist on the PC.

My menu entries for the puppies contain the line:
search --no-floppy --set=root --fs-uuid 0284e81b-569f-40a6-89c6-de69334c4d9d
or in the case of s57-2018 in the third partition
search --no-floppy --set=root --fs-uuid 12bb610b-85c2-412b-992c-a9009f9baacd
This works but is it optimal? I do not even know what this line is saying

This entry at the beginning of the grub.cfg does not find the save file and an error which flashes past contains the information "could not find fd64save.ext4 anywhere" despite the savefile option.
Have I made a typo or have I got the whole option incorrect?
insmod png
background_image /fatdog.png
set timeout=10
menuentry "someone_local Fatdog64 with savefile in USB device" {
echo Loading ...
linux /Fatdog64-812/vmlinuz rootfstype=ramfs waitdev=5
savefile=ram:uuid:0284e81b-569f-40a6-89c6-de69334c4d9d:Fatdog64-812/fd64save-someone_local
initrd /Fatdog64-812/initrd
echo Booting ...
}

TIA
Ken

@step
Thanks for the link, I read-up on Fatdog kernel boot parameters, and added what seems right to the Limine Installer, and have released version 1.0:

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

Now need someone to try it on a computer that has a frugal Fatdog installed, and any other OS's, and find out if everything is detected and the correct entries created in the Limine configuration file 'limine.cfg'

@superchook
If Grub2 continues to confuse you, as it did me, you might find Limine to be an easier experience.

In the Limine PET that I posted, there is a script /usr/local/limine-installer/find-installations, and in it you will see a line where it rejects all USB drives, only scans internal drives

ALLPARTS="$(grep -o -E 'sd[a-z][1-9]+$|mmcblk[0-9]p[0-9]+$|nvme[0-9]n[0-9]p[1-9]+$' /proc/partitions)"

eCNT=1; pCNT=1; lCNT=1; wCNT=1; dCNT=1; mcCNT=1; ecCNT=1; fdCNT=1
for aDEV in $ALLPARTS
do
 [ "$aDEV" == "" ] && continue
 
 #ignore usb drives...
 aDRV="$(echo -n "$aDEV" | sed -e 's%[0-9]*$%%' -e 's%p$%%')" #ex: sdb
 [ ! -e /sys/block/${aDRV} ] && continue #precaution.
 USBflg="$(readlink /sys/block/${aDRV} | grep -o '/usb')"
 [ "$USBflg" ] && continue

...that code could be reversed, so rejects every drive that is not USB.

Limine Installer will then scan the USB drive and generate 'limine.cfg' with entries for all the found frugally installed pups.

Note, though, the syntax is very simple, and it is easy to create entries for limine.cfg manually. For example, using the partition UUID:

:Puppy Linux EasyPup (partition sda6, path easypup/2.2.12)
    PROTOCOL=linux
    KERNEL_CMDLINE=psubdir=easypup/2.2.12 pmedia=atahd
    KERNEL_PATH=guid://86cd1e71-cf5f-4cb8-87dc-a7dcecec0f50/easypup/2.2.12/vmlinuz
    MODULE_PATH=guid://86cd1e71-cf5f-4cb8-87dc-a7dcecec0f50/easypup/2.2.12/initrd.gz

Or, can specify the partition label, say "superchook2":

:Puppy Linux EasyPup (partition sda6, path easypup/2.2.12)
    PROTOCOL=linux
    KERNEL_CMDLINE=psubdir=easypup/2.2.12 pmedia=atahd
    KERNEL_PATH=fslabel://superchook2/easypup/2.2.12/vmlinuz
    MODULE_PATH=fslabel://superchook2/easypup/2.2.12/initrd.gz

Though, I think "pmedia=ataflash" would be correct for the usb-stick.

For a Fatdog installation, perhaps the kernel commandline could be:

savefile=direct:uuid:${UUID}:<path to savefile>

where you get $UUID from the 'blkid' utility.

Installation to the usb-stick is a piece of cake. The Installer does it, but it is very easy to do manually.
You can make the usb-stick bootable on both BIOS and UEFI computers:

The boot partition must be vfat and have boot-flag and esp-flag set.
I presume that you would also have a ext4 partition with frugally-installed pups.
Just copy 'limine.cfg' and 'limine.sys' to top-level in the boot partition,
and BOOTX64.EFI to /EFI/BOOT/ in the boot partition.
Then run, for example of usb-stick being sdb:
# limine-deploy /dev/sdb

...that's it done!
I haven't tried it, but Limine can also boot ISOs, you would need to study the docs on the project page.

There is also another, even simpler syntax:

:Puppy Linux EasyPup (partition sda6, path easypup/2.2.12)
    PROTOCOL=linux
    KERNEL_CMDLINE=psubdir=easypup/2.2.12 pmedia=atahd
    KERNEL_PATH=boot://2/easypup/2.2.12/vmlinuz
    MODULE_PATH=boot://2/easypup/2.2.12/initrd.gz

That means partition number 2 on the drive you have booted from.
That syntax would suit you perfectly.

Syntax is described here:

https://github.com/limine-bootloader/li ... /CONFIG.md

Many thanks for your postings. I may have to change bootloaders but that would mean starting from scratch. My current USB stick boots four different puppies with no problems. It is only the Fatdog specific savefile= that is giving me grief. Unless the "search" line is interfering. I try a bit longer.
cheers,
Ken

superchook wrote: ↑Sun Jul 24, 2022 11:27 am

Many thanks for your postings. I may have to change bootloaders but that would mean starting from scratch. My current USB stick boots four different puppies with no problems. It is only the Fatdog specific savefile= that is giving me grief. Unless the "search" line is interfering. I try a bit longer.
cheers,
Ken

If you decide to add EasyOS frugal install, it is pretty simple. On the kernel commandline:

wkg_uuid=<f.s. uuid> wkg_dir=<path>

Or, instead of wkg_uuid, you could have wkg_label=<f.s. label>

Easy would be installed in a partition, and in a path. The path can be any depth, say "/easyos/dunfell". To do the frugal install, you just copy 'vmlinuz', 'initrd' and 'easy.sfs' into /easyos/dunfell, then create a GRUB entry.

You would have to tell grub how to find 'vmlinuz' and 'initrd' -- I am unfamiliar with grub syntax, but from what I have seen other people doing, it would be something like this:

menuentry "EasyOS" {
insmod part_gpt
insmod ext2
insmod search_fs_uuid
search --no-floppy --fs-uuid --set=root b80c1ef6-51a8-4c34-a992-62062a1a83c4
linux /easyos/dunfell/vmlinuz rw wkg_uuid=b80c1ef6-51a8-4c34-a992-62062a1a83c4 wkg_dir=easyos/dunfell
initrd /easyos/dunfell/initrd

...just my guess!

Note, you only need the one GRUB entry for EasyOS, as boot choices, such as filesystem-check, or no-X, or rollback, can be made by a menu in the initrd, or via the Shutdown menu.

BarryK wrote: ↑Sun Jul 24, 2022 1:34 am

@step
Thanks for the link, I read-up on Fatdog kernel boot parameters, and added what seems right to the Limine Installer, and have released version 1.0:

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

Now need someone to try it on a computer that has a frugal Fatdog installed[...]

I'd be interested but I really can't at the moment - at least not until mid August. I'm travelling light with only Fatdog booting from an old MacBook. Getting Linux to boot on a Mac was quite challenging (had to befriend the Mac firmware boot manager and use refind...). I'm going to pass until I can return to a standard wintel notebook.

I have "outflanked" my original problem i.e. savefile=ram:uuid:0284e81b-569f-40a6-89c6-de69334c4d9d:/Fatdog64-812/fd64save-someone_local not finding my savefile by moving it out of the Fatdog64-812 directory.
In that case the savefile command or option is not needed but this is a messy solution as I wanted all the operating systems to have all their files and directories in their own directory.
I will leave this mystery now but will return to it later.
cheers,
Ken

superchook wrote: ↑Sat Jul 23, 2022 5:02 am

This entry at the beginning of the grub.cfg does not find the save file and an error which flashes past contains the information "could not find fd64save.ext4 anywhere" despite the savefile option.
Have I made a typo or have I got the whole option incorrect?
insmod png
background_image /fatdog.png
set timeout=10
menuentry "someone_local Fatdog64 with savefile in USB device" {
echo Loading ...
linux /Fatdog64-812/vmlinuz rootfstype=ramfs waitdev=5
savefile=ram:uuid:0284e81b-569f-40a6-89c6-de69334c4d9d:Fatdog64-812/fd64save-someone_local
initrd /Fatdog64-812/initrd
echo Booting ...
}

TIA
Ken

Hi Ken,

that error message seems to indicate that grub is looking for fd64save.ext4. I didn't see anything particularly wrong with your menu entry, but something might be amiss with it anyway. Even though it looks fine, did you use the Fatdog "Savefile Argument Builder" from the Control Panel Utilities tab to generate the correct code? Also, when you set up the savefile, did you make it a savefile or a save folder?

Maybe that's helpful.

Dan

Hi @superchook . I am butting in where I probably shouldn't, but following on from Dr Dan's post, if you are using a savefile rather than a save folder, does that savefile end with an extension (e.g. ".ext4")? If so, might adding that to the end of the "fd64save-someone_local" part of the savefile line work? That is "fd64save-someone_local.ext4" if the savefile label ends in ".ext4".
Thanks.

[Edit] Oops. I think you indicate earlier in the thread that you might be using a save folder rather than a savefile. If so "fd64save-someone_local" would be a directory, and the relevant part of the savefile line might need to be modified to "fd64save-someone_local/". Hopefully it might work, but you can never be sure of anything I post.
Thanks again.

In response to dr_Dan and baldronicus, the "savefile" is indeed a save folder and the savefile= that I used was modelled on the line which works from the SSD on this computer. There three partitions on the SSD the first boots into Linux Mint which provides the grub2 bootloader. A 40_custom file in the /etc/grub.d folder of the Linux Mint installation is used to add the entries for the Fatdog64-812 installation on the third partition. These work fine and I use Fatdog64-812 as my everyday OS. Other family members have their own savefile directories within the Fatdog64-812 directory on the third partition. It is only on usb sticks created by "dd"ing the
usb-boot-mbr.img and putting the savefile directories inside the Fatdog64-812 directory that I run into trouble. I will not be at the computer for most of today but will be experimenting with adding Fatdog to an easyOS usb stick.
cheers,
Ken

Ken,

if I read your code correctly, your savefile parameter is on its own line, not on the linux line of the someone_local Fatdog64 entry:

menuentry "someone_local Fatdog64 with savefile in USB device" {
search --no-floppy --set=root --fs-uuid 0284e81b-569f-40a6-89c6-de69334c4d9d
echo Loading ...
linux /Fatdog64-812/vmlinuz rootfstype=ramfs waitdev=5
savefile=ram:uuid:0284e81b-569f-40a6-89c6-de69334c4d9d:Fatdog64-812/fd64save-someone_local
initrd /Fatdog64-812/initrd
echo Booting ...
}

From the Fatdog64 Boot Options help article:

If you use GRUB, the parameters are passed on the kernel line.

I looked up the grub.cfg on my only grub-using machine, and it is on the same line.

I hope that helps.

Dan

Hi @superchook . I hope the eagle eye of Dr Dan has provided the solution to the savefile problem. I suspect so since you have marked the thread "(solved, I think). On a another read I have noticed that you have edited the first post.
An apology should also be made by me for posting in a thread so marked.

However, I had wanted to refer to another concern that you had raised in the thread, but thought I should wait until the savefile problem was resolved.

An important consideration regarding the following is that I don't know what I am writing about, there is no understanding of the workings of bootloaders etc..

It is all supposition, but I think/hope reasonable supposition.

Like yourself I have been curious about how the second partition was set up to function with respect to a USB drive where the usb-boot-mbr.img had been used.

I think that the post by BarryK, regarding setting the second partition as the default boot device/partition using Limine, gives a very strong clue.

Essentially, I think that some code/configuration in the first (ESP) partition on the USB drive is set to achieve the same thing, but via the grub/grub2 bootloader environment rather than the Limine one.

Given that things are set up to boot the files on the second partition of the drive by default, then there presumably would be no need to tell the system where to look for the files if they are on that second partition.
Hence you would not need any "search... set-root..." lines in the stanzas of the grub.cfg file if the files you are wanting to boot are on that second partition.
Which is, of course, how the default grub.cfg file provided with the image is set up.
You do, of course, have to specify the "search... set-root..." stuff if you are attempting to boot files on another partition or device.
I think it sort of follows that files on a system hard drive would not be booted unless the system is explicitly instructed to do so via entries in the grub.cfg file.

It is realised that this is both just supposition, and is now possibly redundant, since I think you might now be having success with an EasyOS based USB drive. However, I felt I had to mention it.

I guess while I am at it I should mention that I had contemplated posting about some changes that I had made to a later "Multi-boot" (for want of a better term) USB drive after realising some mistakes (or maybe less than optimal decisions) I had made with the first one.
This would only have been for your consideration, we all have different objectives etc.. However, I think I might let it rest as this would not be the correct thread and, again, it is probably redundant.

Please accept my apologies if I have only been wasting yours, and others, time.

Thanks.