Date: Thu, 25 Aug 2016 13:29:33 +0200 From: Frederic Chardon <chardon.frederic@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: kern.proc.pathname failure while booting from zfs Message-ID: <CAMODbk=5Ug09LewkP4JqvSQ%2BSj=E3COTRB7N8tKb10pqbP2n5g@mail.gmail.com> In-Reply-To: <CAMODbkk0yAAN8Lpi2ZOJrSKC3PKnhacHDOs2utisyQXA6XaAqA@mail.gmail.com> References: <CAMODbkmNkkOuaKydLJvDPGkKUSGvcFauzyRCAvgX-9quoDUoWw@mail.gmail.com> <CAMODbkmjNK0RNHA1A2Tq0TQ%2BPaqh1RGr-AnsV6BbP1M01e434w@mail.gmail.com> <CAMODbkm%2BZ0TA_MHjcMtzieHgE3Q9akpTuYSVzRgb-bS5vTN=ug@mail.gmail.com> <CAMODbkmV8UNXX76Zi2utgvkw_bZyyJqcBa8e382Hp9oyDpbZXw@mail.gmail.com> <20160823073552.GK83214@kib.kiev.ua> <CAMODbkk5w8QaPNbY-HEWjpZjEP8YOLA1ypz1f8VdQCEusLrgdA@mail.gmail.com> <CAMODbkn-pVd1YWrvva816ShqYKbFn5G8d8Q-u46Sj7ndiKFYrA@mail.gmail.com> <CAMODbkkdBt3LFicdPtmtL7zRDyHrrY%2BM9mO55MqD14wG_gZBVQ@mail.gmail.com> <CAMODbkk0yAAN8Lpi2ZOJrSKC3PKnhacHDOs2utisyQXA6XaAqA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Le 23 ao=C3=BBt 2016 20:24, "Frederic Chardon" <chardon.frederic@gmail.com>=
a
=C3=A9crit :
>
> 2016-08-23 19:35 GMT+02:00 Frederic Chardon <chardon.frederic@gmail.com>:
> > 2016-08-23 9:35 GMT+02:00 Konstantin Belousov <kostikbel@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@gmail.co=
m>
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-jun=
e
> >>> > 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@async_destroy enabled
local
> > zbase feature@empty_bpobj active
local
> > zbase feature@lz4_compress active
local
> > zbase feature@multi_vdev_crash_dump enabled
local
> > zbase feature@spacemap_histogram active
local
> > zbase feature@enabled_txg active
local
> > zbase feature@hole_birth active
local
> > zbase feature@extensible_dataset enabled
local
> > zbase feature@embedded_data active
local
> > zbase feature@bookmarks enabled
local
> > zbase feature@filesystem_limits enabled
local
> > zbase feature@large_blocks enabled
local
> > zbase feature@sha512 enabled
local
> > zbase feature@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=C3=BBt 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMODbk=5Ug09LewkP4JqvSQ%2BSj=E3COTRB7N8tKb10pqbP2n5g>