unable to boot 11.2-BETA1 on BeagleBone

2018-05-12 Thread Mike Karels 
I tried to boot 11.2-BETA1 on a BeagleBone Black that had been running
11.1-RELEASE.  It didn't boot, falling back to the EMMC (which isn't bootable,
a different problem).  I was also unable to boot the snapshot from 12/20.
I see that the boot partition has different contents:

11.1-RELEASE:
MLO u-boot.img  ubldr   ubldr.bin

11.2-BETA1:
MLO boot.scru-boot.img  ubldr.bin

Has anyone else been able to boot on a BeagleBone?

I'm happy to run tests.

Mike

___
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: FreeBSD 11.1-R network slowness on Samba

2018-05-12 Thread Eugene Grosbein 
30.07.2017 12:08, Nenhum_de_Nos wrote:

> I was running 10.3-p7 on Atom hardware and using old samba36-3.6.25_1. All
> was fine.
> 
> Then I updated to 11.1-R by recompiling from svn, using the same
> kernelconfig from 10.3, and now my windows client shows timeouts and
> really slow connection. File copy never past kilobytes per second :(
> 
> I am compiling a new samba packet from ports, but that slow is weird for
> me, and I could not find any other cases on web search.

You should first verify network throughput using another software/protocol
like stock ftpd. If it is slow same way, it might be NIC driver problem
or something else other than Samba. If ftpd runs just fine, then it is Samba 
problem.


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

FreeBSD 11.2-BETA1 Now Available

2018-05-12 Thread Glen Barber 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The first BETA build of the 11.2-RELEASE release cycle is now available.

Installation images are available for:

o 11.2-BETA1 amd64 GENERIC
o 11.2-BETA1 i386 GENERIC
o 11.2-BETA1 powerpc GENERIC
o 11.2-BETA1 powerpc64 GENERIC64
o 11.2-BETA1 sparc64 GENERIC
o 11.2-BETA1 armv6 BEAGLEBONE
o 11.2-BETA1 armv6 CUBIEBOARD
o 11.2-BETA1 armv6 CUBIEBOARD2
o 11.2-BETA1 armv6 CUBOX-HUMMINGBOARD
o 11.2-BETA1 armv6 RPI-B
o 11.2-BETA1 armv6 RPI2
o 11.2-BETA1 armv6 PANDABOARD
o 11.2-BETA1 armv6 WANDBOARD
o 11.2-BETA1 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.2/

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 "stable/11" branch.

A list of changes since 11.1-RELEASE is available in the stable/11
release notes:

https://www.freebsd.org/relnotes/11-STABLE/relnotes/article.html

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

=== 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.2-BETA1/

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-815173ee
 eu-west-3 region: ami-9d8332e0
 eu-west-2 region: ami-14a34e73
 eu-west-1 region: ami-7c261005
 ap-northeast-2 region: ami-22f55d4c
 ap-northeast-1 region: ami-31d9334e
 sa-east-1 region: ami-f81e4294
 ca-central-1 region: ami-efa3238b
 ap-southeast-1 region: ami-d25760ae
 ap-southeast-2 region: ami-fcd4029e
 eu-central-1 region: ami-657e528e
 us-east-1 region: ami-555fd62a
 us-east-2 region: ami-6cf2cf09
 us-west-1 region: ami-e4f9e784
 us-west-2 region: ami-2cf38354

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can
be installed by running:

% vagrant init freebsd/FreeBSD-11.2-BETA1
% vagrant up

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64 and i386
systems running earlier FreeBSD releases.  Systems running earlier
FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 11.2-BETA1

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install

It is recommended to rebuild and install all applications if possible,
especially if upgrading from an earlier FreeBSD release, for example,
FreeBSD 10.x.  Alternatively, the user can install misc/compat10x and
other compatibility libraries, afterwards the system must be rebooted
into the new userland:

# shutdown -r now

Finally, after rebooting, freebsd-update needs to be run again to remove
stale files:

# freebsd-update install

== ISO CHECKSUMS ==

o 11.2-BETA1 amd64 GENERIC:
  SHA512 (FreeBSD-11.2-BETA1-amd64-bootonly.iso) =

[Bug 228174] [dump] dump(8) can read garbage and loop forever

2018-05-12 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228174

--- Comment #2 from Eugene Grosbein  ---
(In reply to Kirk McKusick from comment #1)

Yes, this is mounted and live file system and files are created here.

Does UFS2+SU snapshot guarantee that dump won't get uninitialized indirection
blocks from the file system if snapshot creation occurs at same moment?

I still believe dump should not loop forever and should perform some sanity
checks on indirection blocks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"