FreeBSD 11.1-RC3 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The third RC build of the 11.1-RELEASE release cycle is now available.
This is expected to be the final RC build of the 11.1-RELEASE cycle.

Installation images are available for:

o 11.1-RC3 amd64 GENERIC
o 11.1-RC3 i386 GENERIC
o 11.1-RC3 powerpc GENERIC
o 11.1-RC3 powerpc64 GENERIC64
o 11.1-RC3 sparc64 GENERIC
o 11.1-RC3 armv6 BANANAPI
o 11.1-RC3 armv6 BEAGLEBONE
o 11.1-RC3 armv6 CUBIEBOARD
o 11.1-RC3 armv6 CUBIEBOARD2
o 11.1-RC3 armv6 CUBOX-HUMMINGBOARD
o 11.1-RC3 armv6 GUMSTIX
o 11.1-RC3 armv6 RPI-B
o 11.1-RC3 armv6 RPI2
o 11.1-RC3 armv6 PANDABOARD
o 11.1-RC3 armv6 WANDBOARD
o 11.1-RC3 aarch64 GENERIC

Note regarding arm/armv6 images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.1/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use SVN to do a source based update of an existing
system, use the "releng/11.1" branch.

A summary of changes since 11.1-RC2 includes:

o A rare truncation case has been fixed in the runtime linker.

o Signatures of several pthread(3) stubs have been corrected.

o Deprecation notices have been added to gdb(1), kgdb(1), sicontrol(8),
  wlconfig(8), as well as several drivers that have been removed from
  12.0.

o Loop termination in vm_map_find_min() has been fixed.

o The layout of the vm_map_entry struct has been restored.  See the
  "SPECIAL NOTE" below for one known corner case regarding this.

o The Heimdal KDC-REP service encrypted ticket usage has been fixed.
  [FreeBSD-SA-17:05.heimdal]

o An issue where some Intel SDHCI/eMMC controllers can fail on the first
  attempt after a D3 to D0 transition has been fixed.

o Capsicum support has been added to bhyve(4).

A list of changes since 11.0-RELEASE are available in the releng/11.1
release notes:

https://www.freebsd.org/releases/11.1R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 11.1-RELEASE cycle progresses.

SPECIAL NOTE: Affects those upgrading from 11.1-RC2 within VirtualBox:
If system panics were experienced when upgrading from 11.1-RC1 to
11.1-RC2, and the emulators/virtualbox-ose-additions{,-nox11} port was
built locally as a resolution, the port will either need to be rebuilt
when upgrading to 11.1-RC3, or reinstall the package from the pkg(8)
mirrors using either:

# pkg install -f virtualbox-ose-additions

or 

# pkg install -f virtualbox-ose-additions-nox11

To ensure the system does not panic after rebooting into the updated
kernel, it is recommended to disable the vboxguest service in rc.conf(5)
prior to rebooting the system if possible, or use pkg(8) to forcefully
reinstall the package.

Systems being upgraded from 11.1-RC1 and earlier to 11.1-RC3 should be
unaffected.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64 and i386 architectures.
Disk images may be downloaded from the following URL (or any of the
FreeBSD FTP mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/11.1-RC3/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

 ap-south-1 region: ami-c89ce5a7
 eu-west-2 region: ami-b88a9cdc
 eu-west-1 region: ami-5cf31e25
 ap-northeast-2 region: ami-de0ad4b0
 ap-northeast-1 region: ami-07cfd560
 sa-east-1 region: ami-8f1f6be3
 ca-central-1 region: ami-0953ec6d
 ap-southeast-1 region: ami-5900973a
 ap-southeast-2 

Re: mdconfig and UDF

[John Kennedy]

On Fri, Jul 14, 2017 at 02:31:15PM +0500, Eugene M. Zheganin wrote:
> Is there any chance to mount UDF filesystem under FreeBSD with mdconfig 
> and ISO image ? Mount -t cd9660 /dev/md0 /mnt/cdrom gives me the 
> readme.txt with "This is UDF, you idiot" and mount -t udf /dev/md0 
> /mnt/cdrom gives me
> 
> # mount -t udf /dev/md0 cdrom
> mount_udf: /dev/md0: Invalid argument

If I make an ISO like this (currently under 11.1-RC3):

mkisofs -R -J -joliet-long -udf -iso-level 3 -o /path/to/test.iso 
/source/files/dir

I can mount it like this via md:

mdconfig -a -t vnode -f /path/to/test.iso -u 0
mount -t udf -o ro /dev/md0 /mnt

When I burn it to a physical disk, I just mount it like this:

mount -t udf -o ro /dev/cd0 /mnt
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Extended "system" attributes within jailed environment dont work

[Rick Macklem]

Konstantin Belousov wrote:
>On Fri, Jul 14, 2017 at 07:28:58PM +1000, Dewayne Geraghty wrote:
[stuff snipped]
>>
>> I suppose that the crux to the question is - why should the "system"
>> namespace not be available within a jail?
>Perhaps because system namespace (can) carry attributes which modify the
>filesystem behaviour in a way which is considered inappropriate to allow
>for jailed root. This is somewhat similar to jail security.allow_chflags
>knob, but with more unfortunate consequences.
>
>I do not claim that system namespace cannot be opened to the jailed root,
>but doing so requires a review of all implemented system ext attributes,
>across all types of filesystems.
One *hackish* way to deal with this might be to have the attribute created
within the "user" namepsace with "system." prepended to it's name when within
a jail.
- That would allow SAMBA (and others) set/get attributes that they specify
  as "system namespace", but the attributes wouldn't actually be in "system 
namespace".

Although the patch never ended up in head as yet, there was a similar issue
w.r.t. extended attribute namespace for fuse filesystems, since fuse doesn't
support the notion of a namespace.

Just a suggestion. I have no strong opinion on this, rick

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mdconfig and UDF

[Konstantin Belousov]

On Fri, Jul 14, 2017 at 02:31:15PM +0500, Eugene M. Zheganin wrote:
> Hi.
> 
> 
> Is there any chance to mount UDF filesystem under FreeBSD with mdconfig 
> and ISO image ? Mount -t cd9660 /dev/md0 /mnt/cdrom gives me the 
> readme.txt with "This is UDF, you idiot" and mount -t udf /dev/md0 
> /mnt/cdrom gives me
> 
> 
> # mount -t udf /dev/md0 cdrom
> mount_udf: /dev/md0: Invalid argument
> 
> 
> So...

Most likely this has nothing to do with md(4), but due to old UDF fs driver
not supporting the supposedly newer version of UDF layout you have.  It is
a guess only, but not groundless.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mdconfig and UDF

[Kurt Jaeger]

Hi!

> Is there any chance to mount UDF filesystem under FreeBSD with mdconfig 
> and ISO image ? Mount -t cd9660 /dev/md0 /mnt/cdrom gives me the 
> readme.txt with "This is UDF, you idiot" and mount -t udf /dev/md0 
> /mnt/cdrom gives me
> 
> 
> # mount -t udf /dev/md0 cdrom
> mount_udf: /dev/md0: Invalid argument

sysutils/udfclient

provides some rough way to access the image -- would
that help ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Extended "system" attributes within jailed environment dont work

[Konstantin Belousov]

On Fri, Jul 14, 2017 at 07:28:58PM +1000, Dewayne Geraghty wrote:
> On 14/07/2017 5:56 PM, Konstantin Belousov wrote:
> > On Fri, Jul 14, 2017 at 01:53:40PM +1000, Dewayne Geraghty wrote:
> >> Can someone advise how I can enable extended attributes in a "system"
> >> namespace within a jailed (or bhyve) environment?  There was no guidance
> >> in "man jail" nor "man jail.conf".
> > Mentioning jails and bhyve in a single sentence clearly indicates serious
> > issues with understanding either feature.
> 
> Hmm.
> 
> > 
> >>
> >> Simple test
> >> >From the host or base system:
> >> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
> >> /a  first
> >> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
> >> /a  second
> >>
> >> Within a jail:
> >> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
> >> /a  first
> >> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
> >> setextattr: /a: failed: Operation not permitted
> >> getextattr: /a: failed: Operation not permitted
> >>
> >> The impact of this is that SAMBA after 4.3 uses "system" namespace
> >> extended attributes; hence can not provision an Active Directory within
> >> a jailed environment.  (For the inclined, this affects sysvol, and
> >> interestingly "rsync -x" is unable to copy extended attributes, so
> >> having consistent sysvols across a SAMBA domain may be a challenge)
> > System namespace access is not allowed for jailed processes by design.
> > See sys/kern/vfs_subr.c:extattr_check_cred() and a comment there
> > explicitely mentioning the behaviour. The behaviour predates ~ year
> > 2002, where extended attributes were introduced, and it makes sense.
> 
> Thank-you for the pointer to the source.  With the passage of 15 years
> other applications have come to use "system" namespace extended
> attributes, as though they were in the host system.  Unfortunately if
> you have one physical box available to act as both an authentication
> server (Quasi Active Directory) and a fileserver, then using a jailed
> environment is the only solution.
> 
> By design?  I suppose its akin to saying, why would you want to use
> sysvipc from within a jail, with its global namespace (since FreeBSD
> V5.0) ; or perhaps the use of raw sockets (FreeBSDv6.0); or mount within
> a jail (FreeBSD V9.0); or...?
> Probably because sophisticated use of jails is one of the many
> outstanding features that sets FreeBSD apart from restrictive and
> antiquated environments.  Not all features of a base system should be
> reflected in a jail, that would be silly; but where upstream
> applications use features, then the enhancement of a jail's
> configuration via way of, at least, an option - makes sense.  Doesn't it?
> 
> I suppose that the crux to the question is - why should the "system"
> namespace not be available within a jail?
Perhaps because system namespace (can) carry attributes which modify the
filesystem behaviour in a way which is considered inappropriate to allow
for jailed root. This is somewhat similar to jail security.allow_chflags
knob, but with more unfortunate consequences.

I do not claim that system namespace cannot be opened to the jailed root,
but doing so requires a review of all implemented system ext attributes,
across all types of filesystems.

> 
> Aside: Someone on the SAMBA mailing list also using FreeBSD has a
> similar problem, but he's using bhyve - hence the use within the same
> sentence.
This cannot be related, obviously.  Bhyve is a hypervisor which runs
a full instance of the kernel in VM, so again, claiming that the issue
is same while mixing jails and bhyve is indicative.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mdconfig and UDF

[Maciej Suszko]

On Fri, 14 Jul 2017 14:31:15 +0500
"Eugene M. Zheganin"  wrote:

> Hi.
> 
> 
> Is there any chance to mount UDF filesystem under FreeBSD with
> mdconfig and ISO image ? Mount -t cd9660 /dev/md0 /mnt/cdrom gives me
> the readme.txt with "This is UDF, you idiot" and mount -t
> udf /dev/md0 /mnt/cdrom gives me
> 
> 
> # mount -t udf /dev/md0 cdrom
> mount_udf: /dev/md0: Invalid argument
> 
> 
> So...

Hi,

Mount - probably not, but you can use archivers/p7zip to decompress the
image.
-- 
regards, Maciej Suszko.


pgpxxtCdn6Ftq.pgp
Description: OpenPGP digital signature

mdconfig and UDF

[Eugene M. Zheganin]

Hi.


Is there any chance to mount UDF filesystem under FreeBSD with mdconfig 
and ISO image ? Mount -t cd9660 /dev/md0 /mnt/cdrom gives me the 
readme.txt with "This is UDF, you idiot" and mount -t udf /dev/md0 
/mnt/cdrom gives me



# mount -t udf /dev/md0 cdrom
mount_udf: /dev/md0: Invalid argument


So...


Thanks.

Eugene.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Extended "system" attributes within jailed environment dont work

[Dewayne Geraghty]

On 14/07/2017 5:56 PM, Konstantin Belousov wrote:
> On Fri, Jul 14, 2017 at 01:53:40PM +1000, Dewayne Geraghty wrote:
>> Can someone advise how I can enable extended attributes in a "system"
>> namespace within a jailed (or bhyve) environment?  There was no guidance
>> in "man jail" nor "man jail.conf".
> Mentioning jails and bhyve in a single sentence clearly indicates serious
> issues with understanding either feature.

Hmm.

> 
>>
>> Simple test
>> >From the host or base system:
>> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
>> /a  first
>> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
>> /a  second
>>
>> Within a jail:
>> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
>> /a  first
>> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
>> setextattr: /a: failed: Operation not permitted
>> getextattr: /a: failed: Operation not permitted
>>
>> The impact of this is that SAMBA after 4.3 uses "system" namespace
>> extended attributes; hence can not provision an Active Directory within
>> a jailed environment.  (For the inclined, this affects sysvol, and
>> interestingly "rsync -x" is unable to copy extended attributes, so
>> having consistent sysvols across a SAMBA domain may be a challenge)
> System namespace access is not allowed for jailed processes by design.
> See sys/kern/vfs_subr.c:extattr_check_cred() and a comment there
> explicitely mentioning the behaviour. The behaviour predates ~ year
> 2002, where extended attributes were introduced, and it makes sense.

Thank-you for the pointer to the source.  With the passage of 15 years
other applications have come to use "system" namespace extended
attributes, as though they were in the host system.  Unfortunately if
you have one physical box available to act as both an authentication
server (Quasi Active Directory) and a fileserver, then using a jailed
environment is the only solution.

By design?  I suppose its akin to saying, why would you want to use
sysvipc from within a jail, with its global namespace (since FreeBSD
V5.0) ; or perhaps the use of raw sockets (FreeBSDv6.0); or mount within
a jail (FreeBSD V9.0); or...?
Probably because sophisticated use of jails is one of the many
outstanding features that sets FreeBSD apart from restrictive and
antiquated environments.  Not all features of a base system should be
reflected in a jail, that would be silly; but where upstream
applications use features, then the enhancement of a jail's
configuration via way of, at least, an option - makes sense.  Doesn't it?

I suppose that the crux to the question is - why should the "system"
namespace not be available within a jail?

Aside: Someone on the SAMBA mailing list also using FreeBSD has a
similar problem, but he's using bhyve - hence the use within the same
sentence.

Regards, Dewayne.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Extended "system" attributes within jailed environment dont work

[Konstantin Belousov]

On Fri, Jul 14, 2017 at 01:53:40PM +1000, Dewayne Geraghty wrote:
> Can someone advise how I can enable extended attributes in a "system"
> namespace within a jailed (or bhyve) environment?  There was no guidance
> in "man jail" nor "man jail.conf".
Mentioning jails and bhyve in a single sentence clearly indicates serious
issues with understanding either feature.

> 
> Simple test
> >From the host or base system:
> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
> /a  first
> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
> /a  second
> 
> Within a jail:
> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
> /a  first
> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
> setextattr: /a: failed: Operation not permitted
> getextattr: /a: failed: Operation not permitted
> 
> The impact of this is that SAMBA after 4.3 uses "system" namespace
> extended attributes; hence can not provision an Active Directory within
> a jailed environment.  (For the inclined, this affects sysvol, and
> interestingly "rsync -x" is unable to copy extended attributes, so
> having consistent sysvols across a SAMBA domain may be a challenge)
System namespace access is not allowed for jailed processes by design.
See sys/kern/vfs_subr.c:extattr_check_cred() and a comment there
explicitely mentioning the behaviour. The behaviour predates ~ year
2002, where extended attributes were introduced, and it makes sense.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"