search for: isosize

...and I can't figure it out. I use Webmin, which basically just creates an iso and then uses cdrecord to burn it and it worked fine with previously installed CentOS 4 (I wiped and reinstalled about 8 months ago). This is the command that Webmin tries to execute... cdrecord -v dev=0,0,0 speed=4 -isosize \ '/home/Linux/CentOS-4/CentOS-4.2-i386-bin4of4.iso' The result of cdrecord -scanbus at bottom of email. Log of error just below. Help appreciated... Craig cdrecord: No write mode specified. cdrecord: Asuming -tao mode. cdrecord: Future versions of cdrecord may have different drive depe...

...ourse they are equivalent. Now, I have a question: what about the "offset" parameter? How it modifies our assumptions and calculations if the "offset" parameter is not zero? For example, in isohybrid.c I see: 660: psize = c * head * sector - offset; and 1135: psize = isosize / 512; among others. There are partial equivalents in the Perl variant. Since I am not a developer, I am not really asking about the code. My interest is about how the "partition offset" parameter ([0, 64]) could affect the optimization we have been discussing. Regards, Ady. >...

Sorry if this is a total noob question... I've searched the archives and haven't turned up much. Not turning up much on the web in general, either. I'm working on a project and I'd like to create a Linux bootable ISO disc with an extra chunk of data **outside** the ISO space. This chunk of data might be a 10MB tar/zip. The goal would be to boot into Linux in RAM off the disc

Hi, my proposal is based on a mathematical proof (see mail before) and yours is correct too. They cannot but match. Let's inspect your examples: Ady wrote: > ISO size: 1'085'736'960 bytes ( > 1GiB) This are exactly 132 cylinders of 255x63. 132 is divisible by 4. So there is no padding needed. > Cylinders (1st attempt)=132 > [...] > 2120580 / 4 = 530145, so

...iso_uuid; uint8_t mode = 0; -enum { VERBOSE = 1 }; +enum { VERBOSE = 1 , EFI = 2 , MAC = 4}; /* user options */ uint16_t head = 64; /* 1 <= head <= 256 */ @@ -61,10 +66,150 @@ uint16_t ve[16]; uint32_t catoffset = 0; uint32_t c = 0, cc = 0, cs = 0; +uint32_t psize = 0, isosize = 0; + /* boot catalogue parameters */ uint32_t de_lba = 0; uint16_t de_seg = 0, de_count = 0, de_mbz2 = 0; uint8_t de_boot = 0, de_media = 0, de_sys = 0, de_mbz1 = 0; +uint32_t efi_lba = 0, mac_lba = 0; +uint16_t efi_count = 0, mac_count = 0; +uint8_t efi_boot = 0, efi_media = 0, efi_sys = 0;...

...*fp = NULL; uint8_t *buf = NULL, *bufz = NULL; - int cylsize = 0, frac = 0; + int cylsize = 0, frac = 0, align_factor, align_cylsize; size_t orig_gpt_size, free_space, gpt_size; struct iso_primary_descriptor descriptor; @@ -1058,9 +1058,20 @@ main(int argc, char *argv[]) isosize = lendian_int(descriptor.size) * lendian_short(descriptor.block_size); free_space = isostat.st_size - isosize; + /* Making sure that the resulting image size is divisible by 2048. + (Can waste nearly 32 MB. Should be done on user request only.) + */ + if ((head * sector) % 4 =...

Hi all, A friend of mine gives me a copy of Centos5 DVD. I then make an iso of it using dd if=/dev/cdrom of=centos5.iso command. I then check it using sha1sum. But the result is different than of listed in Centos website. Should it the same? Or we simply cannot compare sha1sum from burned DVD to that of 'unburned' iso file? Thanks. -- Fajar Priyanto | Reg'd Linux User #327841 | Linux

CentOS-6.9 I am trying to verify a locally created dvd. I am using sha256sum in this fashion: sha256sum /dev/sr0 Which gave this result: sha256sum: /dev/sr0: Input/output error So I tried this: sha256sum /dev/cdrom Which, after some time, also produces: sha256sum: /dev/cdrom: Input/output error What does this mean and how do I fix it? -- *** e-Mail is NOT a SECURE channel

I see there's a memtest on the Linux discs I've created... would it be possible to put another program in place (a module, perhaps?) that can calculate a hash using a certain algorithm (i.e. SHA512 or similar) to validate and print out the hash of the boot ISO before booting it? The integrity of the ISO is absolutely critical. Thanks, Bret