search for: 255s

...11 pv guest on redhat5.2 virtualization platform. But the startup process hung with messages: xen-vbd: registered block device major 202 xvda:<6>netfront: Initialising virtual ethernet driver. XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...<6>Uniform Multi-Platform E-IDE driver SCSI subsystem initialized st: Version 20080504, fixed bufsize...

On Wed, 2014-03-05 at 13:18 -0500, Gene Cumm wrote: > Second, I notice the Altiris server specifies _3_ options of code 43, > including one of length 253. The pack/unpack _should_ handle this but > may split it differently. That's legal, and treated as if the values had been concatenated. See RFC2131, section 4.1, and particularly the second paragraph on page 24. Unfortunately, a

...> > concatenating their payloads and processing the result as if it were a > > single option value. In particular, the server is ending each instance > > It appears they assumed you put an option 255 at the end of each > option 43 instance and the client will then strip those 255s. Yup. > If a vendor potentially encodes more than one item of information in > this option, then the vendor SHOULD encode the option using > "Encapsulated vendor-specific options" as described below: > > SHOULD makes me think a vendor can choose how much of the...

...', ''phy:/dev/disk/by-label/PLANTILLA_SW,xvda2,w''] the VM do not boot. Below are the console messages: ... [ 0.241307] Initialising Xen virtual ethernet driver. [ 5.340090] XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...udevd[59]: timeout: killing ''/sbin/modprobe -b xen:vbd'' [69] udevd[59]: ''/sbin/modprobe -b xen:vbd'' [69] terminated by signal 9 (Killed) udevd[61]: timeout: killing ''/sbin/modprobe -b xen:vbd'' [70] [ 300.244208] XENBUS: T...

....iso from pc 1(front > node) to pc 2(cluster node) [...] > PCI: setting up Xen PCI frontend stub [...] > PCI: System does not support PCI > PCI: System does not support PCI [...] > XENBUS: Waiting for devices to initialise: > 295s...290s...285s...280s...275s...270s...265s...260s...255s... Haven''t a clue. Xenbus never initializes, the devices are not enumerated, so device driver loading, and the rest of the boot sequence never occurs. I assume this domu booted fine on the first node, so look for differences between the hardware on the two nodes, same software versions...

...red rtc_cmos as rtc0 [ 0.976298] No iBFT detected. [ 0.976641] TCP cubic registered [ 0.976647] NET: Registered protocol family 17 [ 0.976739] registered taskstats version 1 [ 6.077230] XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30...

...separately, rather than > concatenating their payloads and processing the result as if it were a > single option value. In particular, the server is ending each instance It appears they assumed you put an option 255 at the end of each option 43 instance and the client will then strip those 255s. > of option 43 with tag 255 (END). This has the effect that a correct > client ignores everything after the first END tag(*). This means the > client sees only the following vendor options: > > 1 PXE MTFTP IP address > 2 PXE MTFTP client por > 3 PXE MTFTP server po...

...ading ehci-hcd.ko module Loading ohci-hcd.ko module Loading uhci-hcd.ko module USB Universal Host Controller Interface driver v3.0 Loading jbd.ko module Loading ext3.ko module Loading xenblk.ko module XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30...

...(UDMA4, PIO 8192bytes) ada0: 24405MB (49981680 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata1 bus 0 scbus1 target 0 lun 0 ada1: <ST3250824A 3.AAE> ATA-7 device ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada1: 238475MB (488397168 512 byte sectors: 1H 255S/T 16383C) ada1: Previously was known as ad2 (ada1:ata1:0:0:0): READ_DMA. ACB: c8 00 00 00 00 40 00 00 00 00 10 00 (ada1:ata1:0:0:0): CAM status: ATA Status Error (ada1:ata1:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT ) (ada1:ata1:0:0:0): RES: 51 84 00 00 00 00 00 00 00 00 00 (ada1:...

...the pcap (like Wireshark) and create a single large colon-separated string representation of the 3 option 43 values (should be over 1200 characters long, 3 times total length minus 1). Using wireshark and right-clicking on each option 43 instance, copy, bytes, as hexstream, and leaving the option 255s in I get: 01:04:e0:01:01:03:02:02:de:06:03:02:df:06:04:01:01:05:01:01:06:01:0b:08:70:aa:aa:01:0a:d7:90:3c:00:a0:01:0a:d7:90:3c:00:81:01:0a:d7:90:3c:00:a1:01:0a:d7:90:3c:00:a2:01:0a:d7:90:3c:00:a4:01:0a:d7:90:3c:00:a5:01:0a:d7:90:3c:00:a6:01:0a:d7:90:3c:00:a7:01:0a:d7:90:3c:00:a8:01:0a:d7:90:3c:00:...

The following series of 10 patches is a merge of the xenfb and xenconsoled functionality into the qemu-dm code. The general approach taken is to have qemu-dm provide two machine types - one for xen paravirt, the other for fullyvirt. For compatability the later is the default. The goals overall are to kill LibVNCServer, remove alot of code duplication and/or parallel impls of the same concepts, and