How to make ComboFormat partition larger than a gig?

Using applications, configuring, problems
Message
Author
User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

How to make ComboFormat partition larger than a gig?

#1 Post by Ghost Dog »

Hi,

I'm trying to adjust the value of "count" in line 323 so that the sdb4 partition (comboformat) is larger than a gig, like so:

Code: Select all

dd if=/dev/zero of=$(WKGPATH)/image256m bs=1024 count 1132544
I want to do this so that I can have space for a savefile in the "system" partition.

But I find that if I set any value larger than one gigabyte that it actually formats sdb1 as that size, and fails to create the sdb4 partition at all.

Does anybody know a way I can get around this problem?

Thanks.
Last edited by Ghost Dog on Mon 29 Apr 2013, 11:21, edited 1 time in total.
The Way of the Samurai

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#2 Post by Ghost Dog »

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

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#3 Post by Ghost Dog »

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.

Help!!!!!
The Way of the Samurai

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#4 Post by Flash »

I haven't the slightest idea what you're talking about, so I feel fully qualified to ask if this would be any help. :lol:

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#5 Post by Ghost Dog »

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

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#6 Post by Ted Dog »

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 :roll: )...

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#7 Post by Ghost Dog »

I've attached the Bootflash script. It's one of Barry's official scripts. I'm trying to tweak it so as to have more than one gig for the "system partition" (Partition 4) in ComboFormat.

I see something about 1 gb on line 277, but I'm not sure that's related.
Attachments
bootflash.gz
Bootflash script
(7.84 KiB) Downloaded 225 times
The Way of the Samurai

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#8 Post by Flash »

But it might also help if you told us where you found it; what is the path to its location in which version of Puppy?

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#9 Post by Ghost Dog »

/usr/sbin

All versions.
The Way of the Samurai

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#10 Post by npierce »

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.

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#11 Post by Ghost Dog »

Thank you, npierce!

That's very interesting. For me, it's not as important to have it also be disguised as a zip disk, as to have room for a nice save file. Zip disks are pretty much obsolete now.

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

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#12 Post by npierce »

Ghost Dog wrote: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: Select all

PUPBOOTPART="${USBDRV}4"
to:

Code: Select all

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: Select all

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

Code: Select all

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.

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#13 Post by Ghost Dog »

Well, that nearly worked. :)

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.

Thanks though. :D
The Way of the Samurai

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#14 Post by npierce »

You're welcome.

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: Select all

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

Code: Select all

mkdosfs -F 32 -n storage /dev/${USBDRV}${PARTNUM} #FAT32.
and line 368 from:

Code: Select all

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

Code: Select all

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.

Good luck.

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#15 Post by Ghost Dog »

I've only tested it on the one computer, but it looks like it works.

Partition 1 has the ldlinux.sys file, Partition 2 takes up the rest of the drive and is mountable, and with Puppy on it, it boots just like it's supposed to.

Thank you so much!
Attachments
bootflash.gz
Zip disk feature in ComboFormat removed.
(7.84 KiB) Downloaded 209 times
The Way of the Samurai

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#16 Post by npierce »

You're welcome.

I am happy to read that you got it working. :)

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#17 Post by Ghost Dog »

Here's something weird:

If I make the first partition 1350 mb:

Code: Select all

#create 256M empty file...
   dd if=/dev/zero of=${WKGPATH}/image256m bs=1024 count=1382400
...it works great. But if I make it another 512mb bigger, it suffers from the same problem as before - the second partition is created with the remaining space, but is unmountable.

Code: Select all

sh-4.1# mount /dev/sdf2 /mnt/sdf2
mount: you must specify the filesystem type
The Way of the Samurai

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#18 Post by npierce »

Does partition 1 seem OK? Does it boot?

What's the output from:

Code: Select all

fdisk -l /dev/sdf
blkid /dev/sdf1
blkid /dev/sdf2

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#19 Post by Ghost Dog »

It boots, and the first partition seems to work normally.

Code: Select all

sh-4.1# fdisk -l /dev/sdf

Disk /dev/sdf: 4089 MB, 4089446400 bytes
126 heads, 62 sectors/track, 1022 cylinders, total 7987200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1   *          32     3786239     1893104    b  W95 FAT32
/dev/sdf2         3786240     7987199     2100480    b  W95 FAT32
sh-4.1# blkid /dev/sdf1 
/dev/sdf1: UUID="5233-BBCE" TYPE="vfat"
sh-4.1# blkid /dev/sdf2 
/dev/sdf1: UUID="5233-BBCE" TYPE="vfat"
/dev/sdf: UUID="5233-BBCE" TYPE="vfat"
[and a few entries for my partitions on sda... nothing about sdf2]
The Way of the Samurai

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#20 Post by npierce »

Ghost Dog wrote:

Code: Select all

sh-4.1# blkid /dev/sdf2
/dev/sdf1: UUID="5233-BBCE" TYPE="vfat"
/dev/sdf: UUID="5233-BBCE" TYPE="vfat"
[and a few entries for my partitions on sda... nothing about sdf2]
I was going to say that the second partition must be quite corrupt for blkid to be finding information about the first partition on it, and severely corrupt if it is finding information about your hard drive on it. But I used losetup to associate a file full of zeros with a loop device and tried blkid with it. Sure enough, it reports information on all block devices. So apparently that is a quirk of blkid: when given an unformatted device, it throws up its hands and gives information about every other block device it can find. :)

So it appears that for some reason the second partition just isn't getting formatted, or is being incorrectly formatted, which is no surprise. The question is why.

I notice that /dev/sdf1 has only 1893104 blocks, which is only 1848.734 MiB, which is significantly smaller than the 1350 + 512 = 1862 that you were aiming for. (I think makebootfat may use 32 blocks for the stuff before the first partition, but that only accounts for 0.031 MiB.) So I am guessing that bootflash didn't find enough temporary space to make partition 1 the size that you asked for. (It actually creates the image in a temporary file on an already mounted filesystem (in /tmp/, /root/, or /mnt/home/) before moving it to your flash drive.)

As you know, normally bootflash creates a 256 MiB empty file. It searches for space containing 300 MiB (to allow a little room to breathe). You will see three lines in the script like this:

Code: Select all

 if [ $FREEM -lt 300 ];then
You should change the "300" in those lines to something a little bigger than the size of the file you are creating. (In this case "2000" should probably be sufficient.)

If you are not running a full install, my guess is that you have a PC with 2 GiB, and the layered filesytem in RAM had enough room to create a 1350 MiB file, but not an 1862 MiB file. But bootflash was only looking for 300 MiB of space, which it found in /tmp/ so it tried to create the file in /tmp/.

If that is what happened, then changing those three lines will allow bootflash to keep looking until it finds sufficient space at /mnt/home/, assuming that /mnt/home is a symlink to a mounted partition with sufficient space.

BUT . . .

But this may not be your only problem. While it is easy to see why the above situation could result in partition 1 being smaller than expected, I see no clear reason why it would prevent partition 2 from being formatted correctly. Perhaps mkdosfs needed some space to work and couldn't find any. Anyway, when RAM gets filled up, all bets are off as to what happens.

So changing those three lines may or may not fix partition 2, but let's eliminate that problem first, then we can revisit the lack of proper format for partition 2, if that problem still exists.

Post Reply