similar to: fts_squat + virtual => crash

Hi there, first, thanks a lot for syslinux! I'm aware that one can't mix syslinux 4's MBR + ldlinux.sys with syslinux 6's COM32R modules. Fair enough. Now, I need to know how strong this "versions *must* match" requirement is when dealing with different versions of syslinux 6.x. E.g. * MBR and ldlinux.sys installed by syslinux 6.03-pre1 * all *.c32 modules

Hi, I have just installed dovecot and offlineimap on my laptop for syncing with my gmail, and reading in gnus, as outlined in this article: http://sachachua.com/wp/2008/05/08/geek-how-to-use-offlineimap-and-the-dovecot-mail-server-to-read-your-gmail-in-emacs-efficiently/ I am using Debian Etch, and I am the only user. The only change I made to the default dovecot.conf file was to set:

Hi, we're trying to solve CVE-2008-4870 = rhbz#436287 = dovecot.conf is world readable - possible password exposure. This problem seems to be little more complicated than we thought. dovecot.conf can contain passphrase for ssl key, which is available for everyone since dovecot.conf has world readable permissions. (In CVE's description is note that it RHEL's/Fedora's problem,

Hi, first, thanks a lot, Ady and Gene, for your prompt and very useful replies! Ady wrote (11 Jun 2014 20:18:43 GMT) : > Although I haven't tested it lately, the Tuxboot tool should be able > to use the version of Syslinux included in your ISO images so to > transfer it to a (USB) drive. Since it works for other Debian-based > distros, it might answer to your needs.

Actually your Syslinux config is less relevant than the kernel config file. Indeed Syslinux infers the method to use from the kernel image itself. I assume the .config is public. I will take a look as soon as I can Thomas Le 04/08/2015 14:09, intrigeri via Syslinux a ?crit : > Thomas Letan via Syslinux wrote (04 Aug 2015 09:27:38 GMT) : >> Are you using EFI Handover Protocol? >

Hi, Ady: > I am using the ISO image from TAILS as an excuse to "tease" TAILS' devs > and other users of Syslinux. If intrigeri (TAILS developer) "bites". > then users reading this mailing list might learn one thing or two about > Syslinux (6.04-pre1+). :) > 1_ EFI/BOOT/isolinux.bin is probably a mistake (or misunderstanding) > originated in the ISO

Hi, [ouch, it take me a year? thank you all for this very interesting thread that I'm going to finish reading now.] Pete Batard via Syslinux: > I'll skip the EFI part of tails (that uses grub/EFI) to talk only > about the BIOS/Syslinux part. JFTR Tails uses GRUB only for 32-bit UEFI. We use syslinux for BIOS and 64-bit UEFI. > So, one thing Rufus will need to do is find a

On Sun, Aug 9, 2015 at 3:44 AM, intrigeri via Syslinux <syslinux at zytor.com> wrote: > Hi, > > back in February, Scot Doyle proposed two patches: > > http://www.syslinux.org/archives/2015-February/023209.html 0a2dbb339 > http://www.syslinux.org/archives/2015-February/023179.html 83aad4f6 -- -Gene

I'm going to get the hang of this mailing list eventually. Apologies for any duplicate emails.. >Ian Bannerman: >> While I did know the .exe variant was not official / untrusted, >Is there a special reason for this ? (Except the known bugs which affect Linux binaries, too.) Not really. I had never found a convincing source for it and had seen previous list entries like this

On 2017.04.12 08:35, intrigeri via Syslinux wrote: > Wait, no, there's some misunderstanding going on here. Okay, I stand corrected. Knowing that tails was Debian based, I was assuming that you also followed the Debian boot model, which uses GRUB for UEFI. Considering that this is the Syslinux mailing list, it might be a tactless question to ask, but is there any reason why you chose

Hi, since the Tails ISO grew from ~900MB to ~1.1GB, we see this warning when running isohybrid on it: isohybrid: Warning: more than 1024 cylinders: 1045 isohybrid: Not all BIOSes will be able to boot this device I guess that's fully expected. And, as expected, we get boot failure reports from users. So, my question is: is there a "known optimal" combination of isohybrid

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:

Actually, as you may have questions with some elements you'll see in the log, and especially: Detected Syslinux version: 6.03/20150819 (from '/EFI/BOOT/isolinux.bin') So I should point out that EFI/grub is actually used by the tails people to chain load EFI/Syslinux (hence the ldlinux.e64, ldlinux.c32 as well as isolinux.bin one also sees in /efi/boot/). As a result, in the

Hi, I have a setup with apache 2.2.6 proxying requests to a cluster of 5 mongrels. Occassionally, I receive the following error in the logs: [Tue Oct 30 12:00:28 2007] [error] (70007)The timeout specified has expired: proxy: pass request body failed to 127.0.0.1:8013 (127.0.0.1) from 213.205.247.171 () [Tue Oct 30 12:00:28 2007] [error] [client 213.205.247.171] Handler for proxy-server returned

> 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 > Maybe I'm missing something, but this has been working flawlessly for > us in Tails so far. What exactly fails? Are you using EFI Handover Protocol? It might explain the difference Thomas

Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux leaves long mode in kernel_jump assembly routine does not follow AMD64 specifications. More precisely: 1. After setting a new GADT, `cs` has to be refresh by doing a long jump, but it is not 2. Other segments have to be updated, but they are not 3. Disabling paging has to be done before disabling long mode, but the

> Actually, as you may have questions with some elements you'll see in the > log, and especially: > > Detected Syslinux version: 6.03/20150819 (from '/EFI/BOOT/isolinux.bin') > > So I should point out that EFI/grub is actually used by the tails people > to chain load EFI/Syslinux (hence the ldlinux.e64, ldlinux.c32 as well > as isolinux.bin one also sees in

Correct base's type to match its initialization from prot_mode_base and passage to syslinux_memmap_find(). Tested with extlinux. Signed-off-by: Scot Doyle <lkml14 at scotdoyle.com> --- com32/lib/syslinux/load_linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index 06ae2a9..ac73729 100644 ---

Hi, Ian Bannerman: > I did not know the Perl version did not support the EFI/Mac changes. Comparing the help texts of http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/isohybrid.c and http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/isohybrid.in shows that the latter lacks: -u --uefi Build EFI bootable image -m --mac Add AFP table support