Re: Panic in prison_alloc() on boot
Sorry for the late reply. Panicking this system is a bit painful, but
I found some time to do it today.
Strangely, it's actually cred that is NULL, not cred->cr_prison:
(kgdb) p cred
$7 = (struct ucred *) 0x0
(kgdb) disassemble
Dump of assembler code for function prison_allow:
0x80ac33e0 <+0>: push %rbp
0x80ac33e1 <+1>: mov%rsp,%rbp
=> 0x80ac33e4 <+4>: mov0x30(%rdi),%rax
0x80ac33e8 <+8>: and0xf8(%rax),%esi
0x80ac33ee <+14>:mov%esi,%eax
0x80ac33f0 <+16>:pop%rbp
0x80ac33f1 <+17>:retq
End of assembler dump.
(kgdb) info reg $rdi
rdi0x0 0
However, if I go up a frame, things look fine?
(kgdb) up
#13 0x82c22531 in nullfs_mount (mp=0xf801a483d000)
at /usr/src/sys/fs/nullfs/null_vfsops.c:88
88 if (!prison_allow(td->td_ucred, PR_ALLOW_MOUNT_NULLFS))
(kgdb) p td->td_ucred
$8 = (struct ucred *) 0xf801854c1700
This appears to be a miscompilation, but I've blown away
/usr/obj/usr/src multiple times and rebuilt and got this same error
every time. But looking at the disassembly, something is definitely
wrong:
0x82c22517 <+23>:mov%gs:0x0,%r14
0x82c22520 <+32>:mov0x150(%r14),%rdi
0x82c22527 <+39>:mov$0x100,%esi
0x82c2252c <+44>:callq 0x80ac33e0
=> 0x82c22531 <+49>:test %eax,%eax
(kgdb) p &((struct thread*)0)->td_ucred
$10 = (struct ucred **) 0x158
It uses offset 0x150 to get the cred, but the debug info claims that
td_ucred is at offset 0x158. If I print out the pointer at that
offset, it looks reasonable:
(kgdb) p *td->td_ucred
$11 = {cr_ref = 107, cr_uid = 0, cr_ruid = 0, cr_svuid = 0, cr_ngroups = 1,
cr_rgid = 0, cr_svgid = 0, cr_uidinfo = 0xf80106617000,
cr_ruidinfo = 0xf80106617000, cr_prison = 0x8187cb70 ,
cr_loginclass = 0xf8019fa43b00, cr_flags = 0, cr_pspare2 = {0x0, 0x0},
cr_label = 0x0, cr_audit = {ai_auid = 4294967295, ai_mask = {am_success = 0,
am_failure = 0}, ai_termid = {at_port = 0, at_type = 4, at_addr = {0, 0,
0, 0}}, ai_asid = 0, ai_flags = 0}, cr_groups = 0xf801854c179c,
cr_agroups = 16, cr_smallgroups = {0 }}
I'm really at a loss at to what to try next. Build with
MAKEOBJDIRPREFIX set to something else to get rid of any lingering
possibility of an issue in my objdir, I guess?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make installworld broke / how to recover
On Thu, 22 Feb 2018, at 14:41, tech-lists wrote: > On Thu, Feb 22, 2018 at 03:10:17AM -0800, Jack L. wrote: > >maybe try a clean buildworld, update /usr/src to the latest version, rm -rf > >/usr/obj, then make buildworld && make installworld && make kernel and see > >if that fixes the issue? > > Is there a documented way of say booting to memstick, starting fixit, > mounting the zfs from the broken system then building/installing a > new world? Is there enough "environment" and utilities to do this on the > fixit disk? I can't help from the source/installworld side, but I have a couple of things to share that may help, apologies if this is already familiar to you. The email's long enough to be a blog entry... 1. fixing a dead/borked system I love using mfsbsd[1] by Martin Matuska for this. It's a bootable FreeBSD image with DHCP support so you can ssh into it from a separate system. You can then import the zpool and basically do all the cleanup from there. zpool import -R /mnt -N -f zroot then mount the datasets you need manually. 2. hacking a semblance of sanity back into the borked current Try this, after doing a zfs snapshot of your filesystem. - download the latest CURRENT snapshot and untar kernel + base in place over top of the above mounted rootfs. Copy back anything "important" from your snapshot like /etc/ and /boot/loader.conf and the system will probably boot now. 3. use boot environments I use these all the time, so awesome. basically when you install 11.x the zfs dataset layout already supports this by default. You can tweak an existing system to fit this if needed, it's not too hard. Details elided, help available if you need it later on. install sysutils/beadm-devel and have a go. Briefly, your / is kept in zroot/ROOT/ (called a Boot Environment) and variable data lives outside that namespace, but overlaid using zfs mountpoints. You can make multiple copies of these as you go along, before upgrades, during patches, or major config changes. Real Data like /usr/home, /var/log or (in my case) /var/db/* are in separate datasets and will always be present and up to date, irrespective of which boot environment you are currently running under. For example, I have a 11.1R boot environment, and about 3-4 12.0-CURRENT ones over the last few weeks, in case something unexpected breaks for me. At boot time, the loader (thanks Allan Jude IIRC for implementing this) allows you to choose between those copies so you can simply switch back to the working one and decide what you want to do with the borked one. see [2] for some really cool tricks from Michael Dexter about mounting that into bhyve and then "live testing" before upgrading. 4. beinstall.sh script from Will Andrews If you're building from source, then you can combine #3 with [3] and have your next incarnation automatically installed not into your existing working / dataset but into its own dataset, cloned off your current /, and upgraded, all within the boot environment. This is so awesome it's changed my world (pun intended), I install a new CURRENT every 3-4 days now because rolling back is absolutely painless. I borrowed xmj@ [4] tips on using ccache and metamode, which makes incremental builds pretty quick. I can later on mount the /usr/src and /usr/obj over NFS to other lesser powered systems like my laptop, and beinstall.sh there too. LIKE A BOSS. Here's my current hacky scripts to build world & current, and stash everything into a boot environment. It works for me, but I'm hardly a build-from-source guru so maybe that could be improved [5] [1]: http://mfsbsd.vx.sk/ [2]: http://www.callfortesting.org/bhyve-boot-environments/ [3]: https://svnweb.freebsd.org/base/head/tools/build/beinstall.sh?view=markup [4]: https://xmj.github.io/articles/sysadmin/builds_ccache_memcached.html [5]: https://gist.github.com/dch/99a0e3c42e971a08dd922aab20670d7d ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
