It's very important, you see, because putting a save file on a different partition confuses apps looking for /home. For instance, sfs_load's queue gets all messed up._________________The Way of the Samurai

I noticed some code later on in the script that says something about one gig, not sure what it means. All I know is that if I make partition 4 bigger than a gig, it doesn't even create partition 4, and just makes partition 1 that size.

No Flash, I'm talking about the BootFlash script which prepares a usb stick for booting Puppy. I can't seem to make it create the "partition 4" (which contains all of your system files) bigger than a gig. I was hoping someone understood the code better than me, and could help me fix it._________________The Way of the Samurai

I am drawing a blank on this term ComboFormat, sadly I've haven't gone thru every nook and cranny in puppylinux since version 2.17

Could you give us the full path string to the script you are asking about also let us know if this is one of the many special versions of official puppylinux like wary,quirky,racy, etc, 'blessed' spin-offs (slacko, Fatdog64, etc), or something someone tweaked and gave that a new name (oh, so, so many )...

As you likely know, when choosing the ComboFormat option for bootflash, you are creating a flash drive capable of being booted on any PC that will boot via USB from a hard disk, ZIP disk, or floppy. It is the requirement of making the flash drive appear as a ZIP disk that is giving you trouble here.

In order to make the flash drive appear as a ZIP disk, bootflash must set the drive geometry to indicate that it has 32 sectors per track and 64 heads. Since the old Cylinder/Head/Sector (CHS) addressing scheme used by the BIOS had a limit of 1024 cylinders, the size of the drive is limited to 1024 * 64 * 32 = 2,097,152 sectors. Since sectors hold 512 bytes, this results in a limit of 512 * 2,097,152 = 1,073,741,824 bytes, or exactly one gibibyte (GiB).

And since the first track is used for stuff like the the master boot record and boot loader code, the size available for your partition is reduced by 32 sectors, so 512 * 2,097,120 = 1,073,725,440 bytes.

I am not aware of any way to make a larger partition and still make it fool some BIOS into thinking that it is a ZIP disk.

Is it possible to remove that functionality (or break it) and keep the rest of the ComboFormat mode?

Maybe. You could experiment by removing the --zip option from line 328 (of the version of bootflash that you attached).

That would remove the geometry limitation of 64 heads, which would allow for a much bigger partition size.

A side-effect is that it would also remove the ZIP disk requirement that the boot partition be partition 4. So it would revert to partition 1. This means you would have to change line 331 from:

Code:

PUPBOOTPART="${USBDRV}4"

to:

Code:

PUPBOOTPART="${USBDRV}1"

And later, in the section below "#now create partition to fill remaining space on usb drive...", to make that partition 2, not partition 1, you would need to make a change -- perhaps change line 350 from:

Code:

if [ "$RADIO_ISO" = "true" ];then

to:

Code:

if [ "$RADIO_ISO" = "true" ] || [ "$RADIO_ALL" = "true" ];then

Or, while testing, you could just disable that whole section and either ignore any remaining space on the drive, or add a partition manually.

That's just a couple of things I noticed. There could certainly be other changes necessary. I have no extra USB drives kicking around, so have tested none of this. These suggestions come with no guarantee.

As you have already noted, on line 277 Barry has a warning about the FDD flavor: "only choose this for drives no greater than 1GB." Perhaps that warning would also apply to the ComboFormat flavor, since it also allows the flash drive to look like a floppy drive. I don't know, since I don't know the reason for the warning. Would some BIOS faint at the sight of a floppy drive greater than 1GB in size? Maybe yes; maybe no. If you feel like experimenting, try it and see.

After making the changes you suggested, there are now two partitions, sdx1 and sdx2 instead of 1 and 4, with 1 being the large one, and 2 using the remaining space but being unmountable. No ldlinux.sys file, either.

I was a little surprised that it didn't copy the ldlinux.sys file, so I took another look at the script, and think I see the problem.

When it creates a partition to fill the remaining space on the drive, it now correctly creates partition 2, not partition 1, but when it goes to format the partition it still formats partition 1, which wipes out ldlinux.sys and leaves partition 2 unformatted and unmountable.

This is because it uses the ${PUPSAVEPART} variable when formatting. Previously, in the original script, the partition used for the pupsave file was this new partition, so it worked OK. But now, in your modified script, the pupsave file will be on the partition already created by makebootfat, so the code needs to be adjusted.

Change line 364 from:

Code:

mkdosfs -F 32 -n storage /dev/${PUPSAVEPART} #FAT32.

to:

Code:

mkdosfs -F 32 -n storage /dev/${USBDRV}${PARTNUM} #FAT32.

and line 368 from:

Code:

mkdosfs -n storage /dev/${PUPSAVEPART} #FAT16.

to:

Code:

mkdosfs -n storage /dev/${USBDRV}${PARTNUM} #FAT16.

This ensures that the partition that is formatted by mkdosfs is the same as the partition just created.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum