[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-03-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #16 from Mateusz Guzik  ---
Can you please reproduce with
https://people.freebsd.org/~mjg/patches/rwlock-debug-10.diff appliled on top.
E.g. like this:

cd /usr/src
fetch https://people.freebsd.org/~mjg/patches/rwlock-debug-10.diff
patch -p1 < rwlock-debug-10.diff

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-03-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #15 from Cassiano Peixoto  ---
(In reply to Franco Fichtner from comment #14)
Hi Franco,

Here it is:
FreeBSD 10.3-STABLE #4: Mon Feb  6 09:29:52 BRST 2017
r...@bgp.server.us:/usr/obj/usr/src/sys/GENERIC

My debug bellow:

# kgdb kernel.debug /var/crash/vmcore.last 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 7; apic id = 0e
fault virtual address   = 0x30
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80b2b4fa
stack pointer   = 0x28:0xfe0237a4f450
frame pointer   = 0x28:0xfe0237a4f480
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 79530 (sh)
trap number = 12
panic: page fault
cpuid = 7
KDB: stack backtrace:
#0 0x80b16230 at kdb_backtrace+0x60
#1 0x80ad7036 at vpanic+0x126
#2 0x80ad6f03 at panic+0x43
#3 0x80f810cd at trap_fatal+0x35d
#4 0x80f813e8 at trap_pfault+0x308
#5 0x80f80a2a at trap+0x47a
#6 0x80f661dc at calltrap+0x8
#7 0x80ad4d80 at __rw_wunlock_hard+0x90
#8 0x80dffd9a at vm_map_delete+0x33a
#9 0x80e01b47 at vm_map_remove+0x47
#10 0x80a96759 at exec_new_vmspace+0x1e9
#11 0x80a73284 at exec_elf64_imgact+0xa44
#12 0x80a94ec4 at kern_execve+0x7d4
#13 0x80a9438c at sys_execve+0x4c
#14 0x80f81b00 at amd64_syscall+0x450
#15 0x80f664cb at Xfast_syscall+0xfb
Uptime: 19h0m34s
Dumping 1063 out of 8149 MB: (CTRL-C to abort)
..2%..11%..22%..31%..41%..52%..61%..71%..82%..91%

Reading symbols from /boot/kernel.off/coretemp.ko.symbols...done.
Loaded symbols for /boot/kernel.off/coretemp.ko.symbols
Reading symbols from /boot/modules/plcm.ko...done.
Loaded symbols for /boot/modules/plcm.ko
#0  doadump (textdump=) at pcpu.h:219
219 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) list *0x80b2b4fa
0x80b2b4fa is in turnstile_broadcast
(/usr/src/sys/kern/subr_turnstile.c:838).
833 
834 /*
835  * Transfer the blocked list to the pending list.
836  */
837 mtx_lock_spin(_contested_lock);
838 TAILQ_CONCAT(>ts_pending, >ts_blocked[queue],
td_lockq);
839 mtx_unlock_spin(_contested_lock);
840 
841 /*
842  * Give a turnstile to each thread.  The last thread gets
Current language:  auto; currently minimal
(kgdb) bt
#0  doadump (textdump=) at pcpu.h:219
#1  0x80ad6c53 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:486
#2  0x80ad7075 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:889
#3  0x80ad6f03 in panic (fmt=0x0) at
/usr/src/sys/kern/kern_shutdown.c:818
#4  0x80f810cd in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:858
#5  0x80f813e8 in trap_pfault (frame=0xfe0237a4f3a0,
usermode=) at /usr/src/sys/amd64/amd64/trap.c:681
#6  0x80f80a2a in trap (frame=0xfe0237a4f3a0) at
/usr/src/sys/amd64/amd64/trap.c:447
#7  0x80f661dc in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:238
#8  0x80b2b4fa in turnstile_broadcast (ts=0x0, queue=1) at
/usr/src/sys/kern/subr_turnstile.c:838
#9  0x80ad4d80 in __rw_wunlock_hard (c=0xf8013a3b5318, tid=1,
file=0xf80009947001 "8?\201", line=1) at
/usr/src/sys/kern/kern_rwlock.c:1027
#10 0x80dffd9a in vm_map_delete (map=0xf8000c22b8c0, start=, end=140737488355328) at /usr/src/sys/vm/vm_map.c:2911
#11 0x80e01b47 in vm_map_remove (map=0xf8000c22b8c0,
start=140737488355328, end=1) at /usr/src/sys/vm/vm_map.c:3028
#12 0x80a96759 in exec_new_vmspace (imgp=0xfe0237a4f868,
sv=0x819858e8) at /usr/src/sys/kern/kern_exec.c:1084
#13 0x80a73284 in exec_elf64_imgact (imgp=0xfe0237a4f868) at
/usr/src/sys/kern/imgact_elf.c:881
#14 0x80a94ec4 in kern_execve (td=0xf80009947000,
args=0xfe0237a4fa78, mac_p=) at
/usr/src/sys/kern/kern_exec.c:606
#15 0x80a9438c in sys_execve (td=0xf80009947000, uap=) at /usr/src/sys/kern/kern_exec.c:222
#16 0x80f81b00 in amd64_syscall (td=0xf80009947000, traced=0) at
subr_syscall.c:141
#17 0x80f664cb in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:398
#18

Problem with snmp_wlan

2017-03-13 Thread Peter Ankerstål 
When I try to do a snmpwalk of the BEGEMOT-WIRELESS-MIB I get the follwing on 
the client side:

BEGEMOT-WIRELESS-MIB::wlanIfaceRegDomain."wlan2" = INTEGER: etsi(3)
Error in packet.
Reason: (genError) A general failure occured
Failed object: BEGEMOT-WIRELESS-MIB::wlanIfaceRegDomain."wlan2"

and on the serverside:
Mar 13 20:47:25 gw snmpd[1765]: iface wlan0 - get param: ioctl(57) failed: 
Invalid argument

Anyone know what could be the problem?



smime.p7s
Description: S/MIME cryptographic signature

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-03-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #14 from Franco Fichtner  ---
Hi Cassiano,

What's your output of uname -v?

Can you make sure to include a backtrace here from ddb? type "bt" at the prompt
when the panic happens. It may be related but not the same code path.


Cheers,
Franco

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-03-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #13 from Cassiano Peixoto  ---
(In reply to Franco Fichtner from comment #12)
Hi Franco,

I don't know exactly which svn version i'm using, because when i run uname -a
it doesn't show me. But anyway i updated my FreeBSD 10.3 on February 6th. Is it
makes sense to you?  How can i revert this commit?

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11 due to lack of waiting for da0

2017-03-13 Thread Edward Tomasz Napierała 
On 0313T1206, Pete French wrote:
> I have a number of machines in Azure, all booting from ZFS and, until
> the weekend, running 10.3 perfectly happily.
> 
> I started upgrading these to 11. The first went fine, the second would
> not boot. Looking at the boot diagnistics it is having problems finding the
> root pool to mount. I see this is the diagnostic output:
> 
>   storvsc0:  on vmbus0
>   Solaris: NOTICE: Cannot find the pool label for 'rpool'
>   Mounting from zfs:rpool/ROOT/default failed with error 5.
>   Root mount waiting for: storvsc
>   (probe0:blkvsc0:0:storvsc1: 0:0):  on 
> vmbus0
>   storvsc scsi_status = 2
>   (da0:blkvsc0:0:0:0): UNMAPPED
>   (probe1:blkvsc1:0:1:0): storvsc scsi_status = 2
>   hvheartbeat0:  on vmbus0
>   da0 at blkvsc0 bus 0 scbus2 target 0 lun 0
> 
> As you can see, the drive da0 only appears after it has tried, and failed,
> to mount the root pool.

Are you sure the above transcript is right?  There are three reasons
I'm asking.  First, you'll see the "Root mount waiting" message,
which means the root mount code is, well, waiting for storvsc, exactly
as expected.  Second - there is no "Trying to mount root".  But most
of all - for some reason the "Mounting failed" is shown _before_ the
"Root mount waiting", and I have no idea how this could ever happen.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [misc] Acessos ao CERT.br: 2017-03-06 a 2017-03-12

2017-03-13 Thread Stéphane Dupille via freebsd-stable 

> Le 13 mars 2017 à 19:09, Luiz Eduardo Roncato Cordeiro  a 
> écrit :
> 
> Hello,

Hello,

> I've sent an email with the subject above by mistake 
> to FreeBSD Stable list, I'd like to ask the list 
> administrator to delete the whole email thread from 
> this list and archive.

Unfortunately, as your email has been forwarded to everyone’s mailbox, it is 
impossible to delete it. Hope there’s no secret inside.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [misc] Acessos ao CERT.br: 2017-03-06 a 2017-03-12

2017-03-13 Thread Luiz Eduardo Roncato Cordeiro 
Hello,

I've sent an email with the subject above by mistake 
to FreeBSD Stable list, I'd like to ask the list 
administrator to delete the whole email thread from 
this list and archive.

I'm sorry,
Cordeiro

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [misc] Acessos ao CERT.br: 2017-03-06 a 2017-03-12

2017-03-13 Thread Luiz Eduardo Roncato Cordeiro 
On 13-03-2017 14:12:00 Francisco Jose Candeias Figueiredo wrote:
> 
> ###
> ### Access Denied
> ###
> 
> #Status  DateTime  Door  Card  Name,Dep
> Card Rejected2017-03-10  16:57:46  NU--06P-02-CERT146  Welinton 
> Lima,HELP DESK
> 
> 
> ###
> ### Access Granted
> ###
> 
> [empty]
> 
> ###
> ### Access Granted (CERT'ers)
> ###
> 
> #Status  DateTime  Door  Card  Name,Dep
> Card Admitted2017-03-06  07:54:45  NU--06P-02-CERT234  Renato 
> Medeiros Junior,CERT
> Card Admitted2017-03-06  08:09:56  NU--06P-02-CERT152  Dionathan 
> Nakamura,CERT
> Card Admitted2017-03-06  08:15:53  NU--06P-02-CERT190  Marcus 
> Giraldi,CERT
> Card Admitted2017-03-06  08:17:48  NU--06P-02-CERT152  Dionathan 
> Nakamura,CERT
> Card Admitted2017-03-06  08:21:04  NU--06P-02-CERT190  Marcus 
> Giraldi,CERT
> Card Admitted2017-03-06  08:21:16  NU--06P-02-CERT152  Dionathan 
> Nakamura,CERT
> Card Admitted2017-03-06  08:50:49  NU--06P-02-CERT152  Dionathan 
> Nakamura,CERT
> Card Admitted2017-03-06  08:57:16  NU--06P-02-CERT190  Marcus 
> Giraldi,CERT
> Card Admitted2017-03-06  09:49:45  NU--06P-02-CERT182  Luiz 
> Cordeiro,CERT
> Card Admitted2017-03-06  09:52:09  NU--06P-02-CERT179  Marcelo 
> Chaves,CERT
> Card Admitted2017-03-06  09:56:06  NU--06P-02-CERT176  Joao Ceron,CERT
> Card Admitted2017-03-06  09:57:32  NU--06P-02-CERT139  Cristine 
> Hoepers,CERT
> Card Admitted2017-03-06  10:00:16  NU--06P-02-CERT234  Renato 
> Medeiros Junior,CERT
> Card Admitted2017-03-06  10:10:52  NU--06P-02-CERT179  Marcelo 
> Chaves,CERT
> Card Admitted2017-03-06  10:11:53  NU--06P-02-CERT139  Cristine 
> Hoepers,CERT
> Card Admitted2017-03-06  10:12:18  NU--06P-02-CERT152  Dionathan 
> Nakamura,CERT
> Card Admitted2017-03-06  10:13:14  NU--06P-02-CERT186  Klaus 
> Jessen,CERT
> Card Admitted2017-03-06  10:13:48  NU--06P-02-CERT178  Lucimara 
> Desidera,CERT
> Card Admitted2017-03-06  10:37:14  NU--06P-02-CERT152  Dionathan 
> Nakamura,CERT
> Card Admitted2017-03-06  10:49:53  NU--06P-02-CERT190  Marcus 
> Giraldi,CERT
> Card Admitted2017-03-06  10:50:33  NU--06P-02-CERT234  Renato 
> Medeiros Junior,CERT
> Card Admitted2017-03-06  11:03:57  NU--06P-02-CERT176  Joao Ceron,CERT
> Card Admitted2017-03-06  11:31:19  NU--06P-02-CERT167  Francisco 
> Figueiredo,CERT
> Card Admitted2017-03-06  12:01:13  NU--06P-02-CERT176  Joao Ceron,CERT
> Card Admitted2017-03-06  12:18:26  NU--06P-02-CERT182  Luiz 
> Cordeiro,CERT
> Card Admitted2017-03-06  12:29:38  NU--06P-02-CERT186  Klaus 
> Jessen,CERT
> Card Admitted2017-03-06  12:58:19  NU--06P-02-CERT178  Lucimara 
> Desidera,CERT
> Card Admitted2017-03-06  13:00:37  NU--06P-02-CERT179  Marcelo 
> Chaves,CERT
> Card Admitted2017-03-06  13:14:56  NU--06P-02-CERT190  Marcus 
> Giraldi,CERT
> Card Admitted2017-03-06  13:17:59  NU--06P-02-CERT167  Francisco 
> Figueiredo,CERT
> Card Admitted2017-03-06  13:19:16  NU--06P-02-CERT152  Dionathan 
> Nakamura,CERT
> Card Admitted2017-03-06  13:25:37  NU--06P-02-CERT176  Joao Ceron,CERT
> Card Admitted2017-03-06  13:28:05  NU--06P-02-CERT179  Marcelo 
> Chaves,CERT
> Card Admitted2017-03-06  14:05:23  NU--06P-02-CERT176  Joao Ceron,CERT
> Card Admitted2017-03-06  14:13:28  NU--06P-02-CERT234  Renato 
> Medeiros Junior,CERT
> Card Admitted2017-03-06  14:19:43  NU--06P-02-CERT234  Renato 
> Medeiros Junior,CERT
> Card Admitted2017-03-06  14:22:19  NU--06P-02-CERT176  Joao Ceron,CERT
> Card Admitted2017-03-06  14:42:44  NU--06P-02-CERT179  Marcelo 
> Chaves,CERT
> Card Admitted2017-03-06  14:43:31  NU--06P-02-CERT190  Marcus 
> Giraldi,CERT
> Card Admitted2017-03-06  14:51:23  NU--06P-02-CERT139  Cristine 
> Hoepers,CERT
> Card Admitted2017-03-06  14:58:17  NU--06P-02-CERT167  Francisco 
> Figueiredo,CERT
> Card Admitted2017-03-06  15:00:49  NU--06P-02-CERT176  Joao Ceron,CERT
> Card Admitted2017-03-06  15:03:58  NU--06P-02-CERT178  Lucimara 
> Desidera,CERT
> Card Admitted2017-03-06  15:06:59  NU--06P-02-CERT234  Renato 
> Medeiros Junior,CERT
> Card Admitted2017-03-06  15:26:05  NU--06P-02-CERT139  Cristine 
> Hoepers,CERT
> Card Admitted2017-03-06  15:28:55  NU--06P-02-CERT190  Marcus 
> Giraldi,CERT
> Card Admitted2017-03-06  15:42:14  NU--06P-02-CERT190  Marcus 
> Giraldi,CERT
> Card Admitted2017-03-06  16:01:51  NU--06P-02-CERT167  Francisco 
> Figueiredo,CERT
> Card Admitted2017-03-06  16:07:46  NU--06P-02-CERT176  Joao Ceron,CERT
> Card Admitted2017-03-06  16:13:01  NU--06P-02-CERT234  Renato 
> Medeiros Junior,CERT
> Card Admitted2017-03-06  16:13:13  NU--06P-02-CERT179  Marcelo 
> Chaves,CERT
>

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-03-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #12 from Franco Fichtner  ---
r301157 was backported to 10-STABLE, but 10.3 is unaffected.  There is no
10.3-STABLE.  Which one did you mean?

>From our experience r301157 is the bad commit as the panics have disappeared in
our latest OPNsense version which reverted the rwlock bits of this particular
patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-03-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

Cassiano Peixoto  changed:

   What|Removed |Added

 CC||freebsd-stable@FreeBSD.org,
   ||peixoto.cassi...@gmail.com

--- Comment #11 from Cassiano Peixoto  ---
Guys,

I'm having the same issue here on FreeBSD 10.3-STABLE. I'm using Atom C2758 as
well. It has began after 10.3 update. It's very serious issue because many
production servers are crashing. Can someone take a look please?

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11 due to lack of waiting for da0

2017-03-13 Thread Pete French 
> The variable still exists but is ignored when using ZFS.
>
> It's a known issue. You could try this patch:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208882#c3

Ah, OK, thanks...

> Manually specifying the root pool should workaround the issue.

Interesting, I didnt think of trying that. Mainly because it appears to
have set the variable correctly, or at least it has the output:

Trying to mount root from zfs:rpool/ROOT/default 

But I shall try that. As soon as I can get one of them up
and running again :-( I now have zero machines booting! My
diagnosis that it was due to the size of the Vm was wrong, and I rebooted
them on the smallest size thinking it would be fine. It wasn't.

*sigh*

Thankyou!
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11 due to lack of waiting for da0

2017-03-13 Thread Fabian Keil 
Pete French  wrote:

> I have a number of machines in Azure, all booting from ZFS and, until
> the weekend, running 10.3 perfectly happily.
> 
> I started upgrading these to 11. The first went fine, the second would
> not boot. Looking at the boot diagnistics it is having problems finding
> the root pool to mount. I see this is the diagnostic output:
> 
>   storvsc0:  on vmbus0
>   Solaris: NOTICE: Cannot find the pool label for 'rpool'
>   Mounting from zfs:rpool/ROOT/default failed with error 5.
>   Root mount waiting for: storvsc
>   (probe0:blkvsc0:0:storvsc1: 0: Interface>0):  on vmbus0 storvsc scsi_status = 2
>   (da0:blkvsc0:0:0:0): UNMAPPED
>   (probe1:blkvsc1:0:1:0): storvsc scsi_status = 2
>   hvheartbeat0:  on vmbus0
>   da0 at blkvsc0 bus 0 scbus2 target 0 lun 0
> 
> As you can see, the drive da0 only appears after it has tried, and
> failed, to mount the root pool.
> 
> Normally I would just stick in a big 'vfs.mountroot.timeout' but that
> variable doesnt not appear to exist under 11 - or at least it doesnt
> show up in sysctl.

The variable still exists but is ignored when using ZFS.

It's a known issue. You could try this patch:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208882#c3

Manually specifying the root pool should workaround the issue.

sysctl(8) does not show the variable as it's only a tunable.
This is unrelated to the update.

Fabian


pgpwEHDYyDr4C.pgp
Description: OpenPGP digital signature

Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11 due to lack of waiting for da0

2017-03-13 Thread Pete French 
One extra datapoint - the machines which do not fail are the small DS1_v2
instances. These seem to boot fine, but if I move to the DS2 size then the
problem shows up.

-pete.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

moutnroot failing on zpools in Azure after upgrade from 10 to 11 due to lack of waiting for da0

2017-03-13 Thread Pete French 
I have a number of machines in Azure, all booting from ZFS and, until
the weekend, running 10.3 perfectly happily.

I started upgrading these to 11. The first went fine, the second would
not boot. Looking at the boot diagnistics it is having problems finding the
root pool to mount. I see this is the diagnostic output:

storvsc0:  on vmbus0
Solaris: NOTICE: Cannot find the pool label for 'rpool'
Mounting from zfs:rpool/ROOT/default failed with error 5.
Root mount waiting for: storvsc
(probe0:blkvsc0:0:storvsc1: 0:0):  on 
vmbus0
storvsc scsi_status = 2
(da0:blkvsc0:0:0:0): UNMAPPED
(probe1:blkvsc1:0:1:0): storvsc scsi_status = 2
hvheartbeat0:  on vmbus0
da0 at blkvsc0 bus 0 scbus2 target 0 lun 0

As you can see, the drive da0 only appears after it has tried, and failed,
to mount the root pool.

Normally I would just stick in a big 'vfs.mountroot.timeout' but that
variable doesnt not appear to exist under 11 - or at least it doesnt
show up in sysctl.

I have one machine which boots fine. I can take the drive of this machine,
clone it, and attach to a new VM, and that VM fails to boot! Am now
a bit scared to reboot that virtual machine in case it doesnt come back.

Can anyone offer any suggestions ? Just being able to delay the
mount might be enough if there is a variable which can do that. I do
rather need to get these machines back online

thanks,

-pete.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"