similar to: PXE Error Reporting

Hello Andreas, Andreas Gruenbacher wrote: > Hello, > > I've recently ran into a problem trying to boot over TFTP using > pxelinux.0. On the console, I got the following message: > > Could not find ramdisk image: initramfs-3.10.0-123.13.2el7.x86_64 > > It took me a while to figure out that the file *could* be found but that > the file permissions were set

Hi, On 01/16/2015 12:19 AM, Sebastian Herbszt wrote: > Andreas Gruenbacher wrote: >> "Loading <FILE>... failed: No such file or directory" when the TFTP >> server replies with "Permission denied" for the kernel or initrd. > [...] > > The (almost untested) patch below should fix this. hmm, probably close but I still get the same "No such file

Sebastian, On 01/15/2015 12:49 AM, Sebastian Herbszt wrote: > which version of pxelinux were you trying? Looks like < 5.x. the one from Fedora 20, syslinux-4.05. It turns out that pxelinux.0 from Fedora 21, syslinux-6.03, reports "Failed to load ldlinux.c32" when ldlinux.c32 can't be read, and "Loading <FILE>... failed: No such file or directory" when the

Hi, On 01/17/2015 12:57 AM, Sebastian Herbszt wrote: >> On 01/16/2015 12:19 AM, Sebastian Herbszt wrote: >>> Andreas Gruenbacher wrote: >>>> "Loading <FILE>... failed: No such file or directory" when the TFTP >>>> server replies with "Permission denied" for the kernel or initrd. >>> [...] >>> >>> The

Hello Andreas, Andreas Gruenbacher wrote: > Hi, > > On 01/16/2015 12:19 AM, Sebastian Herbszt wrote: > > Andreas Gruenbacher wrote: > >> "Loading <FILE>... failed: No such file or directory" when the TFTP > >> server replies with "Permission denied" for the kernel or initrd. > > [...] > > > > The (almost untested) patch

Hello Andreas, Andreas Gruenbacher wrote: > Sebastian, > > On 01/15/2015 12:49 AM, Sebastian Herbszt wrote: > > which version of pxelinux were you trying? Looks like < 5.x. > > the one from Fedora 20, syslinux-4.05. > > It turns out that pxelinux.0 from Fedora 21, syslinux-6.03, reports > "Failed to load ldlinux.c32" when ldlinux.c32 can't be

On 01/18/2015 03:23 PM, Sebastian Herbszt wrote: > > --- tftp-hpa-5.2/tftpd/tftpd.c.orig 2015-01-16 21:45:30.790798281 +0100 > +++ tftp-hpa-5.2/tftpd/tftpd.c 2015-01-18 23:44:28.031177383 +0100 > @@ -1504,6 +1504,8 @@ static int validate_access(char *filenam > return ENOSPACE; > case EEXIST: > return EEXISTS; > + case EACCES: >

Hello Andreas, Andreas Gruenbacher wrote: > Hi, > > On 01/17/2015 12:57 AM, Sebastian Herbszt wrote: > >> On 01/16/2015 12:19 AM, Sebastian Herbszt wrote: > >>> Andreas Gruenbacher wrote: > >>>> "Loading <FILE>... failed: No such file or directory" when the TFTP > >>>> server replies with "Permission denied"

On Fri, Mar 7, 2014 at 2:33 AM, Vieri <rentorbuy at yahoo.com> wrote: > So I take it it's more of a DHCP hack in which: > 1- client boots and gets DHCP response from 10.215.144.7 with PXE syslinux info > 2- client loads pxelinux.0 menu and selects menu that chains to Altiris PXE menu except, instead of calling pxechain.com or pxechn.c32 with the Altiris server's IP address,

On 01/20/2015 12:17 PM, Andreas Gruenbacher wrote: > On 01/20/2015 09:13 PM, H. Peter Anvin wrote: >> I can't remember, but I have a vague recollection that someone >> specifically requested that EACCES be treated the same as ENOENT... > > If that is really necessary then please don't report that condition as > "file not found"; it's really

On 01/20/2015 02:45 PM, Andreas Gruenbacher wrote: > > Sorry, but people with such stupid requirements just shouldn't be > supported. The approach may look alright in a few specific scenarios at > the cost of everyone else. > That is a pretty harsh statement. That is effectively saying "my use case matters more than anyone else's." -hpa

On Thu, 2014-03-06 at 16:52 -0500, Gene Cumm wrote: > > RFC2131, section 4.1, and particularly the second paragraph on page 24. > > Conditionally. "Options may appear only once, unless otherwise > specified in the options document." I don't see any indication of any > options that DO allow it unless "The information is an opaque object > of n

On Tue, Jan 20, 2015 at 3:55 PM, H. Peter Anvin <hpa at zytor.com> wrote: > On 01/20/2015 12:17 PM, Andreas Gruenbacher wrote: >> On 01/20/2015 09:13 PM, H. Peter Anvin wrote: >>> I can't remember, but I have a vague recollection that someone >>> specifically requested that EACCES be treated the same as ENOENT... >> >> If that is really necessary

On 01/21/2015 09:56 AM, H. Peter Anvin wrote: > On 01/20/2015 02:45 PM, Andreas Gruenbacher wrote: >> >> Sorry, but people with such stupid requirements just shouldn't be >> supported. The approach may look alright in a few specific scenarios at >> the cost of everyone else. > > That is a pretty harsh statement. That is effectively saying "my use >

The current code only works iff the tsize option is set. This patch fixes the handling of the OACK packet and makes the code work with all combinations of the tsize and blksize options. Signed-off-by: Sebastian Herbszt <herbszt at gmx.de> diff --git a/core/pxe.c b/core/pxe.c index 81d3e23..a4b8a14 100644 --- a/core/pxe.c +++ b/core/pxe.c @@ -913,8 +913,10 @@ static void pxe_searchdir(char

On 01/20/2015 09:13 PM, H. Peter Anvin wrote: > I can't remember, but I have a vague recollection that someone > specifically requested that EACCES be treated the same as ENOENT... If that is really necessary then please don't report that condition as "file not found"; it's really misleading. Thanks, Andreas

On 01/20/2015 09:55 PM, H. Peter Anvin wrote: > That is, however, the whole point -- the existence of a inaccessible > file should not be visible to the client. > > This is apparently a security requirement in some environments. Sorry, but people with such stupid requirements just shouldn't be supported. The approach may look alright in a few specific scenarios at the cost of

What is required to get the mwi to work? Is it more of a phone subject or *? I have the mailbox= line in sip.conf, but only one extension is named, and in some of the examples, I have seen that there are two... What is that all about and how does it affect the extensions.conf and voicemail.conf? Thanks again..... Just some background as you start seeing my lists, I just started my own business

The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the

On 24/09/2018 13:35, Stephan Bosch wrote: > You can enable `-d -' and `-t - -Tlevel=matching' as well. $ sieve-test -D -d - -t - -Tlevel=matching -c dovecot.conf sieve message sieve-test(james): Debug: Effective uid=1001, gid=10, home=/home/james sieve-test(james): Debug: maildir++: root=/path/to//james/Maildir, index=, indexpvt=, control=, inbox=/path/to//james/Maildir, alt=