similar to: Warm boot ISO image from Linux

----- Forwarded Message ---- From: H. Peter Anvin <hpa at zytor.com> To: For discussion of SYSLINUX and tftp-hpa <syslinux at zytor.com> Sent: Wednesday, November 7, 2007 2:27:47 PM Subject: Re: [syslinux] I'd like to eventually support network console, at least in pxelinux. n schembr wrote: > > Hi, > > Would it be hard to add a network console to syslinux, extlinux

Hi, i wrote: > > Would it be desirable to explain how Fedora et.al. > > created their FAT boot images by help of old or new > > GRUB ? > > (If developers of EFI bootable ISOs are reading this, > > please give a short sketch of the procedure.) piranna at gmail.com wrote: > I did it by including the Linux kernel and the initramfs None of the ISOs i know has this

Hi, Curt Brune wrote: > At the risk of contributing to the 'urban legends' and the 'salads' I apologize to all communities who hand out correct info. :)) > http://lukeluo.blogspot.com/2013/06/grub-how-to-2-make-boot-able-iso-with.html Well, the excursion on CD-DA is off topic and i would describe many aspects in different terms. Nice to see that at least one person read

On 07/03/2014 08:44 PM, Gene Cumm wrote: > On Thu, Jul 3, 2014 at 9:13 PM, Alexander Perlis wrote: > >> I suppose we could try making an ISOLINUX CD for the local boot, which then >> uses pxechn.c32 to connect to our PXE server? > > pxechn.c32 requires a functional PXELINUX. If I understand the issue correctly, is it that pxelinux.0 does not have a network stack and

> Daniel Kiper <daniel.kiper at oracle.com> writes: > > > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default > > Linux infrastructure and require some support from firmware and/or hypervisor. > > To cope with that problem kexec firmware infrastructure was introduced. > > It allows a developer to use all kexec/kdump features of given firmware

> Daniel Kiper <daniel.kiper at oracle.com> writes: > > > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default > > Linux infrastructure and require some support from firmware and/or hypervisor. > > To cope with that problem kexec firmware infrastructure was introduced. > > It allows a developer to use all kexec/kdump features of given firmware

Hi, I bought a USB hard drive, got Mandriva installed on it, and made it bootable with extlinux. Works great on machines that can boot from USB. I also created a boot cd using the instructions in the wiki. This is working too. The only problem with the boot cd is that I had to copy the kernel, initrd, etc. to the cd. This means that whenever I install a new kernel I'll have to create and

Hi all, Here I am sending as attachments patches enabling kexec/kdump support in Xen PV domU. Only x84_64 architecture is supported. There is no support for i386 but some code could be easily reused. Here is a description of patches: - kexec-tools-2.0.3_20120522.patch: patch for kexec-tools which cleanly applies to version 2.0.3, - kexec-kernel-only_20120522.patch: main kexec/kdump kernel

Hi all, Here I am sending as attachments patches enabling kexec/kdump support in Xen PV domU. Only x84_64 architecture is supported. There is no support for i386 but some code could be easily reused. Here is a description of patches: - kexec-tools-2.0.3_20120522.patch: patch for kexec-tools which cleanly applies to version 2.0.3, - kexec-kernel-only_20120522.patch: main kexec/kdump kernel

Hi all, Here I am sending as attachments patches enabling kexec/kdump support in Xen PV domU. Only x84_64 architecture is supported. There is no support for i386 but some code could be easily reused. Here is a description of patches: - kexec-tools-2.0.3_20120522.patch: patch for kexec-tools which cleanly applies to version 2.0.3, - kexec-kernel-only_20120522.patch: main kexec/kdump kernel

On 30.04.20 10:11, Dan Williams wrote: > On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 29.04.20 18:08, David Hildenbrand wrote: >>> Some paravirtualized devices that add memory via add_memory() and >>> friends (esp. virtio-mem) don't want to create entries in >>> /sys/firmware/memmap/ - primarily to

On 01.05.20 22:12, Dan Williams wrote: > On Fri, May 1, 2020 at 12:18 PM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:43, Dan Williams wrote: >>> On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 20:03, Dan Williams wrote: >>>>> On Fri, May 1, 2020 at

On 01.05.20 22:12, Dan Williams wrote: > On Fri, May 1, 2020 at 12:18 PM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:43, Dan Williams wrote: >>> On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 20:03, Dan Williams wrote: >>>>> On Fri, May 1, 2020 at

Dear, InetBoot(GRUB+BuildRoot+HTTP-FUSE) boots Xenoppix(Xen2.0.6) with Plan9/DomU and NetBSD/DomU. You can feel old Xen environment. :-) ------------------------------------------------------------------------- InetBoot (GRUB + BuildRoot + HTTP-FUSE) is released. HP: http://openlab.jp/oscircular/inetboot/ Guide-PDF: http://openlab.ring.gr.jp/oscircular/inetboot/InetBoot-httpfuse080418-E.pdf

On 29.04.20 18:08, David Hildenbrand wrote: > Some paravirtualized devices that add memory via add_memory() and > friends (esp. virtio-mem) don't want to create entries in > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only

On 29.04.20 18:08, David Hildenbrand wrote: > Some paravirtualized devices that add memory via add_memory() and > friends (esp. virtio-mem) don't want to create entries in > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only

Is it possible to kexec to the syslinux interface, thus bypassing the hw initialization? What would be the kexec command? kexec -l ??? --append=??? --initrd=??? TIA Jorge Almeida

>> Now, let's clarify what I want regarding virtio-mem: >> >> 1. kexec should not add virtio-mem memory to the initial firmware >> memmap. The driver has to be in charge as discussed. >> 2. kexec should not place kexec images onto virtio-mem memory. That >> would end badly. >> 3. kexec should still dump virtio-mem memory via kdump. > > Ok,

Hello, to compile kexec-tools statically against klibc we still need a patch for socket.h, otherwise: | kexec/ifdown.c:46:16: error: 'SIOCGIFCONF' undeclared (first use in this function) | kexec/ifdown.c:46:16: note: each undeclared identifier is reported only once for each function it appears in | kexec/ifdown.c:65:18: error: 'SIOCSIFFLAGS' undeclared (first use in this

David Hildenbrand <david at redhat.com> writes: > On 30.04.20 17:38, Eric W. Biederman wrote: >> David Hildenbrand <david at redhat.com> writes: >> >>> Some devices/drivers that add memory via add_memory() and friends (e.g., >>> dax/kmem, but also virtio-mem in the future) don't want to create entries >>> in /sys/firmware/memmap/ -