you can modify the /etc/xen/vm/<vmname> definition file and insert kernel parameters into the "extra" line. Using this method you can simply append a "1" to the "extra" line, take the xen vm out from cluster control (crm resource stop) and manually boot it doing a xm create -c <vmname> from one of the dom0's. You may also want to ensure that in the "extra" line you also add "xencons=tty" as without this directive it can prevent console messages from displaying after the console driver loads during the vm boot process.
hth, Gary W. Stansbury II Lead LAN Engineer gary_stansb...@nexweb.org 757-631-3356 From: Miles Fidelman <mfidel...@meetinghouse.net> To: General Linux-HA mailing list <linux-ha@lists.linux-ha.org> Date: 10/28/2010 10:48 AM Subject: Re: [Linux-HA] HELP - debugging a hanging domU boot? Sent by: linux-ha-boun...@lists.linux-ha.org spoke too soon - it is a file system error, but not with boot, root, or swap - seems like the Debian boot scripts don't report stuff going on in the middle of /etc/rcS.d/S35mountall.sh - they log errors, but don't report to the console (at least with stock configuration) -- though, it could be that it was trying to do a repair, and I didn't have the patience to wait it out Had to mount the root directory and pour through logs for the DomU to find this running an fsck on it now still begs the question of how to do single-user, or other diagnostic boot of a domU Miles Fidelman wrote: > Looks like this is NOT a filesystem issue: > > - mounted /dev/drbd1 and it behaves properly > - did an fsck on /dev/drbd1 and it came back as clean > > Digging a little deeper, looking at the console messages for a > similarly configured domU, what I see is: > > ..... > [ 31.088678] EXT3 FS on xvda1, internal journal > [ 42.316654] NET: Registered protocol family 10 > ..... > > I seem to be hanging right after mounting root, and just before > networking starts up. Which brings me to two questions: > 1. any thoughts on debugging network startup in a domU > 2. my original question: how do I insert myself into the boot process > - e.g., to bring the domU up in single-user mode, etc.? > > Petri Asikainen wrote: >> Have you tried to mount/fsck filesystem xvd from dom0? >>> Hi Folks, >>> >>> I'm running (what's supposed to be) a 2-node high-availability >>> configuration consisting of: >>> - Xen3.x >>> - Debian Stable Dom0 on each node >>> - DRBD >>> - Pacemaker >>> - several Debian Stable DomUs >>> >>> One of my DomUs seems to have crashed and is stubbornly refusing to >>> boot. On either node, it comes part way up and then hangs, with the >>> (virtual) console reporting: >>> >>> .... >>> [ 2.387986] EXT3-fs: mounted filesystem with ordered data mode. >>> Begin: Running /scripts/local-bottom ... done. >>> done. >>> Begin: Running /scripts/init-bottom ... done. >>> INIT: version 2.86 booting >>> Starting the hotplug events dispatcher: udevd[ 5.467529] udevd >>> version 125 started >>> . >>> Synthesizing the initial hotplug events...done. >>> Waiting for /dev to be fully populated...done. >>> Starting boot logger: bootlogd[ 6.190409] Adding 3145588k swap on >>> /dev/xvda2. Priority:-1 extents:1 across:3145588k >>> [ 89.796051] EXT3 FS on xvda1, internal journal >>> <hang> >>> >>> I've also tried stopping it on one node, booting it on the other; >>> reboot >>> the underlying nodes; etc. >>> >>> The underlying RAID10 and DRBD arrays are reporting themselves as >>> healthy, and during the boot process DRBD seems to shift from secondary >>> to primary. >>> >>> So.... I know how I might proceed if I were booting a physical machine >>> - try to come up in single user mode, failing that, boot with a live CD >>> and start examining things. But with everything wired with CRM and Xen >>> in the middle of the boot process, I'm a little lost as to how to >>> insert >>> myself into the domU boot process for diagnostic purposes. >>> >>> Any suggestions? >>> >>> Thanks very much, >>> >>> Miles Fidelman >>> >>> p.s. What makes this particularly vexing is that the DomU that refuses >>> to come up has no purpose in life other than to handle nightly backups >>> of other domUs. Sigh... >>> >>> -- >>> In theory, there is no difference between theory and practice. >>> In<fnord> practice, there is. .... Yogi Berra >>> >>> >>> _______________________________________________ >>> Linux-HA mailing list >>> Linux-HA@lists.linux-ha.org >>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>> See also: http://linux-ha.org/ReportingProblems >> _______________________________________________ >> Linux-HA mailing list >> Linux-HA@lists.linux-ha.org >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems > > -- In theory, there is no difference between theory and practice. In<fnord> practice, there is. .... Yogi Berra _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems ****************************************************************************** This email and any files transmitted with it are intended solely for the use of the individual or agency to whom they are addressed. If you have received this email in error please notify the Navy Exchange Service Command e-mail administrator. This footnote also confirms that this email message has been scanned for the presence of computer viruses. Thank You! ****************************************************************************** _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
