Frederic Chardon
2016-Aug-27 19:09 UTC
Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
2016-08-25 13:29 GMT+02:00 Frederic Chardon <chardon.frederic at gmail.com>:> > Le 23 ao?t 2016 20:24, "Frederic Chardon" <chardon.frederic at gmail.com> a > ?crit : >> >> 2016-08-23 19:35 GMT+02:00 Frederic Chardon <chardon.frederic at gmail.com>: >> > 2016-08-23 9:35 GMT+02:00 Konstantin Belousov <kostikbel at gmail.com>: >> >> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote: >> >>> Le 20 ao??t 2016 22:03, "Frederic Chardon" >> >>> <chardon.frederic at gmail.com> a >> >>> ??crit : >> >>> > >> >>> > Hi >> >>> > >> >>> > I see a strange interaction between zfs on root and >> >>> > kern.proc.pathname >> >>> > on my laptop. Whenever I try to use gcore it fails with: >> >>> > gcore 1023 >> >>> > gcore: kern.proc.pathname failure >> >>> > >> >>> > However, gcore /usr/local/bin/zsh 1023 is working properly. >> >>> > >> >>> > I made some tests booting from usb stick (fresh installworld, no >> >>> > src.conf, no make.conf, GENERIC kernel) >> >>> > What works: having / on ufs and importing a zfs pool later on. >> >>> > What doesn't: having / on zfs, whatever the settings for checksum, >> >>> > compression, or normalization. >> >>> > >> >>> > Both 11-stable and 12-current behave this way. Current from may-june >> >>> > worked properly. >> >>> > adb, chromium and virtualbox as well stopped working at >> >>> > approximately >> >>> > the same time, however I don't know if it is linked ("truss -f adb >> >>> > start-server" shows that garbage is passed to execl after forking). >> >>> > >> >>> > Any idea what's going on? Does anybody else see this? >> >>> > >> >>> > Thanks! >> >>> >> >>> Nobody else have this problem? I reinstalled the system from scratch >> >>> and >> >>> still gcore fails with the same error, even in single user mode. >> >> >> >> Do you have a property on your root fs which forces it to ignore case >> >> in >> >> the file names ? >> > >> > No. I do have normalization set to formC though. I observed the same >> > behavior with the property unset (in fact, with no property set to >> > anything but default as well). >> > If I boot from usb stick and import the pool afterwards it works >> > properly. >> > >> > zpool get all zbase >> > NAME PROPERTY VALUE >> > SOURCE >> > zbase size 9,94G - >> > zbase capacity 43% - >> > zbase altroot - >> > default >> > zbase health ONLINE - >> > zbase guid 8964242380523899513 >> > default >> > zbase version - >> > default >> > zbase bootfs zbase/bootenv/11-STABLE >> > local >> > zbase delegation on >> > default >> > zbase autoreplace off >> > default >> > zbase cachefile - >> > default >> > zbase failmode wait >> > default >> > zbase listsnapshots off >> > default >> > zbase autoexpand off >> > default >> > zbase dedupditto 0 >> > default >> > zbase dedupratio 1.00x - >> > zbase free 5,65G - >> > zbase allocated 4,29G - >> > zbase readonly off - >> > zbase comment - >> > default >> > zbase expandsize - - >> > zbase freeing 0 >> > default >> > zbase fragmentation 41% - >> > zbase leaked 0 >> > default >> > zbase feature at async_destroy enabled >> > local >> > zbase feature at empty_bpobj active >> > local >> > zbase feature at lz4_compress active >> > local >> > zbase feature at multi_vdev_crash_dump enabled >> > local >> > zbase feature at spacemap_histogram active >> > local >> > zbase feature at enabled_txg active >> > local >> > zbase feature at hole_birth active >> > local >> > zbase feature at extensible_dataset enabled >> > local >> > zbase feature at embedded_data active >> > local >> > zbase feature at bookmarks enabled >> > local >> > zbase feature at filesystem_limits enabled >> > local >> > zbase feature at large_blocks enabled >> > local >> > zbase feature at sha512 enabled >> > local >> > zbase feature at skein enabled >> > local >> > >> > >> > zfs get all zbase/bootenv/11-STABLE >> > NAME PROPERTY VALUE >> > SOURCE >> > zbase/bootenv/11-STABLE type filesystem >> > - >> > zbase/bootenv/11-STABLE creation sam. ao?t 20 13:07 2016 >> > - >> > zbase/bootenv/11-STABLE used 4,23G >> > - >> > zbase/bootenv/11-STABLE available 5,34G >> > - >> > zbase/bootenv/11-STABLE referenced 2,72G >> > - >> > zbase/bootenv/11-STABLE compressratio 1.97x >> > - >> > zbase/bootenv/11-STABLE mounted yes >> > - >> > zbase/bootenv/11-STABLE quota none >> > default >> > zbase/bootenv/11-STABLE reservation none >> > default >> > zbase/bootenv/11-STABLE recordsize 128K >> > default >> > zbase/bootenv/11-STABLE mountpoint / >> > local >> > zbase/bootenv/11-STABLE sharenfs off >> > default >> > zbase/bootenv/11-STABLE checksum sha256 >> > inherited from zbase >> > zbase/bootenv/11-STABLE compression lz4 >> > inherited from zbase >> > zbase/bootenv/11-STABLE atime off >> > inherited from zbase >> > zbase/bootenv/11-STABLE devices on >> > default >> > zbase/bootenv/11-STABLE exec on >> > default >> > zbase/bootenv/11-STABLE setuid on >> > default >> > zbase/bootenv/11-STABLE readonly off >> > default >> > zbase/bootenv/11-STABLE jailed off >> > default >> > zbase/bootenv/11-STABLE snapdir hidden >> > default >> > zbase/bootenv/11-STABLE aclmode discard >> > default >> > zbase/bootenv/11-STABLE aclinherit restricted >> > default >> > zbase/bootenv/11-STABLE canmount on >> > local >> > zbase/bootenv/11-STABLE xattr off >> > temporary >> > zbase/bootenv/11-STABLE copies 1 >> > default >> > zbase/bootenv/11-STABLE version 5 >> > - >> > zbase/bootenv/11-STABLE utf8only on >> > - >> > zbase/bootenv/11-STABLE normalization formC >> > - >> > zbase/bootenv/11-STABLE casesensitivity sensitive >> > - >> > zbase/bootenv/11-STABLE vscan off >> > default >> > zbase/bootenv/11-STABLE nbmand off >> > default >> > zbase/bootenv/11-STABLE sharesmb off >> > default >> > zbase/bootenv/11-STABLE refquota none >> > default >> > zbase/bootenv/11-STABLE refreservation none >> > default >> > zbase/bootenv/11-STABLE primarycache all >> > default >> > zbase/bootenv/11-STABLE secondarycache all >> > default >> > zbase/bootenv/11-STABLE usedbysnapshots 1,52G >> > - >> > zbase/bootenv/11-STABLE usedbydataset 2,72G >> > - >> > zbase/bootenv/11-STABLE usedbychildren 0 >> > - >> > zbase/bootenv/11-STABLE usedbyrefreservation 0 >> > - >> > zbase/bootenv/11-STABLE logbias latency >> > default >> > zbase/bootenv/11-STABLE dedup off >> > default >> > zbase/bootenv/11-STABLE mlslabel >> > - >> > zbase/bootenv/11-STABLE sync disabled >> > inherited from zbase >> > zbase/bootenv/11-STABLE refcompressratio 1.96x >> > - >> > zbase/bootenv/11-STABLE written 37,6M >> > - >> > zbase/bootenv/11-STABLE logicalused 7,82G >> > - >> > zbase/bootenv/11-STABLE logicalreferenced 4,95G >> > - >> > zbase/bootenv/11-STABLE volmode default >> > default >> > zbase/bootenv/11-STABLE filesystem_limit none >> > default >> > zbase/bootenv/11-STABLE snapshot_limit none >> > default >> > zbase/bootenv/11-STABLE filesystem_count none >> > default >> > zbase/bootenv/11-STABLE snapshot_count none >> > default >> > zbase/bootenv/11-STABLE redundant_metadata all >> > default >> >> I meant: "if I boot from a _UFS_ usb stick" of course. The FreeBSD >> installation img for example. > > Anybody is able to reproduce this behavior or is it a local problem?Reverting 303970 solves this issue. gcore and adb works again, and I can start the vboxnet service. I recreated my boot pool with no properties defined, just to be sure.
Andriy Gapon
2016-Sep-04 08:24 UTC
Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
On 27/08/2016 22:09, Frederic Chardon wrote:>> Anybody is able to reproduce this behavior or is it a local problem? > Reverting 303970 solves this issue. gcore and adb works again, and I > can start the vboxnet service. > I recreated my boot pool with no properties defined, just to be sure.I can not reproduce this issue here. Unfortunately, I have no clue how kern.proc.pathname works, so I would appreciate any hints at what filesystem operations I should look for potential problems. -- Andriy Gapon