similar to: Testing for ISO boot in init-premount

Varugis Kurien via Syslinux <syslinux at zytor.com> writes: > I have a scenario where I need to test for whether I have booted via a > syslinux ISO image in init-premount as opposed to (say) PXE boot. Is > there any variable that I can test for this? I don't think you can do this without bootloader support. And if you can configure your boot loaders, then you can freely vary

Hi All, I am working on creating storage driver domain with xen-4.3.0 . I am referring this - http://wiki.xen.org/wiki?title=Storage_driver_domains&oldid=9371 I have created Storage domain with xl utility of xen, then followed above wiki for rest of the steps, additionally I did install blktap-dkms package also- Following xen processes are running on Domain 0:

Hi All, I am working on creating storage driver domain with xen-4.3.0 . I am referring this - http://wiki.xen.org/wiki?title=Storage_driver_domains&oldid=9371 I have created Storage domain with xl utility of xen, then followed above wiki for rest of the steps, additionally I did install blktap-dkms package also- Following xen processes are running on Domain 0:

Hello, when booting via pxelinux I can change the image to be booted based on client uuid, and MAC-Adresses. http://www.syslinux.org/wiki/index.php/PXELINUX#Configuration Now when using syslinux I would like to be able to also do this as I like to use one usb flash-drive for booting multiple machines. Is this possible or impossible by design because syslinux always uses syslinux.cfg? Regards

On Sun, Sep 20, 2015 at 8:33 AM, syslinux-bot for Gene Cumm <gene.cumm at gmail.com> wrote: > Commit-ID: e0ac1d2fdf7d7c58457f3796a12561cce95ca29f > Gitweb: http://www.syslinux.org/commit/e0ac1d2fdf7d7c58457f3796a12561cce95ca29f > Author: Gene Cumm <gene.cumm at gmail.com> > AuthorDate: Sun, 20 Sep 2015 08:30:55 -0400 > Committer: Gene Cumm <gene.cumm at

Hi, Adam Williamson > I think it would be better if someone else confirms there's actually > something to fix. There was indeed the shortcomming that byte values 128 to 255 were treated as whitespace and mapped to "_" resp. "". This would affect non-ASCII characters of UTF-8 or old ISO-8859. But the reason why gcc 5 made a difference to gcc 4.9 is not found yet.

core and the simple menu do not interpret the IPAPPEND/SYSAPPEND directives in the same way. Which is the proper way? Either way, this should be clarified in the documentation. com32/elflink/ldlinux/readconfig.c: } else if ((ep = looking_at(p, "ipappend")) || (ep = looking_at(p, "sysappend"))) { uint32_t s = strtoul(skipspace(ep), NULL,

I did confirm earlier that this does work, and combined with a MENU HIDDEN to hide it from the visible menu it is a possible solution. I originally assumed that this was due to that going down a different code path and did not mention it, apologies. The scale of my menu makes doubling/tripling menu entries less ideal, though. Do we consider it intended functionality that modules such as whichsys

On 06/13/2013 10:15 PM, Gene Cumm wrote: > On Thu, Jun 13, 2013 at 8:08 PM, Gerardo Exequiel Pozzi > <vmlinuz386 at yahoo.com.ar> wrote: >> Hello >> >> While testing PXE booting, I decided to change IPAPPEND to the new >> SYSAPPEND and does not work: nothing is appended to command line. >> >> I tested using menu.c32 and vesamenu.c32, same issue.

On Sun, Jun 23, 2013 at 3:16 PM, Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar> wrote: > I guess the bug is here (com32/menu/readconfig.c) > > 910 } else if (looking_at(p, "ipappend") || looking_at(p, > "sysappend")) { > 911 if (ld.label) > 912 ld.ipappend = atoi(skipspace(p + 8)); > 913

Hi, poma wrote: > - "unsigned char c;" does not solve the problem > > - "c >= 0 && c <= ' '" solves the problem for the current git What the ... ?!? My proposal of "(c >= 0 ... )" was only made to avoid the need for a type change of variable "c". Both proposals should be equivalent ... on the first morning glimpse they

Hello While testing PXE booting, I decided to change IPAPPEND to the new SYSAPPEND and does not work: nothing is appended to command line. I tested using menu.c32 and vesamenu.c32, same issue. --------------------------------------------------------------------- SERIAL 0 38400 UI boot/syslinux/vesamenu.c32 LABEL arch64_nbd MENU LABEL Boot Arch Linux (x86_64) (NBD) LINUX boot/x86_64/vmlinuz

The following changes since commit 4ff8fcac8e7b5046987dee15592ab510ab343aa8: Matt Fleming (1): Merge branch 'menu-ipappend-1-for-mfleming' of git://github.com/geneC/syslinux into elflink are available in the git repository at: git://github.com/geneC/syslinux.git ipappend-fix-for-mfleming Gene Cumm (2): core & menu: fix IPAPPEND/SYSAPPEND conversion doc/ &

On Tue, Jun 30, 2015 at 4:29 PM, poma <pomidorabelisima at gmail.com> wrote: > "A real serial port that can reliably operate at 115200 8n1 may be > necessary." > > Gene, is there something special in "A real serial port" usage, compared to emulated? I should restate: A serial port that responds on BIOS IO port 3F8h that can reliably operate at 115200 8n1 may

I think my oven is broken, but maybe I have the recipe wrong. I've been trying to utilize the lwIP stack and dmi information to avoid iPXE use. I can do a SYSAPPEND 0x00080 and it shows up in /proc/cmdline after booting the kernel, but tcpdump is not revealing the cookies as described during HTTP calls in the documentation. Trying the magic "SENDCOOKIES" parameter outside of an

> Let me know what kind of info would be useful for debugging the > mboot issue, and I will collect it all. Also, EFI is still somewhat > new to me, so I don't know how to find the UEFI firmware revision > or UEFI extension agents. I'll see if it's in the server manual, > but if you have an idea how one typically finds those, I'd appreciate > any pointers. >

Yes, MENU HIDE would work as well, but still requires additional entries for each case (possible entries for pxe, syslinux, isolinux, cpu architectures, PCI devices, lua scripting scenarios, etc.) By blocking modules, I meant that as long as I disable user editing of menu commands via ALLOWOPTIONS 0, I cannot use any of the following com32 modules without creating duplicate LABEL entries for each

On Sun, Jun 23, 2013 at 11:09 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sun, Jun 23, 2013 at 11:06 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >> core and the simple menu do not interpret the IPAPPEND/SYSAPPEND >> directives in the same way. Which is the proper way? Either way, >> this should be clarified in the documentation. > > To be clear:

please pull git://charm.itp.tuwien.ac.at/mattems/klibc/.git maks for the change: maximilian attems: [klibc] simplify nuke fixes boot failures due to unexpected error returns usr/utils/nuke.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/usr/utils/nuke.c b/usr/utils/nuke.c index 01b300f..9470bcf 100644 --- a/usr/utils/nuke.c +++

On 02.07.2015 11:10, Thomas Schmitt wrote: > Hi, > > poma wrote: >> - if (c <= ' ' || c == '\x7f') { >> + if (c <= ' ' && c == '\x7f') { > > As Geert Stappers pointed out (and can be verified by a > simple test program), the reinstated term > (c <= ' ' && c == '\x7f') >