[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: How this wired boot timing bug comes, init rc scripts or zfs?
From:       Meowthink <meowthink () gmail ! com>
Date:       2020-10-12 12:50:25
Message-ID: CABnABoaSuBVcNvVnTq51_Eo-NMKuyXE4Je=6aW1Cet=0FViN=g () mail ! gmail ! com
[Download RAW message or body]

On Sun, Oct 11, 2020 at 11:33 AM tech-lists <tech-lists@zyxst.net> wrote:
>
> On Sun, Oct 04, 2020 at 10:50:20AM +0800, Meowthink wrote:
> >Hello hackers,
> >Recently I installworld and rebooted a server, seems working, but my
> >kerberized nfsd, precisely gssd, is not functional.
> >At first I thought it may be a bug from stable, so I did some trivial
> >tests, replacing the kernel with releng one, then the whole world, but
> >found this is nothing related to the kernel, and triggers randomly
> >when rebooting some recent stable/11 world (releng/11.4 seems fine).
> >To dig it deeper, here is what the console showed when failing:
>
> Hi,
>
> I had a possibly similar problem (boot wanting to mount ZFS before usb
> had finished recognising the hardware), and asked around.
> The advice I got led to me putting this in /boot/loader.conf:
>
> vfs.root_mount_always_wait=1 # give usb time to settle before zfs
> kern.cam.boot_delay="30000"  # 30s delay for usb3 spinning rust

I do think vfs.root_mount_always_wait will behave the same as ZFS and
NFS root. And this is where the problem lies: why do my rc scripts run
precisely between mounting / and /usr?

>
> ok a long boot time, but now everything's there as expected. My context
> is a rasberry pi4b+(8GB) booting from microsd (ufs) with a 1Tb external
> hard drive attached (which is zfs mounted) running -current r366312 with
> a no-debug kernel.
>
> --
> J.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]