search for: bytes_per_sector

Hello, can someone give me a short summary on the status of support for sector sizes >512bytes in SYSLINUX? The installer obviously still doesn't support it, at least it complains about "unsupported sector size" when used on a 4k-sector disk. I read somewhere that this is only a problem of the installer, and that SYSLINUX itself would work if it got installed "by other

...{ int rc; vfs_statvfs_struct svfs; if (!lp_unix_extensions()) { return ERROR_NT(NT_STATUS_INVALID_LEVEL); } rc = SMB_VFS_STATVFS(conn, ".", &svfs); if (!rc) { + + { + SMB_BIG_UINT dfree,dsize,bsize,block_size,sectors_per_unit,bytes_per_sector; + + if (get_dfree_info(conn,".",False,&bsize,&dfree,&dsize) != (SMB_BIG_UINT)-1) { + block_size = lp_block_size(snum); + if (bsize < block_size) { + SMB_BIG_UINT factor = block_size/bsize; + bsize = block_size; + dsize /= factor; +...

...x's code, we should at least test the values that are around or close to the limits between FAT12/16/32. For simplicity, I'll give basic examples (which I have not truly analyzed; developers could / should test relevant code). Example A: Volume_Total_Sectors: 66'463 FAT type: FAT32 Bytes_per_sector: 512 Sectors_per_Cluster: 1 Sectors_per_FAT: 511 ---> this value should _not_ be accepted as valid minfatsize; 512 should be OK. Example B: Volume_Total_Sectors: 4'187'104 FAT type: FAT32 Bytes_per_sector: 512 Sectors_per_Cluster: 64 Sectors_per_FAT: 511 ---> this value should _not_...

Hi Ady, I won't comment on the reasons why the original computation was wrong, but thanks for the detailed analysis. On 2016.02.26 08:05, Ady via Syslinux wrote: >> Thus we can finally get a formula for Fs that satisfies the above: >> >> Fs = (To - Rs + Nf * Cs) / ((Ss * Cs / Fe) + Nf) + 1 > > I believe such formula is slightly inaccurate too. > > My

...(and potential wear out) of storage media (e.g. so called "flash / pen drives" and SSDs). So let's attempt to list the minimal conditions, and the additional desired (preferred) conditions, for the algorithm: 1_ The resulting ISO9660 file system size shall be a multiple of 2048 (bytes_per_sector). 2_ The resulting size of the isohybrid image shall be a multiple of 2048 bytes. 3_ The resulting partition size should better match the end of a complete cylinder (the latter is the value to be calculated and optimized). 4_ The additional zero-padding tail (so to match the calculated complete...

...t, the code. I placed this at the bottom of the main loop in com32/modules/disk.c as a simple test of writing to the disk: printf(" Host bus: %s, Interface type: %s\n\n", d->edd_params.host_bus_type, d->edd_params.interface_type); zero_buf = calloc(1, d->edd_params.bytes_per_sector); for(int sector = 0; sector < d->edd_params.sectors; sector++){ err = write_verify_sectors(d, sector,zero_buf,1); if (err == -1) { printf("sector: %d error: %d\n", sector, disk_errno); //disk_errno is always zero here } printf("sector: %d wrote:%d\r", sector,...

...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. (Theoretically there could be other block sizes between 512 byte and 64 KiB. But 2048 is the address granularity of optical media and so no other block sizes have been seen yet.) > 2_ The resulting size of the isohybrid image s...

...gt; this round-up-to-multiple-of-2048-bytes operation itself? > > [Tails] https://tails.boum.org/ > [details] https://labs.riseup.net/code/issues/8891#note-9 > > Cheers, > -- > intrigeri Any (common) ISO image size should be a multiple of 2048 bytes, as this is the normal bytes_per_sector value. For isohybrid images, the result should be a multiple of 1MiB (1048576 bytes), which is itself a multiple of 2048 bytes. So, in addition to adding the corresponding MBR and partition table to the original ISO image, the isohybrid tool should also check that the ISO image is a multiple o...

...ers); + SET_TABLE_STRING_INT(L, "heads", info.edd_params.heads); + SET_TABLE_STRING_INT(L, "sectors", info.edd_params.sectors); + // size in mb as lua number type is uint32_t + SET_TABLE_STRING_INT(L, "size", + (uint64_t) info.edd_params.sectors * info.edd_params.bytes_per_sector + / (1024 * 1024)); + SET_TABLE_STRING_STRING(L, "host_bus", info.edd_params.host_bus_type); + SET_TABLE_STRING_STRING(L, "interface", info.edd_params.interface_type); + lua_settable(L, -3); + i++; + } + return 1; +} + +static const luaL_Reg disklib[] = { + {"g...

Hi, at [Tails] we're in the process of shipping hybrid ISO images by default again. We're using `isohybrid -h 255 -s 63' to do that (thanks to the advice we got on this mailing-list a few months ago!). And then, we've discovered that sometimes, isohybrid produces ISO images whose size is not a multiple of 2048 bytes. Who cares? ... may you ask. Well, apparently, VirtualBox does:

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

...n > 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. > (Theoretically there could be other block sizes between > 512 byte and 64 KiB. But 2048 is the address granularity > of optical media and so no other block sizes have been seen > yet.) > > > > 2...

...h; + out[1] = (c & 0x300) >> 2 | s; + out[2] = c & 0xff; +} + +static int +create_partition_boot_sector (const char *label, struct virtual_floppy *floppy) +{ + memcpy (floppy->bootsect.oem_name, OEM_NAME, + sizeof floppy->bootsect.oem_name); + + floppy->bootsect.bytes_per_sector = htole16 (SECTOR_SIZE); + floppy->bootsect.sectors_per_cluster = SECTORS_PER_CLUSTER; + floppy->bootsect.reserved_sectors = htole16 (32); + floppy->bootsect.nr_fats = 2; + floppy->bootsect.nr_root_dir_entries = htole16 (0); + floppy->bootsect.old_nr_sectors = htole16 (0); + fl...

Add nbdkit-floppy-plugin, “inspired” by qemu's VVFAT driver, but without the ability to handle writes. The implementation is pretty complete, supporting FAT32, LFNs, volume labels, timestamps, etc, and it passes both ‘make check’ and ‘make check-valgrind’. Usage is simple; to serve the current directory: $ nbdkit floppy . Then using guestfish (or any NBD client): $ guestfish --ro

From: Matt Fleming <matt.fleming at linux.intel.com> This series fixes some bugs and switches the elflink branch to be entirely ELF modules. It applies on top of, http://syslinux.zytor.com/archives/2011-April/016369.html The deletions in the diff stat below are mainly from deleting com32/elflink/modules (finally!). Now there should be no duplicate code because we don't need COM32 and