Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

[Andriy Gapon]

I've written a patch that implements zfs_vptocnp() using z_parent property.
The new code should be 100% reliable for directories and "mostly" reliable for
files (that is, when hardlinks across directories are not used).

Could you please review / test it?
https://reviews.freebsd.org/D8146

Thanks!
-- 
Andriy Gapon
___
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: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

[Andriy Gapon]

On 04/09/2016 17:51, Konstantin Belousov wrote:
> It is only masked when name cache has an entry for the vnode.  So sometimes
> vn_fullpath() should be broken even if no normalization is applied.

Yes, this is true.

> OTOH, classic filesystems like UFS do not have any other means to translate
> non-directory inode to name and parent at all, except the namecache hint.

In fact, this is true for ZFS as well.  While ZFS znodes have an attribute that
specifies a (single) parent, it's obviously unreliable for files, because a file
can be linked into multiple directories and then unlinked from a directory
specified by the attribute.

So, at the moment I do not have any good ideas on how to make this work.
Maybe trying to use the parent attribute and failing when it's inconsistent
would be good enough...


-- 
Andriy Gapon
___
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: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

[Konstantin Belousov]

On Sun, Sep 04, 2016 at 04:11:39PM +0300, Andriy Gapon wrote:
> On 04/09/2016 11:24, Andriy Gapon wrote:
> > 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.
> 
> I was not trying hard enough.  I've just reproduced the problem using a
> non-default normalization property.  The issue is that 303970 disabled the use
> of VFS name cache when any name "mangling" (normalization, case-insensitivity)
> is enabled.  And apparently I misunderstood how vop_stdvptocnp() works.  So,
> right now zfs_vptocnp() is broken when its argument is a non-directory vnode.
> That fact is masked when the name cache is used and is exposed otherwise.
It is only masked when name cache has an entry for the vnode.  So sometimes
vn_fullpath() should be broken even if no normalization is applied.

OTOH, classic filesystems like UFS do not have any other means to translate
non-directory inode to name and parent at all, except the namecache hint.
___
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: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

[Andriy Gapon]

On 04/09/2016 11:24, Andriy Gapon wrote:
> 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.

I was not trying hard enough.  I've just reproduced the problem using a
non-default normalization property.  The issue is that 303970 disabled the use
of VFS name cache when any name "mangling" (normalization, case-insensitivity)
is enabled.  And apparently I misunderstood how vop_stdvptocnp() works.  So,
right now zfs_vptocnp() is broken when its argument is a non-directory vnode.
That fact is masked when the name cache is used and is exposed otherwise.

I will think about a fix.  Could you please file a bug report for this (if not
already)?
Sorry about the breakage.

-- 
Andriy Gapon
___
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: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

[Andriy Gapon]

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
___
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"

Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

[Frederic Chardon]

2016-08-25 13:29 GMT+02:00 Frederic Chardon :
>
> Le 23 août 2016 20:24, "Frederic Chardon"  a
> écrit :
>>
>> 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-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  autoreplaceoff
>> > 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  freeing0
>> > default
>> > zbase  fragmentation  41%-
>> > zbase  leaked 0
>> > default
>> > zbase  feature@async_destroy  enabled
>> > local
>> > zbase  feature@empty_bpobjactive
>> > local
>> > zbase  feature@lz4_compress   active
>> > local
>> > zbase  feature@multi_vdev_crash_dump  enabled
>> > local
>> > zbase  feature@spacemap_histogram active
>> > local
>> > zbase  feature@enabled_txgactive
>> > 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ût 20 13:07 2016
>> > -
>> > zbase/bootenv/11-STABLE  used  4,23G
>> > -
>> > 

Re: kern.proc.pathname failure while booting from zfs

[Frederic Chardon]

Le 23 août 2016 20:24, "Frederic Chardon"  a
écrit :
>
> 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-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  autoreplaceoff
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  freeing0
default
> > zbase  fragmentation  41%-
> > zbase  leaked 0
default
> > zbase  feature@async_destroy  enabled
local
> > zbase  feature@empty_bpobjactive
 local
> > zbase  feature@lz4_compress   active
 local
> > zbase  feature@multi_vdev_crash_dump  enabled
local
> > zbase  feature@spacemap_histogram active
 local
> > zbase  feature@enabled_txgactive
 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ût 20 13:07 2016
-
> > zbase/bootenv/11-STABLE  used  4,23G
 -
> > zbase/bootenv/11-STABLE  available 5,34G
 -
> > zbase/bootenv/11-STABLE  referenced2,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
> > 

Re: kern.proc.pathname failure while booting from zfs

[Frederic Chardon]

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-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   8964242380523899513default
> zbase  version-  default
> zbase  bootfs zbase/bootenv/11-STABLElocal
> zbase  delegation on default
> zbase  autoreplaceoffdefault
> zbase  cachefile  -  default
> zbase  failmode   wait   default
> zbase  listsnapshots  offdefault
> zbase  autoexpand offdefault
> 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  freeing0  default
> zbase  fragmentation  41%-
> zbase  leaked 0  default
> zbase  feature@async_destroy  enabledlocal
> zbase  feature@empty_bpobjactive local
> zbase  feature@lz4_compress   active local
> zbase  feature@multi_vdev_crash_dump  enabledlocal
> zbase  feature@spacemap_histogram active local
> zbase  feature@enabled_txgactive local
> zbase  feature@hole_birth active local
> zbase  feature@extensible_dataset enabledlocal
> zbase  feature@embedded_data  active local
> zbase  feature@bookmarks  enabledlocal
> zbase  feature@filesystem_limits  enabledlocal
> zbase  feature@large_blocks   enabledlocal
> zbase  feature@sha512 enabledlocal
> zbase  feature@skein  enabledlocal
>
>
> zfs get all zbase/bootenv/11-STABLE
> NAME PROPERTY  VALUE 
> SOURCE
> zbase/bootenv/11-STABLE  type  filesystem-
> zbase/bootenv/11-STABLE  creation

Re: kern.proc.pathname failure while booting from zfs

[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-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   8964242380523899513default
zbase  version-  default
zbase  bootfs zbase/bootenv/11-STABLElocal
zbase  delegation on default
zbase  autoreplaceoffdefault
zbase  cachefile  -  default
zbase  failmode   wait   default
zbase  listsnapshots  offdefault
zbase  autoexpand offdefault
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  freeing0  default
zbase  fragmentation  41%-
zbase  leaked 0  default
zbase  feature@async_destroy  enabledlocal
zbase  feature@empty_bpobjactive local
zbase  feature@lz4_compress   active local
zbase  feature@multi_vdev_crash_dump  enabledlocal
zbase  feature@spacemap_histogram active local
zbase  feature@enabled_txgactive local
zbase  feature@hole_birth active local
zbase  feature@extensible_dataset enabledlocal
zbase  feature@embedded_data  active local
zbase  feature@bookmarks  enabledlocal
zbase  feature@filesystem_limits  enabledlocal
zbase  feature@large_blocks   enabledlocal
zbase  feature@sha512 enabledlocal
zbase  feature@skein  enabledlocal


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  

Re: kern.proc.pathname failure while booting from zfs

[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-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 ?
___
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: kern.proc.pathname failure while booting from zfs

[Frederic Chardon]

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-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.
___
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"

kern.proc.pathname failure while booting from zfs

[Frederic Chardon]

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!
___
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"