similar to: unable to make USB-ZIP using rufus_v1.4.5

Test, test one two, test > > > > Thanks in advance, > > > > Prof S W Damle > > I don't know whether Pete Batard (RUFUS' developer) have read your > messages. And this message is to see if the "reply to list mungling" is gone. (Check the E-mail headers ( this message was/is a "reply to list" )) Groeten Geert Stappers

> Hello Sir, > > Following are the settings I used, > > Device: NO _Label (O:) > > Partition scheme and target system type: MBR partition scheme for BIOS > or UEFI computers > > File System: FAT32 > > Cluster size: 4096 bytes (Default) > > New Volume label: > > (i)Quick format > (ii)Create bootable disk using: MS-DOS > (iii)Create

Hello, rufus_v1.3.1 suggested by "Bernd Blaauw" is working fine. Sorry to say unable to make USB-ZIP using rufus_v1.4.5 Your valuable suggestions/guide lines please. Thanks in advance, Prof. S W Damle

On 03/02/16 16:19, Ady via Syslinux wrote: > > That's not what common users are forced to deal with. Syslinux's binary > files in the wild come from different sources (official upstream > Syslinux, distros' packages, others). > > Since v.6+ (and possibly, even before it) a re-build might show some > inconsistencies between "the same version" of

Pete Batard via Syslinux <syslinux at zytor.com> writes: > One solution to avoid that would be to embed in Rufus all possible > .c32 modules from Syslinux, alongside with the 'ldlinux.sys' version > we have, and replace them on the USB. Why not install instead an arbitrary version of Syslinux and replace all .c32 files with the modules of the installed version? --

[disclaimer: I am the author of Rufus] Hi, On 2014.01.15 10:10, Thomas Schmitt wrote: > As producer of MBRs i wonder where that LBA-flag is located. > In bit 0 to bit 6 of byte 446 (where bit 7 means active/bootable) ? I haven't looked at what GParted does, so I may be off mark, but I have a strong suspicion that this LBA "flag" is a fake flag that simply indicates if a

Hi Shao, You're right, "a=b=<immediate value>;" wasn't the actual issue. On 2016.03.06 20:34, Shao Miller via Syslinux wrote: > If this change is simply due to a mental note about an incident where a > compiler once complained about this type of thing The problem was due to the following warning when compiling for 64-bit using using the latest WDK (7600.16385.1),

On 2016.03.06 13:13, Gene Cumm wrote: > Did Visual Studio actually complain about this one? WDK compiler (which I also use) if I recall correctly. At any rate, some older compilers do not like double initializations like this one, and I don't think this change should be much of a contention point, since it doesn't introduce any liability. Regards, /Pete

I get a redefinition warning on _GNU_SOURCE when compiling with MinGW, and while I could see that this #define was introduced in e4fc44 [1], but the reason to introduce it is not mentioned, and I can't really see a good reason to have it, especially as MSVC will happily compile that source. So far I have found no evidence that _GNU_SOURCE applies to memset/memmove/memcpy, which are the

More MSVC compatibility fixes, for packed structures. NB: In case you are aware of the issues that may come with MS vs GCC packing, so far, I have not seen evidence of detrimental impact from using ms_struct packing in MSVC (vs gcc_struct, which is explicitly specified for MinGW), with regards to the sections of code I am using in Rufus. -------------- next part --------------

> 2015-11-19 17:30 UTC+01:00, Nicolas Cornu via Syslinux <syslinux at zytor.com>: > > - Remove padsize argument as it is never used. > > - Add an usage printed when $file is not set or --help, -h > > is the first argument. > > - Add basic tests for this script. > > --- > > mbr/checksize.pl | 27 ++++++++++++++++++--------- > >

On Mon, 7 Mar 2016, Pete Batard via Syslinux wrote: > I could also say something about the ISOHybrid _HACK_, which clearly is not > something that was ever intended by the people who designed ISO-9660, and > that could "either work if you're lucky or fail if you're not". Looking at > the recent history of this mailing list, it does seem to me like ISOHybrid >

On Mon, 7 Mar 2016, Pete Batard via Syslinux wrote: > On 2016.03.07 17:55, Ferenc W?gner wrote: >> Why not install instead an arbitrary version of Syslinux and replace all >> .c32 files with the modules of the installed version? > > I mentioned that in my previous mail. But I reckon it was easy to miss > as that mail was rather long: > > > "One solution to

On 3/3/2016 07:43, Pete Batard via Syslinux wrote: > [...] as far as I am concerned, 'A "version" such as "6.03" [is not] > enough'. [...] I'd like to help to improve Syslinux with regards to version-related concerns. Having typed that, perhaps we could discuss your (or Rufus') specific needs, in parallel? Do I understand correctly that the primary

Here are some thoughts: 1. Customized Syslinux could be customized such that it refuses to boot from USB. No amount of version-matching nor downloading from the same source can help with that scenario. A different Syslinux would be needed, by definition (of the customizer) 2. Slightly less bad is where an ISO or CD/DVD is made with a key piece of non-ISOLINUX Syslinux missing

On 3/8/2016 07:23, Pete Batard via Syslinux wrote: > [...] the merging of ldlinux.sys and isolinux.bin, which I would very > much like to rally people on this list into seeing as beneficial. [...] My understanding is that isolinux.bin and ldlinux.bin are pretty much twins[1]. If I understand correctly, you'd like the latter to be tacked onto the former because people are too stupid

Hi, i began to implement a common lookup function for SUSP and Rock Ridge entries: /* Obtain the payload bytes of all SUSP entries with a given signature. @param fs The data source from which to read CE blocks. @param dir_rec Memory containing the whole ISO 9660 directory record. @param sig Two characters of SUSP signature. E.g. "NM", "ER", ...

On Tue, 8 Mar 2016, Pete Batard via Syslinux wrote: > On 2016.03.08 03:10, BALATON Zoltan via Syslinux wrote: >> The difference is that the >> headache in this case is for those tech savvy people creating the hybrid >> iso who should be able to figure it out so the non-tech savvy end users >> should not have a problem with it as long as used as intended. > >

H. Peter Anvin schreef op 9-8-2013 7:37: > Sorry. If you are substituting any files you should substitute them all. I assume it's not possible to store a copy of the LDLINUX.SYS binary at the end or inside of either ISOLINUX.BIN or LDLINUX.C32 then? Then at least it could be extracted, for those distributions not having LDLINUX.SYS / SYSLINUX(64).EXE present on their CD. Having

On Fri, Aug 9, 2013 at 1:54 PM, Pete Batard <pete at akeo.ie> wrote: > Also, if the best answer I get is that I'll just have to be creative with > trying to compensate for the version lockdown, could I at least get an > answer to my question of how one can determine the exact version of a .c32 > file? In general, no. There's a magic number but only indicates the major