From owner-freebsd-stable@freebsd.org Sat Aug 27 19:09:38 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE169B770CD; Sat, 27 Aug 2016 19:09:38 +0000 (UTC) (envelope-from chardon.frederic@gmail.com) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B24AEC4E; Sat, 27 Aug 2016 19:09:38 +0000 (UTC) (envelope-from chardon.frederic@gmail.com) Received: by mail-oi0-x233.google.com with SMTP id l203so151349736oib.1; Sat, 27 Aug 2016 12:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=FuYUcmPBPlQb2zJzfqDrpjfyI//tNChpI63ZRV2GZic=; b=K4dyiJf+naZEc5kB/ueMoWEuojpvRM7VyEThxIpGNO35QoN31C7NTcUZMrz6+qJAWd 99UIqBO2fWe0dt2OwfT6LFvI2TqMS9cHNQ6gay7gkvh3KGF39d5MBMXs1A2VxazHR3hI 8CnLJYnGmWEQRU9eonfIldopsSm9PK/xME6Lk6wTiX4Fc44cARIOtqUCj4DRUvUAKhOr SiNpHhzUYzv39AxWX/8moBddPAc8TNL+Ke8jIJXKYHoWNPaBnhGZX0Bdra0sQjOM2OQY tZ+eO/5y09yvHh8YartHapwbn08RI1URK4QML3Tk9aC8I/6YlLkd0L8DzDDZA8m87huz 4J2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=FuYUcmPBPlQb2zJzfqDrpjfyI//tNChpI63ZRV2GZic=; b=NdaQV6+yQEttb51xNGE9mVSz6S2fpJRFoG4NRvm0rMBcgz6O/4iB5b9Jl+TXTNtXHA v8BQIZCvSwpwx29/8Cr/qVf4o/QsVIu5Ld8nlt+rrSYlaKkST1WYNzX/bKKBit9IPat1 //9VoLhUuUBMEwDIwsbPuIfTmnnt0bi14Q5V5Ufm/SgScJSLDOvdOdgXHL5Gno4UGS0Q 8aIzsmiagmO6dAeDSz9aWktjuWtoZCyPS+ZsH7Y7EQu6ncsQHHl3K9KbXjOHNlYjk975 0nFjq81lPO6HmzcsNfqEeeEjlpgFHyg0PYedjoJXVoqPbGQzr8Av83tOEvpru25gYWoY sEeQ== X-Gm-Message-State: AE9vXwMIIE10yg5gHKIF9nDYrnlEmXth74PN/sw+a+78IP74++B+uQoPUXzRcANSZlh3KFwktXRqH/dkSHyOOA== X-Received: by 10.202.80.211 with SMTP id e202mr7584618oib.9.1472324978022; Sat, 27 Aug 2016 12:09:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.51.196 with HTTP; Sat, 27 Aug 2016 12:09:37 -0700 (PDT) From: Frederic Chardon Date: Sat, 27 Aug 2016 21:09:37 +0200 Message-ID: Subject: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs) To: Konstantin Belousov , avg@freebsd.org Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 19:09:39 -0000 2016-08-25 13:29 GMT+02:00 Frederic Chardon : > > Le 23 ao=C3=BBt 2016 20:24, "Frederic Chardon" a > =C3=A9crit : >> >> 2016-08-23 19:35 GMT+02:00 Frederic Chardon = : >> > 2016-08-23 9:35 GMT+02:00 Konstantin Belousov : >> >> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote: >> >>> Le 20 ao??t 2016 22:03, "Frederic Chardon" >> >>> 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-ju= ne >> >>> > 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? 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.