From owner-freebsd-current@freebsd.org Thu Aug 25 11:29:35 2016 Return-Path: Delivered-To: freebsd-current@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 5494FBC6716; Thu, 25 Aug 2016 11:29:35 +0000 (UTC) (envelope-from chardon.frederic@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 195051918; Thu, 25 Aug 2016 11:29:35 +0000 (UTC) (envelope-from chardon.frederic@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id 4so62498295oih.2; Thu, 25 Aug 2016 04:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cd6Sj5YCJT5UyCqQB1Y6pntkX5wuhEKIa24cfdMnQ40=; b=RZIAJ/XDHeWeq/y6YptDc8u9qHLa743+AVzUZWrUzQOhJOko/RIVfis3ljXg+x2LSV frhl6ETUrk3q9ul67Yb4MgS7LA3/oq9ICjiLPiPIHzYY2JfHvrDq+jatNXH6SjGAbcNZ d/3ahPa8BvdvjlmFVlBxXJ1qm0ymdFj5jkw22Aqm6TlMCSx4YnHt+LchX2A4XI61kwPO PJKHPiriolx7JMN2OqZ8DZhSzXthC99BNelpMzqMurCG5DKCBqIfZP/F8muCJUYAt/Py Gmrf0HA/4PetAFb19UHBI2QvzjwDJ4LoI75IzMbuG7pCV1LNMj5xQNCL7780w94SnDjM N3RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cd6Sj5YCJT5UyCqQB1Y6pntkX5wuhEKIa24cfdMnQ40=; b=FxY7HlRHwGpnAO17krKLWeJY4myLG/UIEyR6SNF0hbb1W0IDKCko9rR5NFsMj7sikk HvCYLk/wWkS3HXmq+S9D1aSDqfLLlE/YhS48ONjBlB+I8klG+SZPQZxyO7+51Bj2E38d ufPD4dpat8uZTMuybpF4cLsb6oGLo94DoAbvIINtZnpcOSh6R4P8tyL1FNsler9i0NVH lB6Zc9r3VI5sJeH9GqwVyW9aL5vGnFe0VU0zwZp3AxYq37pe3LUClWWrk5yq/gKgltP4 0CDWgkGCgNDX7dJXBZ4RiWM2VvaZElsjb6fVqs4bfudBjNhK3L0HNnMzW6bSw5fRv3or JK3w== X-Gm-Message-State: AE9vXwMXHPGsjz05v0B5FK3tA0LuXAWty4oQzCDQ9FzBKtTUycb+QHoCRotor1aoZ3kmPwg5P8UHMs2cFPTzNQ== X-Received: by 10.157.10.46 with SMTP id 43mr5835715otg.150.1472124574205; Thu, 25 Aug 2016 04:29:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.51.196 with HTTP; Thu, 25 Aug 2016 04:29:33 -0700 (PDT) Received: by 10.202.51.196 with HTTP; Thu, 25 Aug 2016 04:29:33 -0700 (PDT) In-Reply-To: References: <20160823073552.GK83214@kib.kiev.ua> From: Frederic Chardon Date: Thu, 25 Aug 2016 13:29:33 +0200 Message-ID: Subject: Re: kern.proc.pathname failure while booting from zfs To: Konstantin Belousov Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 11:29:35 -0000 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-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?