search for: xc_dom_boot_xen_init

...ine="root=/dev/hda1 ro quiet splash", features="" xc_dom_kernel_file: filename="/var/run/xend/boot/boot_kernel.25ua2U" xc_dom_malloc_filemap : 1723 kB xc_dom_ramdisk_file: filename="/var/run/xend/boot/boot_ramdisk.2aUKzk" xc_dom_malloc_filemap : 6646 kB xc_dom_boot_xen_init: ver 3.1, caps xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p xc_dom_parse_image: called xc_dom_find_loader: trying ELF-generic loader ... failed xc_dom_find_loader: trying multiboot-binary loader ... failed xc_dom_core.c:495: panic: xc_dom_find_loader: no loader found Anyone have any suggestions...

...ot;type=vnc,vncunused=1"] bootloader="/usr/bin/pygrub" vcpus=2 on_reboot = ''restart'' on_crash = ''restart'' My env is: dom0-> xen 3.2 on 64 bits dom0 <servername> -> 64 bit server with kernel-xenU-2.6.9-67.0.7.EL the xen logs say: xc_dom_boot_xen_init: ver 3.2, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xc_dom_parse_image: called xc_dom_find_loader: trying ELF-generic loader ... failed xc_dom_find_loader: trying multiboot-binary loader ... failed xc_dom_core.c:499: panic: xc_dom_find_loader: no loader found...

...lder-ng.log file : xc_dom_allocate: cmdline="root=/dev/xvda2 ro ", features="" xc_dom_kernel_file: filename="/boot/vmlinuz-2.6.18.8" xc_dom_malloc_filemap : 1528 kB xc_dom_ramdisk_file: filename="/boot/initrd.img-2.6.18.8" xc_dom_malloc_filemap : 37 MB xc_dom_boot_xen_init: ver 4.0, caps xen-3.0-x86_64 xen-3.0-x86_32p xc_dom_parse_image: called xc_dom_find_loader: trying ELF-generic loader ... failed xc_dom_find_loader: trying Linux bzImage loader ... xc_dom_bzimageloader.c:357: panic: xc_dom_probe_bzimage_kernel: boot protocol too old (0204) failed xc_dom_find_loade...

...t;root=LABEL=atsina:ROOTFS ro console=hvc0", features="" xc_dom_kernel_file: filename="/boot/atsina/vmlinuz-2.6.26-1-amd64" xc_dom_malloc_filemap : 1703 kB xc_dom_ramdisk_file: filename="/boot/atsina/initrd.img-2.6.26-1-amd64" xc_dom_malloc_filemap : 6101 kB xc_dom_boot_xen_init: ver 3.2, caps xen-3.0-x86_64 xen-3.0-x86_32p xc_dom_parse_image: called xc_dom_find_loader: trying ELF-generic loader ... failed xc_dom_find_loader: trying Linux bzImage loader ... xc_dom_malloc : 8035 kB xc_dom_do_gunzip: unzip ok, 0x1a409f -> 0x7d8d00 OK elf_parse_binary: phdr: paddr=0x20000...

.../efw22/vmlinuz-2.6.21.7-2.neobiker.efw22xen" xc_dom_malloc_filemap : 2294 kB xc_dom_malloc : 5113 kB xc_dom_do_gunzip: unzip ok, 0x23dac4 -> 0x4fe5b0 xc_dom_ramdisk_file: filename="/boot/efw22/initrd-2.6.21.7-2.neobiker.efw22xen.img" xc_dom_malloc_filemap : 238 kB xc_dom_boot_xen_init: ver 3.3, caps xen-3.0-x86_32p xc_dom_parse_image: called xc_dom_find_loader: trying ELF-generic loader ... OK elf_parse_binary: phdr: paddr=0x1000000 memsz=0x2ff890 elf_parse_binary: phdr: paddr=0x1300000 memsz=0x139000 elf_parse_binary: memory: 0x1000000 -> 0x1439000 elf_xen_parse_note: GUEST...

...ppears the xvda1 device on DomU is not created or accessible: Parsing config file dom1 domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvda1 console=hvc0 root=/dev/xvda1 ro 3", features="(null)" domainbuilder: detail: xc_dom_kernel_mem: called domainbuilder: detail: xc_dom_boot_xen_init: ver 4.1, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find...

...tail: xc_dom_kernel_file: filename="vmlinuz-2.6.32-5-amd64" domainbuilder: detail: xc_dom_malloc_filemap : 2367 kB domainbuilder: detail: xc_dom_ramdisk_file: filename="initrd.img-2.6.32-5-amd64" domainbuilder: detail: xc_dom_malloc_filemap : 9075 kB domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_l...

I''m unable to start xl console on latest xen-unstable (build with commit 8e0da8c07f4f80e14314977a11f738bd74a5b62b). > xl -vvv console sid > xenconsole: Could not read tty from store: No such file or directory I also tried "xl create -c", and it shows console from pygrub but when the "xl create" reaches the end I got the same error: > xenconsole: Could not

...detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" domainbuilder: detail: xc_dom_malloc_filemap : 1130 kB domainbuilder: detail: xc_dom_malloc : 14779 kB domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x11a833 -> 0xe6effa domainbuilder: detail: xc_dom_boot_xen_init: ver 4.1, caps xen-3.0-x86_64 xen-3.0-x86_32p domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... xc:...

Changes from v3: - mini-os configuration files moved into stubdom/ - mini-os extra console support now a config option - Fewer #ifdefs - grant table setup uses hypercall bounce - Xenstore stub domain syslog support re-enabled Changes from v2: - configuration support added to mini-os build system - add mini-os support for conditionally compiling frontends, xenbus -

I''ve addressed all (I think/hope) of the review comments. The main change is to expose the guest virtual platform (e.g. memory layout and interrupt usage etc) to the toolstack via the public interface. This is then used during FDT generation. I have just codified the current defacto standard layout, it''s probably not the best layout but any change can be a separate patch/series.

Since the vTPM implementations are being incorproated into Xen and possibly upstream Linux, I would like to see if this protocol change could be added before we have significant legacy implementations. If not, I still think it would be useful as either a v2 or negotiated protocol change. The current vTPM protocol is a copy of the network protocol. This was likely done for ease of implementation,

Biggest change is to switch the new DTB node to /xen-core-devices instead of /xen at Stefano''s request. I also dropped the few patches title HACK etc which weren''t supposed to be there and fixed up some bits and pieces which folks commented on. George, WRT the freeze I think this is functionality which we cannot ship Xen 4.4 without. The impact is entirely constrained to the