similar to: [PATCH 1/2] Support iso images over 2GB in isohybrid

FYI -------- Original Message -------- Subject: IPAPPEND on http://syslinux.zytor.com/faq.php#config Date: Mon, 31 Jan 2005 15:20:00 +0100 From: Pascal Terjan <pterjan at mandrakesoft.com> Organization: Mandrakesoft To: david at weekly.org Hi, I needed to get the MAC from which we booted using pxelinux (in order to know which interface we used to boot). I found reading the source that

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

Op 2014-06-20 om 15:56 schreef Ady: > > The Perl variant, isohybrid.in, seems to be getting left behind > regarding several patches. I don't recall whether there is at least > some mention in the isohybrid docs about the existence of 2 variants > included in Syslinux (and that is in addition to other isohybrid > methods outside Syslinux). Is there any reference? >

Hi, > Now, I have a question: what about the "offset" parameter? How it > modifies our assumptions and calculations if the "offset" parameter is > not zero? The offset influences only the start address of the partition. The alignment goal is about the end address. So these concepts are nearly independent. Of course, partition start must be smaller than partition

When running isohybrid again it's nice to preserve the MBR id There was some partial code to support setting the id using non existing to_int, but no way to use it. Signed-off-by: Pascal Terjan <pterjan at mandriva.com> --- utils/isohybrid.in | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/utils/isohybrid.in b/utils/isohybrid.in index

EFI systems typically don't support booting off ISO 9660 filesystems, even if written to USB sticks. This patch adds support for generating a GPT that covers the stick as well, with an additional partition entry pointing purely at the secondary El Torito image. When burned to CD the secondary El Torito will be used as an EFI boot image, and when written to a USB stick the GPT partition

> > Same result as yours. > > > Have a nice day :) > > Thomas > I was under the impression (apparently the wrong one) that your pseudo-code was adding 4 cylinders to the first example, from 132 to 136, which would be non-optimal. Since I am not a developer, I believe you when you say that such jump won't happen :). Perhaps the code will be more clear to me

Dear R developers, I am writing some C code that loads multiple images into a list of R matrices. The whole R object is created within the C code. To simplify coding, elements of the list are first created as vectors and then converted to corresponding matrices using setAttrib(x, R_DimSymbol, s). Generally the code works fine except for one detail. Applying setAttrib sets ALL elements

> Hi, > > > Hopefully I am explaining it better this time. > > Our ideas of implementation are supposed to yield the > same result. > Hmm, I am not sure. Or perhaps I am misunderstanding your code. Let me try with an example (or two). For this example, let's assume: -h 255 -s 63 ISO size: 1'085'736'960 bytes ( > 1GiB) This size happens to be a

Hello, I currently have a problem : There is a domain administrators group which I filled as "admin users" in smb.conf. They can do what they want on files, that's fine. Problem is the files they create are owned by root. Let's explain why this is a problem for me : - People in this group can't access their files in an unix way (ftp, shell, ...) - If one of them get removed

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

I have addressed all the issues that I know about (including, hopefully, the isohybrid version dependence...). I would like to release this this week so please let me know as soon as possible if this version is "go". -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

> > I wrapped the essential code into a standalone program for > playing with a few numbers: What about '-h 255 -s 63 , ISO size 1085736960' ? > I expect the average waste to be a bit less than 16 MB. Yes, but slightly misleading. For example, the "16MB average" is relevant for 255/63. Some user reading the code might not know the whole reasoning for: >

Hi, > What about '-h 255 -s 63 , ISO size 1085736960' ? -h 255 -s 63 , ISO size 1085736960 : align_factor= 4 , padding= 0 , image size= 132.000000 cylinders ----------------------------------------------------------------- Code of isohybrid_test_mockup.c : ----------------------------------------------------------------- #include <stdlib.h> #include <stdio.h> int

> I proposed -h 252 -s 63 because it yields the largest > possible cylinder size which is divisible by 4 (i.e. > the byte count is divisible by 512*4 = 2048). > -h 240 -s 63 would fulfill this constraint, too. > Size limits are 252*63*1024*512 = 8,323,596,288 > resp. 240*63*1024*512 = 7,927,234,560 bytes. > > > The workaround cannot be temporal, because the

Hi, intrigeri wrote: > We're using `isohybrid -h 255 -s 63' [...] > isohybrid produces ISO > images whose size is not a multiple of 2048 bytes. Seems to be intentional. http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/isohybrid.in # Target image size: round up to a multiple of $h*$s*512

> 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?

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: > my suggestion to modify the _amount_ of Cylinders was intended to > overcome the "by 4" (or rather, "by 2048") issue. Now 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. This would work. But with -h 255 -s 63 it could waste up to 32,899,072 bytes. >

> 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. And my suggestion to modify the _amount_ of Cylinders was intended to overcome the "by 4" (or rather, "by