Parallel release failed on pwd_mkdb

2015-07-06 Thread Oliver Pinter
Hi All!

We got this build failure, when two release make release running in parallel:

10-STABLE:
-

--
 stage 4.4: building everything
--
pwd_mkdb: /var/tmp/temproot/etc/pwd.db.tmp to
/var/tmp/temproot/etc/pwd.db: No such file or directory
*** Error code 1

Stop.
make[4]: stopped in /jenkins/workspace/HardenedBSD-10-STABLE-amd64/etc
*** Error code 1

Stop.
make[3]: stopped in /jenkins/workspace/HardenedBSD-10-STABLE-amd64
*** Error code 1

Stop.
make[2]: stopped in /jenkins/workspace/HardenedBSD-10-STABLE-amd64

  *** FATAL ERROR: Cannot 'cd' to
/jenkins/workspace/HardenedBSD-10-STABLE-amd64/release/.. and install
files to
  the temproot environment

*** Error code 1

Stop.
make[1]: stopped in /jenkins/workspace/HardenedBSD-10-STABLE-amd64/release
*** Error code 1


11-CURRENT:


pwd_mkdb -i -p -d /var/tmp/temproot/etc /var/tmp/temproot/etc/master.passwd
pwd_mkdb: /var/tmp/temproot/etc/pwd.db.tmp: File exists
*** Error code 1

Stop.
make[4]: stopped in /jenkins/workspace/HardenedBSD-master-amd64/etc
*** Error code 1

Stop.
make[3]: stopped in /jenkins/workspace/HardenedBSD-master-amd64
*** Error code 1

Stop.
make[2]: stopped in /jenkins/workspace/HardenedBSD-master-amd64

  *** FATAL ERROR: Cannot 'cd' to
/jenkins/workspace/HardenedBSD-master-amd64/release/.. and install
files to
  the temproot environment

*** Error code 1

Stop.
make[1]: stopped in /jenkins/workspace/HardenedBSD-master-amd64/release
*** Error code 1

I could work it around with build order dependency or with chrooted builds...

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


Re: Parallel release failed on pwd_mkdb

2015-07-06 Thread Simon J. Gerraty
Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 We got this build failure, when two release make release running in parallel:

Can you elaborate what you mean by two release make release ?
Do you mean two separate builds running in the same tree at the same
time using the same DESTDIR?

  stage 4.4: building everything
 --
 pwd_mkdb: /var/tmp/temproot/etc/pwd.db.tmp to
 /var/tmp/temproot/etc/pwd.db: No such file or directory
 *** Error code 1

The pwd_mkdb command in etc uses $DESTDIR/etc - it obviously assumes
that is unique.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Parallel release failed on pwd_mkdb

2015-07-06 Thread Oliver Pinter
On Mon, Jul 6, 2015 at 10:26 PM, Simon J. Gerraty s...@juniper.net wrote:
 Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 We got this build failure, when two release make release running in parallel:

 Can you elaborate what you mean by two release make release ?

Two concurrent make release would be the previous statement.

 Do you mean two separate builds running in the same tree at the same
 time using the same DESTDIR?

We building from separated git repos. Every target has an it's own,
and we don't specify custom DESTDIR, just issue a simple make
real-release in the ${SRCTOP}/release directory.


  stage 4.4: building everything
 --
 pwd_mkdb: /var/tmp/temproot/etc/pwd.db.tmp to
 /var/tmp/temproot/etc/pwd.db: No such file or directory
 *** Error code 1

 The pwd_mkdb command in etc uses $DESTDIR/etc - it obviously assumes
 that is unique.


I tracked down the issue to the ${SRCTOP}/release/scripts/mm-mtree.sh
file, which called without release specific temproot argument.

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


Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)

2015-07-06 Thread Kurt Lidl

On 7/2/15 11:00 AM, Glen Barber wrote:

On Thu, Jul 02, 2015 at 10:52:00AM -0400, Kurt Lidl wrote:

Kurt, can you re-enable the ipv6 line in rc.conf(5), and add '-tso6' to
your rc.conf(5) lines?

  ifconfig_bge0=DHCP
  ifconfig_bge0_ipv6=inet6 accept_rtadv -tso6



I tried this, and it panic'd in the same manner.  (Note - I've upgraded
this machine to the second 10.2-PRELEASE build.)



Okay, thank you for testing.  The last commits that I see specifically
referencing this bge(4) model were a long time ago, but TSO was
mentioned.  It was worth a shot.


Sure, no problem.




[...]

I've also seen (now that it's been running a bit longer), a couple of
other occurrences of the spin lock held too long panic. So while
having the IPv6 configuration in /etc/rc.conf causes this crash to
occur most of the time on boot, the same crash occurs at other times
too, which don't appear to IPv6 related.



Can you update the PR with this information, please?


Already done by the time I sent the email.




1) when making the requested change, I editted my /etc/rc.conf file,
and then issued reboot.  The machine panic'd during the reboot
processing:

root@spork:~ # reboot
Jul  2 09:48:53 spork reboot: rebooted by root
Jul  2 09:48:53 spork syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 0 done
All buffers synced.
Uptime: 14h34m16s
GEOM_MIRROR: Device gswap: provider mirror/gswap destroyed.
GEOM_MIRROR: Device gswap destroyed.
pid 1 (init), uid 0: exited on signal 4
spin lock 0xc0cba338 (smp rendezvous) held by 0xf8000bbbe920 (tid
100367) too long
timeout stopping cpus
panic: spin lock held too long
cpuid = 1
KDB: stack backtrace:
#0 0xc05757c0 at panic+0x20
#1 0xc0559250 at _mtx_lock_spin_failed+0x50
#2 0xc0559318 at _mtx_lock_spin_cookie+0xb8
#3 0xc08d801c at tick_get_timecount_mp+0xdc
#4 0xc05840c8 at binuptime+0x48
#5 0xc08a400c at timercb+0x6c
#6 0xc08d8380 at tick_intr+0x220
Uptime: 14h34m16s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
timeout stopping cpus
timeout shutting down CPUs.

SC Alert: Host System has Reset

Note: the SC Alert: message comes the Sparc's ALOM management system,
so that's from the hardware directly, not from FreeBSD's kernel.



Hmm.  Any chance this could be hardware (failure) related?


Highly unlikely.

First, both Chris and I both see this same error on our V240 machines.

Also, I took the time this weekend to re-install from the
10.0-RELEASE media onto the other disks in this machine.[*]
My V240 has 4x72GB drives, so I now have 10.0-RELEASE running
on a ZFS mirror on disk0/disk1 and have the second 10.2-PRERELEASE
bits installed onto a ZFS mirror on disk2/disk3.  So I can boot
into either of those environments pretty easily.

When running 10.0-RELEASE, the hardware does not exhibit the
spin lock held too long message.

-Kurt

[*] This turned out to be unexpected hard.  I was able to boot
from the 10.0-RELEASE cdrom, and create a ZFS mirror, and install
to it, but when I rebooted, I got this error:

Trying to mount root from zfs:sys/ROOT/default []...
Mounting from zfs:sys/ROOT/default failed with error 45.

It took me a while to figure out what was going on.  In 10.0,
the sparc ZFS support probed all the disk devices, looking
for the disks in the boot zpool.  In 10.2, it only probes the
the devices configured in the eeprom's boot-device setting.
I had installed the 10.2-ish bits into the zpool called sys,
and when I reinstalled the 10.0 bits, I also put them into
a zpool named sys.  So I had two entirely different sys
zpools, the first on disk0/disk1 and the second on disk2/disk3.

The 10.2 code can handle this (since it only looked at disk2/disk3),
and happily booted from disk2/disk3.
The 10.0 code, on the other hand, examined all the disks, found
devices that didn't match up, and gave up.  I ultimately ended up
reinstalling the 10.0-RELEASE software into a zpool named sys0.

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


New FreeBSD snapshots available: stable/10 (20150704 r285132)

2015-07-06 Thread Glen Barber
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FTP mirrors.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 10.2-PRERELEASE amd64 GENERIC
o 10.2-PRERELEASE i386 GENERIC
o 10.2-PRERELEASE ia64 GENERIC
o 10.2-PRERELEASE powerpc GENERIC
o 10.2-PRERELEASE powerpc64 GENERIC64
o 10.2-PRERELEASE sparc64 GENERIC
o 10.2-PRERELEASE armv6 BEAGLEBONE
o 10.2-PRERELEASE armv6 CUBOX-HUMMINGBOARD
o 10.2-PRERELEASE armv6 GUMSTIX
o 10.2-PRERELEASE armv6 RPI-B
o 10.2-PRERELEASE armv6 PANDABOARD
o 10.2-PRERELEASE armv6 WANDBOARD

Snapshots may be downloaded from the corresponding architecture
directory from:

ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/

Please be patient if your local FTP mirror has not yet caught
up with the changes.

Problems, bug reports, or regression reports should be reported
through the Bugzilla PR system or the appropriate mailing list,
such as -current@ or -stable@ .

=== Virtual Machine Disk Images ===
 
VM disk images are available for the amd64 and i386 architectures:

o 10.2-PRERELEASE amd64
o 10.2-PRERELEASE i386

Disk images may be downloaded from the following URL (or any of the
FreeBSD FTP mirrors):

ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW disk image
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ ~17GB - freebsd-ufs GPT partition type (rootfs GPT label)

=== Amazon EC2 AMI Images ===

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

 us-east-1 region: ami-abc70ac0
 us-west-1 region: ami-5bef
 us-west-2 region: ami-932120a3
 sa-east-1 region: ami-83169b9e
 eu-west-1 region: ami-e68fcc91
 eu-central-1 region: ami-3a93a827
 ap-northeast-1 region: ami-92852992
 ap-southeast-1 region: ami-1aa8a948
 ap-southeast-2 region: ami-05682c3f

=== Azure / VM Depot Images ===

FreeBSD/amd64 images are available for use within the Microsoft Azure
hosting platform through VM Depot.  For deployment instructions, see:

https://vmdepot.msopentech.com/Vhd/Show?vhdId=56718

=== Vagrant Images ===

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

% vagrant init freebsd/FreeBSD-10.2-PRERELEASE
% vagrant up --provider vmware_desktop

Note:  At this time, support exists only for the vmware_desktop
provider.

== ISO CHECKSUMS ==

o 10.2-PRERELEASE amd64 GENERIC:
SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-bootonly.iso) = 
82c9d989806240c5e202f54b6e2475e910c55ead234771edbcb473199ca52c97
SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-bootonly.iso.xz) 
= a8608c436a9641a842b848499c030c0fe759bc43829ff8a698e99a41fd94a8da
SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-disc1.iso) = 
7094f12e800828be8400c507a9f11209232f36c56a722003e5e7f8419794f47a
SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-disc1.iso.xz) = 
0bd305cb025cc3c17f1f5976a9a3f14d7cd3a784e5a45e0e022052b3d989316a
SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-memstick.img) = 
145168b73db4b3d77d70cea6301730651fb140b89e3de64d3264069a4deaee7f
SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-memstick.img.xz) 
= 1024add6d5f2c41de34b1a5f4409b2b79ac1705ac31791082861dce941a959d1
SHA256 
(FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-mini-memstick.img) = 
420a6681f3b9a2aff00e29e6b6f6fdbf9fcbbc53d0247ef5b3d6726e3dfc8af6
SHA256 
(FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-mini-memstick.img.xz) = 
f8ddd28849808578fcbbba5dfa6f0870c120b4799b91a962ffd0bb4fb0b92832
SHA256 
(FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-uefi-bootonly.iso) = 
63d356a1ad8eaa98d18e8e0ae6c0fca57c0d1e21a9f5272a4970d4527e244143
SHA256 
(FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-uefi-bootonly.iso.xz) = 
61d78b1c6adeaf1428ca42388c32b76b1d03e4d65df9362a48b4d5a18106fed2
SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-uefi-disc1.iso) 
= a0e745c7f1acce5d0bd364c6261f76b229aa4f535072e67d01ad088690b2cd11
SHA256 
(FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-uefi-disc1.iso.xz) = 
a9b73ca3fc30780080fa7368b5194bc555297524ae2998cf73651c2115e9a03f
SHA256