Jump to content
  • 0

XenServer 8.2 (UEFI): Boot process pauses


erpede

Question

Hi out there,
I currently run into a problem and could use some help in solving it:

 

I installed XenServer 8.2 onto a (nearly) brand new Dell PowerEdge R440. All components are in the HCL.
- UEFI
- RAID 5 - 3.35 TB
- PERC H730P Adapter (integrated)
- no installation errors

 

Each time the boot process pauses for about 5 1/2 minutes after the graphics screen disappears. (See log extract below.)

 

I have installed all available patches, tested things like disable fcoe, disable xs-fcoe and disable lldpad and so on.
But I can't find a cause for this interruption, and an evaluation of a safemode boot did not shed any light on this.

Installations on PRIMERGY RX2540 M5 work without problems.

 

So, have any of you heard of something like this before? Could you guys give me some helpful hints?


Thank you
 

 

Log excerpt:

...

daemon.log:         Dec 11 16:10:36  xs-servername systemd[1]: Started Open-FCoE Initialiser.
daemon.log:         Dec 11 16:10:36  xs-servername systemd[1]: Starting Availability of block devices...
daemon.log:         Dec 11 16:10:36  xs-servername systemd[1]: Started Availability of block devices.

kern.log:               Dec 11 16:10:38  xs-servername kernel: [   30.252979] tg3 0000:04:00.0 eth0: Link is up at 1000 Mbps, full duplex
kern.log:               Dec 11 16:10:38  xs-servername kernel: [   30.252989] tg3 0000:04:00.0 eth0: Flow control is on for TX and on for RX
kern.log:               Dec 11 16:10:38  xs-servername kernel: [   30.252993] tg3 0000:04:00.0 eth0: EEE is disabled

 

--> first pause ca. half a minute

 

secure:                    Dec 11 16:11:10 xs-servername stunnel: LOG5[0]: Service [xapi] accepted connection from ::ffff:aa.bb.cc.ee:55282
secure:                    Dec 11 16:11:10 xs-servername stunnel: LOG3[0]: s_connect: connect 127.0.0.1:80: Connection refused (111)

...some security messages here...
secure:                  Dec 11 16:11:26  xs-servername stunnel: LOG3[7]: No more addresses to connect
secure:                  Dec 11 16:11:26  xs-servername stunnel: LOG5[7]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
--> from here on a really long pause, the following entries are the only ones during this period (all in all for about 5 minutes)

 

    secure:             Dec 11 16:13:01  xs-servername sshd[2965]: Accepted keyboard-interactive/pam for root from aa.bb.cc.dd port 50904 ssh2
    secure:             Dec 11 16:13:01  xs-servername sshd[2965]: pam_unix(sshd:session): session opened for user root by (uid=0)
    xensource.log: Dec 11 16:13:26  xs-servername xcp-rrdd: [ info||7 ||rrdd_main] GC live_words = 353128
    xensource.log: Dec 11 16:13:26  xs-servername xcp-rrdd: [ info||7 ||rrdd_main] GC heap_words = 860672
    xensource.log: Dec 11 16:13:26  xs-servername xcp-rrdd: [ info||7 ||rrdd_main] GC free_words = 507544

 

--> next three minutes, no log entries at all and no screen messages during this period
    
    xensource.log: Dec 11 16:16:26  xs-servername xcp-rrdd: [ info||7 ||rrdd_main] GC live_words = 199374
    xensource.log: Dec 11 16:16:26  xs-servername xcp-rrdd: [ info||7 ||rrdd_main] GC heap_words = 256512
    xensource.log: Dec 11 16:16:26  xs-servername xcp-rrdd: [ info||7 ||rrdd_main] GC free_words = 57137

 

--> from here it goes on again normally (just seconds to finish the boot process):
cron:                     Dec 11 16:17:21  xs-servername crond[4169]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 3% if used.)
cron:                     Dec 11 16:17:22  xs-servername crond[4169]: (CRON) INFO (running with inotify support)
SMlog:                  Dec 11 16:17:23  xs-servername SMAPIv3: [4228] - INFO - called as: ['/usr/libexec/xapi-storage-script/datapath/qdisk/Plugin.Query', '--json']
SMlog:                  Dec 11 16:17:23  xs-servername SMAPIv3: [4229] - INFO - called as: ['/usr/libexec/xapi-storage-script/datapath/tapdisk/Plugin.Query', '--json']

...

Link to comment

2 answers to this question

Recommended Posts

  • 0

There was an issue in the configuration of the network time daemon and it would cause the boot process to block until it timed out trying to connect to the network time server when none was configured. If you had a valid one configured it connected immediately and booted straight up.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...