search for: sectors_per_track

...ample, let's assume: -h 255 -s 63 ISO size: 1'085'736'960 bytes ( > 1GiB) This size happens to be a multiple of: 63, 255 and 2048 So, using these values in my suggested loop. 1_ Calculate a potential Cylinders (amount) value; Cylinders= trunc(roundup( ISO_size / (Heads * Sectors_per_track * 512)) Cylinders (1st attempt)= trunc(roundup(1085736960/(255*63*512)) Cylinders (1st attempt)= trunc(roundup(132)) Cylinders (1st attempt)=132 2_ Calculate 'Cylinders * Heads * Sectors_per_track'; 132 * 255 * 63 = 2120580 3._ Is the result of the calculation (as explained in t...

Hi, > Hopefully I am explaining it better this time. Our ideas of implementation are supposed to yield the same result. As said, i am willing to implement my proposal in a copy of isohybrid.c, if somebody wants to test it. Advantages and disadvantages should be obvious. Interested users please send util/isohybrid.c from your local SYSLINUX source code installation to me. Just to be sure

...a cylinder size divisible by 4. This would work. But with -h 255 -s 63 it could waste up to 32,899,072 bytes. > Hopefully I am clarifying my suggestion in this email: > [...] loop to step #2. The algorithm would not have to loop for a solution but could compute it directly: if (Heads * Sectors_per_track) is divisible by 4 # Pad up to next full cylinder align_factor = 1 else if (Heads * Sectors_per_track) is divisible by 2 # Pad up to next full double cylinder align_factor = 2 else # Pad up to next full quatruple cylinder (nearly 32 MB) align_factor = 4 In isohyb...

This patch-set deals with some of the style isues in blkvsc_drv.c. We also get rid most of the "dead code" in this file: 1) Get rid of most of the forward declarations in this file. The only remaining forward declarations are to deal with circular dependencies. 2) Get rid of most of the dead code in the file. Some of the functions in this file are place holders - they

This patch-set deals with some of the style isues in blkvsc_drv.c. We also get rid most of the "dead code" in this file: 1) Get rid of most of the forward declarations in this file. The only remaining forward declarations are to deal with circular dependencies. 2) Get rid of most of the dead code in the file. Some of the functions in this file are place holders - they

...w i get your intention. You want to align the > resulting ISO to 4 full cylinders in order to avoid > the need for a cylinder size divisible by 4. > No :). I want to align to resulting isohybrid image size to 4 full cylinders *only when necessary*. Depending on the values of Heads and Sectors_per_track (whether they are command-line parameters the user established, or whether they are the result of other command-line parameters the user might have used), the amount of Cylinders might not need to be a multiple of 4 (e.g. '-h 64 -s 32'). But it also depends on the size of the ISO image...

More cleanup. In this patch-set we deal with the following issues: 1) While a Linux guest on Hyper-V can be assigned removable media devices (DVD, floppy etc), these devices are not handled by the Hyper-V block driver. So, we cleanup all the dead code dealing with removable media devices. 2) There were multiple functions to retrieve information about the device. Since much of

More cleanup. In this patch-set we deal with the following issues: 1) While a Linux guest on Hyper-V can be assigned removable media devices (DVD, floppy etc), these devices are not handled by the Hyper-V block driver. So, we cleanup all the dead code dealing with removable media devices. 2) There were multiple functions to retrieve information about the device. Since much of

The latest upstream merge changed struct block_device_operations: This merge got rid of blkvsc_media_changed and introduced the function blkvsc_check_events. This broke all the patches that were sent after the tree was closed the last time. This is a resend of this patch-set to account for this change in the kernel. More cleanup. In this patch-set we deal with the following issues: 1) While a

The latest upstream merge changed struct block_device_operations: This merge got rid of blkvsc_media_changed and introduced the function blkvsc_check_events. This broke all the patches that were sent after the tree was closed the last time. This is a resend of this patch-set to account for this change in the kernel. More cleanup. In this patch-set we deal with the following issues: 1) While a

...e relevant / important for his goal / needs? > > But how to explain all this mess ? Even we two have problems > to get a common understanding. Hopefully I am clarifying my suggestion in this email: 1_ Calculate a potential Cylinders (amount) value; 2_ Calculate 'Cylinders * Heads * Sectors_per_track'; 3._ Is the result of the calculation a multiple of '4'? 3.a_ If it is, continue; 3.b_ If it is not, then add '1' to the attempted Cylinders (amount) value and loop to step #2. 4_ Other conditions and logic already present in the isohybrid source code still apply (e.g. the Cy...

...table by some users. So, instead of immediately making such a big jump (in the resulting size), I am suggesting to repeat (loop) the calculation (please do not interpret the following pseudo-code as actual functions / operations in C, it is not): Cylinders= trunc(roundup( ISO_size / (Heads * Sectors_per_track * 512)) where 'ISO_size' is the size, in bytes, of the input ISO image. (Note: roundup(n.0) = n) With this first-attempt value, calculate the potential resulting isohybrid image size. Is it a multiple of 2048 bytes? If the potential resulting isohybrid image size is a multiple of 2048...

Hi, Ady wrote: > I am not so sure that using a different pair of '-h' and '-s' values > would be better than using 255/63. But 255 * 63 is not divisible by 4 and thus can cause trouble with virtual DVD-ROM. > Most BIOS and most partition editors would assume this geometry. I cannot tell for BIOSes, but partition editors have options to set heads-per-cyl and

Hi, it would be interesting to know for what solution TAILS decides and whether any problems arise with it. ------------------------------------------------------- On with the fundamental discussion of MBR cylinders: Ady wrote: > 1_ The resulting ISO9660 file system size shall be a multiple of 2048 > (bytes_per_sector). The known ISO production programs comply to this condition.

When I boot Hardware Detection Tool 0.2.3 or 0.2.5 with syslinux 3.73 or 3.74-pre11, I get: ======================================================= Hardware Detection Tool 0.2.5 by Erwan Velu CPU: Detecting DISKS: Detecting DISK 0x80: 0x80: PCI ATA : sectors = 703282600, s/t = 63 head = 255: EDD=3.0 ======================================================= Then it halts. Ctrl + Alt + Del

Hi, Ady wrote: > We seem to be suggesting to just dd' the first 432 bytes of their USB > devices with Martin's isohybrid Yes. As long as it is not about the old Macs which the APM of Fedora and some Gentoo ISOs wants to make boot, and not about ISOs made with isohybrid options --partok -ctrlhd0 --forcehd0. > which would be the step-by-step instructions for users of other >

...ion gets align_factor = 4. So isohybrid would pad up to quadruple cylinders. Well, 132 is already such a quadruple. > When comparing your code with my suggested calculation, I see that your > conditionals do not account for the ISO image size, but only for > "Heads" and "Sectors_per_track". The existing code in isohybrid already handles the size for padding up to a target granularity. Currently the target is always a single cylinder. My new code only decides about the granularity of 1, 2, or 4 cylinders. > ISO size: 1'085'736'960 bytes+2048 bytes > [...] &...

...ot;'head' multiple of 4" would be as valid as using a different pair of values that would cover the total size of the ISO image. And, with "temporal" I meant that users can supply whatever they want (to the isohybrid tools included in Syslinux) as 'heads' and 'sectors_per_track' values without changing the source code (or without waiting for a new release). So, while choosing 255/63 has some intentional purpose, choosing 252/63 is as arbitrary as choosing, for instance, 240/63, or 128/32, with the difference that "252" does not coincide with any particul...

Hi, Ady wrote: > Let's not forget that the goal usually is to select CHS values so that > the resulting (optical and/or other) media would boot correctly in as > many systems as possible Agreed. But we now have a report about failure of 255x63 on a popular pseudo-hardware, when the ISO is presented as DVD-ROM. (Probably there is no complaint when it gets presented as hard disk.)

...sectors = htole16 (32); + floppy->bootsect.nr_fats = 2; + floppy->bootsect.nr_root_dir_entries = htole16 (0); + floppy->bootsect.old_nr_sectors = htole16 (0); + floppy->bootsect.media_descriptor = 0xf8; + floppy->bootsect.old_sectors_per_fat = htole16 (0); + floppy->bootsect.sectors_per_track = htole16 (0); + floppy->bootsect.nr_heads = htole16 (0); + floppy->bootsect.nr_hidden_sectors = htole32 (0); + floppy->bootsect.nr_sectors = htole32 (floppy->data_last_sector + 1); + + floppy->bootsect.sectors_per_fat = + htole32 (floppy->fat_clusters * SECTORS_PER_CLUSTER...