search for: 32mib

> Hi, > > Ady wrote: > > Is this "32MiB" a limitation related to the UEFI specs in any way? Or > > is it relevant for BIOS (non-EFI) too? > > It comes from El Torito specs which are referred to by UEFI 2.4 > specs. In EL Torito 1.0, Figures 3 and 5, "Sector Count" is a 2-byte > "Word". So it c...

...t; EFI from CD/DVD/BD has a soft size limit of 32 MB for its > System Partition. > That's due to the format of El Torito Boot Catalog which > counts the 512-bytes blocks by a 16-bit unsigned integer. @Thomas, If you would be so kind, would you please remind me (us)... Is this "32MiB" a limitation related to the UEFI specs in any way? Or is it relevant for BIOS (non-EFI) too? Is this limitation related to the El Torito "emulation" methods/types (01/02/03)? Is this limitation also valid / relevant for the first/default entry in the Boot Catalog? Or is it only...

Hi, Ady wrote: > So, someone could assert the following reasoning steps: > 1_ We can workaround the Sector Count limitation of 32MiB for > no-emulation methods. If the EFI firmware programmers obey version 2.4, yes. > 2_ The ESP is considered a no-emulation method. >From the view of UEFI 2.4 it is a partition. Partitions may be marked by MBR partition table or by GPT on hard disk (rotating or not), and by EL Torito...

...39;re encountering here, as I have a way to report that to the people in charge of making updates, and we could hopefully improve the status with the help of this community. >So, someone could assert the >following reasoning steps: > >1_ We can workaround the Sector Count limitation of 32MiB for >no-emulation methods. >2_ The ESP is considered a no-emulation method. >3_ From the above assertions, we could conclude that the limitation of >32MiB is not really relevant for the ESP. In order to remove that potential problem, I'm now generating 30 MB boot images. May not so...

...I tried to test it using something like: ./rsync --rsync-path\="$PWD/rsync" -v --bwlimit=100 --progress --copy-devices --write-devices /dev/mapper/vg-pokus1 root at localhost:/dev/mapper/vg-pokus2 where pokus1 & pokus2 are two identically initialized block devices (logical volumes) 32MiB in size. All the data was passed trough local connection without the benefit. (I set --bwlimit low, so I can see evidently the rsync performance). By adding more -v I found, that some stat() call in the generator.c reports destination device size is zero. I added some code handling block device si...

...] [drm] nouveau 0000:00:05.0: Parsing VBIOS init table 2 at offset 0xDE75 [ 15.262666] [drm] nouveau 0000:00:05.0: Parsing VBIOS init table 3 at offset 0xDFF7 [ 15.262675] [drm] nouveau 0000:00:05.0: Parsing VBIOS init table 4 at offset 0xE040 [ 15.262998] [drm] nouveau 0000:00:05.0: Detected 32MiB VRAM (stolen system memory) [ 15.272560] [drm] nouveau 0000:00:05.0: 512 MiB GART (aperture) [ 15.435031] [drm] nouveau 0000:00:05.0: 1 available performance level(s) [ 15.435036] [drm] nouveau 0000:00:05.0: 0: core 475MHz shader 475MHz fanspeed 100% [ 15.435038] [drm] nouveau 0000:00:05.0:...

Hi, Ady wrote: > Is this "32MiB" a limitation related to the UEFI specs in any way? Or > is it relevant for BIOS (non-EFI) too? It comes from El Torito specs which are referred to by UEFI 2.4 specs. In EL Torito 1.0, Figures 3 and 5, "Sector Count" is a 2-byte "Word". So it can count up to 65535. Sec...

Hello, Ady via Syslinux said on Sun, Oct 25, 2015 at 08:15:37PM +0200: >_ Creating filesystem that _does_ conform to ISO-9660; I think the only issue is with a tag. That same image boots with grub 0.99 >_ The fat image should not be bigger than 32MiB, and it should be >aligned. The latter suggestion is usually ignored by almost everyone, >but if we are troubleshooting... Tried with more and less than 30 MB without impatc. Aligned: could you give me an example of how you would create it with dd ? >_ Creating a UEFI-boot-only image......

...w.musique-ancienne.org http://www.medieval.org > _______________________________________________ > Some points to consider, if not for general use then at least for the troubleshooting phase: _ Creating filesystem that _does_ conform to ISO-9660; _ The fat image should not be bigger than 32MiB, and it should be aligned. The latter suggestion is usually ignored by almost everyone, but if we are troubleshooting... _ Creating a UEFI-boot-only image... _ genisoimage is not the same as mkisofs; do not use the former (which has been unmaintained since 2010). BTW, the EFI parameters for mk...

...less than 1%. Additionally, we are talking about an average of 16MiB of padding for "un-padded" images. Current (as of 6.03) isohybrid images are already padded (with a different algorithm), so the additional (differential) "waste" produced by this patch is (much) less than 32MiB, and less than 16MiB on average. In other words, I would suggest using a more accurate wording, and implementing the correction, instead of leaving this issue on the air. Realistically, I would not expect distro maintainers to edit isohybrid.c so to make use of the patch; they will use what is...

...olume. Would 'syslinux.efi' be able to do whatever (and everything) it needs to do under these conditions? Could any kernel be _completely and successfully_ booted under these conditions? Rhetorical question: And then what? Syslinux would have access to the FAT volume (usually less than 32MiB), but it would not be able to access the whole ISO9660 file system (or, in other words, the rest of the optical media, outside the FAT image). Remember, as of version 6.03, Syslinux has no access to other file system volumes other than the one it booted from. Alternatively, instead of using a...

http://bugs.freedesktop.org/show_bug.cgi?id=26986 Summary: TNT2 crashed on startup with 2.6.34-rc1 Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

...up to next full double cylinder align_factor = 2 else # Pad up to next full quatruple cylinder (nearly 32 MB) align_factor = 4 For the example I am presenting here, "Heads*Sectors_per_track" is 255*63, so it is not a multiple of 4 nor of 2. Would you add anyway nearly 32MiB? I assume you wouldn't. Instead, I guess you would first evaluate whether it is already a full "valid" cylinder and that no additional zero-padding would be required. When comparing your code with my suggested calculation, I see that your conditionals do not account for the ISO im...

https://bugs.freedesktop.org/show_bug.cgi?id=36422 Summary: unable to hibernate with nouveau and NV11 [bisected] Product: xorg Version: unspecified Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

Hi, Ady wrote: > * ISO images, > * burnt to _optical media_, > * and using then the resulting _optical media_ to boot in _UEFI mode_, > * in which the _main bootloader_ for such _optical media_ booting in > such _UEFI mode_ is part of The Syslinux Project. I would be willing to try such an ISO with qemu+OVMF. Regrettably my real test iron has no EFI firmware. Do you know the

...r than what the partition table allows; nothing has changed. The purpose of the suggested loop (instead of immediately using an amount of Cylinders multiple of 4) is to minimize the zero-padding. For example, if we were to need '4*255*63*512-1' additional bytes, that would be less than 32MiB to be added to the input ISO image. If the input image size was around 1.2GiB, that's less than %2.56. Depending on the exact size of the ISO image, it could also be much less (the suggested loop would decide). For a geometry of 64/32 (for a size lower than 1GiB), the suggested zero-padding...

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

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

On Thu, Oct 22, 2015 at 1:56 PM, Bruno Cornec via Syslinux <syslinux at zytor.com> wrote: > 3/ Using syslinux.efi in a FAT32 image (similar to the previous 2 > confs) stored on a iso9660 media by genisoimage and its > -eltorito-alt-boot -efi-boot $imagefile -no-emul-boot option doesn't > work. I get a red screen with debug info (attached). However, I'm not >