Re: zfsboot patch for /usr
On 10/03/2016 01:02, Freddie Cash wrote: > Set mountpoint=none if you just want to create the parent dataset without > actually using it for storage. Then you can set properties on it, and child > datasets will inherit then. Like pool/usr/local Usually, you want the mountpoint to be one of the inherited properties -- so set canmount=off instead. This pattern is used by default already in the installer. The root filesystem is created as a BE under zroot/ROOT/default/ but there is also a zroot/var which has canmount=off to act as a parent to zroot/var/logs, zroot/var/mail etc. which are not part of the boot environment but are mounted in the expected locations under /var Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: EFI zfs loader and beadm?
On Thu, Mar 10, 2016 at 1:49 PM, krad wrote: > Make sure you are running the latest snapshot of current or 10.3 as well, as > the MFC commits were in early February for 10-stable > >> >> If remove efiwpool/ROOT/init/boot and copy his content on >> efiwpool/ROOT/init my scheme work fine too. >> /usr /var /home and other included in BE for consistent boot system >> (CURRENT world may not boot with kernel other rev), and old home >> snapshot sometimes useful for backup/restore >> ___ % uname -a FreeBSD x220.efi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296548: Wed Mar 9 01:16:17 MSK 2016 root@des.local:/usr/obj/usr/src/sys/X220 amd64 ___ 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: EFI zfs loader and beadm?
On Thu, Mar 10, 2016 at 2:55 PM, krad wrote: > presumably it boots now? > > On 10 March 2016 at 11:01, Andrey Fesenko wrote: >> >> On Thu, Mar 10, 2016 at 1:49 PM, krad wrote: >> > Make sure you are running the latest snapshot of current or 10.3 as >> > well, as >> > the MFC commits were in early February for 10-stable >> > >> >> >> >> If remove efiwpool/ROOT/init/boot and copy his content on >> >> efiwpool/ROOT/init my scheme work fine too. >> >> /usr /var /home and other included in BE for consistent boot system >> >> (CURRENT world may not boot with kernel other rev), and old home >> >> snapshot sometimes useful for backup/restore >> >> ___ >> >> % uname -a >> FreeBSD x220.efi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296548: >> Wed Mar 9 01:16:17 MSK 2016 >> root@des.local:/usr/obj/usr/src/sys/X220 amd64 > > My current working config % mount efiwpool/ROOT/init0 on / (zfs, local, noatime, nfsv4acls) devfs on /dev (devfs, local, multilabel) efiwpool/ROOT/init0/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls) efiwpool/ROOT/init0/usr on /usr (zfs, local, noatime, nfsv4acls) efiwpool/ROOT/init0/usr/home on /usr/home (zfs, local, noatime, nfsv4acls) efiwpool/ROOT/init0/var on /var (zfs, local, noatime, nfsv4acls) efiwpool/ROOT/init0/var/crash on /var/crash (zfs, local, noatime, noexec, nosuid, nfsv4acls) efiwpool/ROOT/init0/var/db on /var/db (zfs, local, noatime, noexec, nosuid, nfsv4acls) efiwpool/ROOT/init0/var/db/pkg on /var/db/pkg (zfs, local, noatime, nosuid, nfsv4acls) efiwpool/ROOT/init0/var/db/tlpkg on /var/db/tlpkg (zfs, local, noatime, nosuid, nfsv4acls) efiwpool/ROOT/init0/var/empty on /var/empty (zfs, local, noatime, noexec, nosuid, read-only, nfsv4acls) efiwpool/ROOT/init0/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls) efiwpool/ROOT/init0/var/mail on /var/mail (zfs, local, noatime, noexec, nosuid, nfsv4acls) efiwpool/ROOT/init0/var/run on /var/run (zfs, local, noatime, noexec, nosuid, nfsv4acls) efiwpool/ROOT/init0/var/tmp on /var/tmp (zfs, local, noatime, nosuid, nfsv4acls) => 40 234441568 ada1 GPT (112G) 40 1600 1 efi (800K) 1640 234439960 2 freebsd-zfs (112G) 234441600 8- free - (4.0K) % zfs get -r mountpoint efiwpool NAME PROPERTY VALUE SOURCE efiwpool mountpoint none local efiwpool/ROOT mountpoint none inherited from efiwpool efiwpool/ROOT/initmountpoint legacy local efiwpool/ROOT/init/tmpmountpoint /tmp local This work fine, booted, beadm create new env, activate them, see boot menu and select BE. % beadm list BEActive Mountpoint Space Created init - - 420.7M 2016-03-09 02:57 init0 NR / 35.9G 2016-03-10 05:00 If i'm add separate dataset for /boot (efiwpool/ROOT/init0/boot) system not booted, efi loader (first stage) see only my pool, not found /boot/loader.efi ___ 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"
FreeBSD_HEAD_amd64_gcc4.9 - Build #1121 - Still Failing
FreeBSD_HEAD_amd64_gcc4.9 - Build #1121 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1121/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1121/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1121/console Change summaries: 296610 by mav: MFV r296609: 6370 ZFS send fails to transmit some holes Reviewed by: Matthew Ahrens Reviewed by: Chris Williamson Reviewed by: Stefan Ring Reviewed by: Steven Burgess Reviewed by: Arne Jansen Approved by: Robert Mustacchi Author: Paul Dagnelie In certain circumstances, "zfs send -i" (incremental send) can produce a stream which will result in incorrect sparse file contents on the target. The problem manifests as regions of the received file that should be sparse (and read a zero-filled) actually contain data from a file that was deleted (and which happened to share this file's object ID). Note: this can happen only with filesystems (not zvols, because they do not free (and thus can not reuse) object IDs). Note: This can happen only if, since the incremental source (FromSnap), a file was deleted and then another file was created, and the new file is sparse (i.e. has areas that were never written to and should be implicitly zero-filled). We suspect that this was introduced by 4370 (applies only if hole_birth feature is enabled), and made worse by 5243 (applies if hole_birth feature is disabled, and we never send any holes). The bug is caused by the hole birth feature. When an object is deleted and replaced, all the holes in the object have birth time zero. However, zfs send cannot tell that the holes are new since the file was replaced, so it doesn't send them in an incremental. As a result, you can end up with invalid data when you receive incremental send streams. As a short-term fix, we can always send holes with birth time 0 (unless it's a zvol or a dataset where we can guarantee that no objects have been reused). Closes #37 openzfs/openzfs@adef853162e83f7cdf6b2d9af9756d434a9c743b 296607 by imp: Don't assume that bio_cmd is a bitfield. Differential Revision: https://reviews.freebsd.org/D5591 296606 by imp: Don't assume that bio_cmd is a bit mask. Differential Revision: https://reviews.freebsd.org/D5592 296605 by imp: Don't assume that bio_cmd is bit mask. Differential Revision: https://reviews.freebsd.org/D5593 296604 by imp: Move to new value for XPT_GET_SIM_KNOB to avoid clash with XPT_ATA_IO. 296603 by np: cxgbe(4): Add general purpose routines that offer safe access to the chip's memory windows. Convert existing users of these windows to the new routines. 296602 by zbb: Fix bug in VNIC causing phony number of available TX descriptors TSO packets will signal segments TX completion in the separate CQ descriptors. Each CQ descriptor for HW TSO will point to the same SQ entry. Do not invoke nicvf_put_sq_desc() for secondary segments to avoid free_cnt corruption and eventually integer overflow that will result in the negative free_cnt value and hence impossibility of further transmission. Reviewed by: wma Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5535 296601 by zbb: Fix "received NULL mbuf" bug in VNIC Do not modify NIC_QSET_CQ_0_7_HEAD manually, especially in non-atomic context. It doesn't seem to be necessary to recreate CQ head after interrupt clearing too. Reviewed by: wma Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5533 296596 by np: cxgbe(4): Allow the addr/len pair that is being validated in validate_mem_range to span multiple memory types. Update validate_mt_off_len to use validate_mem_range. 296595 by sephe: hyperv/hn: Make the # of TX rings configurable. Rename the tunables to avoid confusion. MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5578 296594 by sephe: hyperv/hn: Factor out hn_channel_attach MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5577 296593 by sephe: hyperv/hn: Move if_initname to an earlier place So that functions shared w/ attach path could use if_printf(). While I'm here, remove unnecessary if_dunit and if_dname assignment. MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5576 296592 by imp: Don't assume that bio_cmd is a bitfield. Differential revision: https://reviews.freebsd.org/D5590 296591 by imp: Don't assume bio_cmd is a bit field. Differential Revision: https://reviews.freebsd.org/D5594 296590 by imp: Add raw RX-50 support. These are 400k single sided disks with 80 tracks and 10 sectors per track. More exotic RX-50 types not supported, nor is there support for de-interleaving the first two tracks where the physical sectors are 0 1 2 3 4 5 6 7 8 9, but they should be interpreted as 0 5 1
Re: EFI zfs loader and beadm?
Make sure you are running the latest snapshot of current or 10.3 as well, as the MFC commits were in early February for 10-stable On 9 March 2016 at 16:01, Andrey Fesenko wrote: > On Wed, Mar 9, 2016 at 6:48 PM, Eric van Gyzen wrote: > > On 03/09/2016 09:40, Andrey Fesenko wrote: > >> Hello, > >> I'm test EFI boot ZFSroot with BE, this not support now? > >> svn 2965489 > >> > >> If i build simplest system > >> > http://blog.multiplay.co.uk/2015/12/freebsd-10-2-release-efi-zfs-root-boot/ > >> > >> # zfs get -r mountpoint efifpool > >> NAME PROPERTYVALUE SOURCE > >> efifpool mountpoint /mnt/efifpool default > >> > >> => 40 30712240 da0 GPT (15G) > >> 40 16001 efi (800K) > >> 1640 307106322 freebsd-zfs (15G) > >> 30712272 8 - free - (4.0K) > >> > >> system boot nice > >> > >> If make BE env > >> > >> # zfs get -r mountpoint efiwpool > >> NAME PROPERTYVALUE SOURCE > >> efiwpool mountpoint none local > >> efiwpool/ROOT mountpoint none > >> inherited from efiwpool > >> efiwpool/ROOT/initmountpoint legacy local > >> efiwpool/ROOT/init@init mountpoint - - > >> efiwpool/ROOT/init/boot mountpoint /media/bootlocal > >> efiwpool/ROOT/init/tmpmountpoint /media/tmp local > >> efiwpool/ROOT/init/usrmountpoint /media/usr local > >> efiwpool/ROOT/init/usr@init mountpoint - - > >> efiwpool/ROOT/init/usr/home mountpoint /media/usr/home > >> inherited from efiwpool/ROOT/init/usr > >> efiwpool/ROOT/init/usr/home@init mountpoint - - > >> efiwpool/ROOT/init/varmountpoint /media/var local > >> efiwpool/ROOT/init/var@init mountpoint - - > >> efiwpool/ROOT/init/var/crash mountpoint /media/var/crash > >> inherited from efiwpool/ROOT/init/var > >> efiwpool/ROOT/init/var/db mountpoint /media/var/db > >> inherited from efiwpool/ROOT/init/var > >> efiwpool/ROOT/init/var/db/pkg mountpoint /media/var/db/pkg > >> inherited from efiwpool/ROOT/init/var > >> efiwpool/ROOT/init/var/empty mountpoint /media/var/empty > >> inherited from efiwpool/ROOT/init/var > >> efiwpool/ROOT/init/var/logmountpoint /media/var/log > >> inherited from efiwpool/ROOT/init/var > >> efiwpool/ROOT/init/var/mail mountpoint /media/var/mail > >> inherited from efiwpool/ROOT/init/var > >> efiwpool/ROOT/init/var/runmountpoint /media/var/run > >> inherited from efiwpool/ROOT/init/var > >> efiwpool/ROOT/init/var/tmpmountpoint /media/var/tmp > >> inherited from efiwpool/ROOT/init/var > >> > >> system not boot. > >> > >> Not found /boot/loader.efi (in BE system real path > >> efiwpool/ROOT/init/boot/loader.efi) if copy this efiwpool/ROOT/init > >> (blank in BE system) loader found this (but not found /boot/kernel) I > >> can copy this and get a similar system > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192184#c15 (with out > >> msdos kernel part), but this ruin BE update mechanism > > > > Your dataset hierarchy is not what beadm expects. Specifically, you > > have /boot separate from /, which I imagine is causing your problem. > > /boot should be part of /. Also, you have several file systems in the > > BE that are usually not in it; I doubt this is part of your boot > > failure, though. > > > > For reference, here is my layout, which is mostly the same as the > > default installation: > > > > NAME USED AVAIL REFER MOUNTPOINT > > zroot 117G 108G96K none > > zroot/ROOT 14.8G 108G96K none > > zroot/ROOT/10.2 444K 108G 6.35G / > > zroot/ROOT/103beta 14.8G 108G 8.75G / > > zroot/ROOT/103beta1 8K 108G 8.17G / > > zroot/ROOT/103beta3 8K 108G 8.75G / > > zroot/home 97.8G 108G 94.9G /home > > zroot/usr3.36G 108G96K /usr > > zroot/usr/ports 985M 108G 736M /usr/ports > > zroot/usr/src2.40G 108G 2.19G /usr/src > > zroot/var2.19M 108G96K /var > > zroot/var/audit96K 108G96K /var/audit > > zroot/var/crash96K 108G96K /var/crash > > zroot/var/log1.15M 108G 420K /var/log > > zroot/var/mail360K 108G 120K /var/mail > > zroot/var/tmp 416K 108G 144K /var/tmp > > > > Eric > > If remove efiwpool/ROOT/init/boot and copy his content on > efiwpool/ROOT/init my scheme work fine too. > /usr /var /home and other included in BE for consistent boot system > (CURRENT world may not boot with kernel other rev), and old home > snapshot sometimes useful for backup/restore >
Re: [CFT] packaging the base system with pkg(8)
On Tue, Mar 08, 2016 at 03:40:16PM +0300, Slawa Olhovchenkov wrote: > About use cases. I am try to imagine different use cases and don't > found answer how do this: > > 1. package building as `make packages` witch version as timestamp of > start buildworld. I.e. on every buildworld every package will be > rebuild, take new version and will be reinstaled. Where is profit of > package spliting? > > 2. After src.conf change some package don't build. Where analog of > `make delete-old delete-old-libs`? > Some forgotten points: 7. What about src/tools/tools? Do you planed to package this? 8. Current layout is incompatible with beadm: /var/db/pkg is placed on /var and separated from beadm control (zroot/ROOT). As result, switching OS install by beadm give incorrectly information about installed packages. For correcting this need separatly pkg database for system packages under beadm control. Same for etcupdate database. 9. etcupdate database currently don't populated under upgrade process. Proposal: may be retreating from concept 'every file owned only by one package' can be solved problem with 'fat' base packages and thin upgrades? Upgrade/SA package will be contain only modyfied (and 'imaginary' for deleting) files, replaced files initially installed. ___ 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: EFI zfs loader and beadm?
presumably it boots now? On 10 March 2016 at 11:01, Andrey Fesenko wrote: > On Thu, Mar 10, 2016 at 1:49 PM, krad wrote: > > Make sure you are running the latest snapshot of current or 10.3 as > well, as > > the MFC commits were in early February for 10-stable > > > >> > >> If remove efiwpool/ROOT/init/boot and copy his content on > >> efiwpool/ROOT/init my scheme work fine too. > >> /usr /var /home and other included in BE for consistent boot system > >> (CURRENT world may not boot with kernel other rev), and old home > >> snapshot sometimes useful for backup/restore > >> ___ > > % uname -a > FreeBSD x220.efi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296548: > Wed Mar 9 01:16:17 MSK 2016 > root@des.local:/usr/obj/usr/src/sys/X220 amd64 > ___ 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"
sparc64 linker scripts get installed and removed during upgrade
I have a sparc64 host running stable/10. I have noticed on the last several updates that I've done (basic list of operations below): checkout current stable/10 sources make buildworld make buildkernel make installkernel reboot mergemaster -p make installworld mergemaster make delete-old I get a bunch of sparc64 linker scripts that get installed each time, and then are removed during the 'make delete-old' operation. root@gatekeeper-372: make delete-old && make delete-old-libs >>> Removing old files (only deletes safe to delete libs) remove /usr/libdata/ldscripts/elf64_sparc.x? y remove /usr/libdata/ldscripts/elf64_sparc.xbn? y remove /usr/libdata/ldscripts/elf64_sparc.xn? y remove /usr/libdata/ldscripts/elf64_sparc.xr? y remove /usr/libdata/ldscripts/elf64_sparc.xs? y remove /usr/libdata/ldscripts/elf64_sparc.xu? y remove /usr/libdata/ldscripts/elf64_sparc.xc? y remove /usr/libdata/ldscripts/elf64_sparc.xsc? y remove /usr/libdata/ldscripts/elf32_sparc.x? y remove /usr/libdata/ldscripts/elf32_sparc.xbn? y remove /usr/libdata/ldscripts/elf32_sparc.xn? y remove /usr/libdata/ldscripts/elf32_sparc.xr? y remove /usr/libdata/ldscripts/elf32_sparc.xs? y remove /usr/libdata/ldscripts/elf32_sparc.xu? y remove /usr/libdata/ldscripts/elf32_sparc.xc? y remove /usr/libdata/ldscripts/elf32_sparc.xsc? y I would think these shouldn't be installed at all, if they are not needed or obsolete. Thanks. -Kurt ___ 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: EFI zfs loader and beadm?
As Eric said you cant have /boot on a separate dataset as the whole loader bootstrap isnt designed too look for it on the dataset defined by bootfs. Remember no other datasets are mounted at that stage of the bootstrap. You could maybe bodge something by manually playing around with the bootfs property, symlinks and rootfs variables in the loader.conf. But why would you want to do this? It's more work and non standard, and will break a lot? On 10 March 2016 at 12:11, Andrey Fesenko wrote: > On Thu, Mar 10, 2016 at 2:55 PM, krad wrote: > > presumably it boots now? > > > > On 10 March 2016 at 11:01, Andrey Fesenko wrote: > >> > >> On Thu, Mar 10, 2016 at 1:49 PM, krad wrote: > >> > Make sure you are running the latest snapshot of current or 10.3 as > >> > well, as > >> > the MFC commits were in early February for 10-stable > >> > > >> >> > >> >> If remove efiwpool/ROOT/init/boot and copy his content on > >> >> efiwpool/ROOT/init my scheme work fine too. > >> >> /usr /var /home and other included in BE for consistent boot system > >> >> (CURRENT world may not boot with kernel other rev), and old home > >> >> snapshot sometimes useful for backup/restore > >> >> ___ > >> > >> % uname -a > >> FreeBSD x220.efi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296548: > >> Wed Mar 9 01:16:17 MSK 2016 > >> root@des.local:/usr/obj/usr/src/sys/X220 amd64 > > > > > > My current working config > % mount > efiwpool/ROOT/init0 on / (zfs, local, noatime, nfsv4acls) > devfs on /dev (devfs, local, multilabel) > efiwpool/ROOT/init0/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls) > efiwpool/ROOT/init0/usr on /usr (zfs, local, noatime, nfsv4acls) > efiwpool/ROOT/init0/usr/home on /usr/home (zfs, local, noatime, nfsv4acls) > efiwpool/ROOT/init0/var on /var (zfs, local, noatime, nfsv4acls) > efiwpool/ROOT/init0/var/crash on /var/crash (zfs, local, noatime, > noexec, nosuid, nfsv4acls) > efiwpool/ROOT/init0/var/db on /var/db (zfs, local, noatime, noexec, > nosuid, nfsv4acls) > efiwpool/ROOT/init0/var/db/pkg on /var/db/pkg (zfs, local, noatime, > nosuid, nfsv4acls) > efiwpool/ROOT/init0/var/db/tlpkg on /var/db/tlpkg (zfs, local, > noatime, nosuid, nfsv4acls) > efiwpool/ROOT/init0/var/empty on /var/empty (zfs, local, noatime, > noexec, nosuid, read-only, nfsv4acls) > efiwpool/ROOT/init0/var/log on /var/log (zfs, local, noatime, noexec, > nosuid, nfsv4acls) > efiwpool/ROOT/init0/var/mail on /var/mail (zfs, local, noatime, > noexec, nosuid, nfsv4acls) > efiwpool/ROOT/init0/var/run on /var/run (zfs, local, noatime, noexec, > nosuid, nfsv4acls) > efiwpool/ROOT/init0/var/tmp on /var/tmp (zfs, local, noatime, nosuid, > nfsv4acls) > > => 40 234441568 ada1 GPT (112G) > 40 1600 1 efi (800K) >1640 234439960 2 freebsd-zfs (112G) > 234441600 8- free - (4.0K) > > % zfs get -r mountpoint efiwpool > NAME PROPERTY > VALUE SOURCE > efiwpool mountpoint none > local > efiwpool/ROOT mountpoint none > inherited from efiwpool > efiwpool/ROOT/initmountpoint > legacy local > efiwpool/ROOT/init/tmpmountpoint /tmp > local > > > This work fine, booted, beadm create new env, activate them, see boot > menu and select BE. > > % beadm list > BEActive Mountpoint Space Created > init - - 420.7M 2016-03-09 02:57 > init0 NR / 35.9G 2016-03-10 05:00 > > If i'm add separate dataset for /boot (efiwpool/ROOT/init0/boot) > system not booted, efi loader (first stage) see only my pool, not > found /boot/loader.efi > ___ 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: ukbd.c: error: use of undeclared identifier 'key_map'
> Subject: Re: ukbd.c: error: use of undeclared identifier 'key_map' > To: sg...@hotmail.com; freebsd-current@freebsd.org; ema...@freebsd.org > From: h...@selasky.org > Date: Thu, 10 Mar 2016 08:00:02 +0100 > > On 03/09/16 23:04, Brendan Sechter wrote: >> Hello- >> >> My kernel fails to build when I specify a default keymap. The problem >> appears to >> exist in both atkbd(4) and ukbd(4). My last build appears to have succeeded >> in >> September of last year. That may have been when I added the option. >> >> My kernel config and the failing build output for ukbd are below. The >> VIRTUALBOX >> kernel config below built without issue. >> >> Regards, >> -Brendan >> > > Hi, > > Given the heavy rework in the console area in 11-current I'm not sure if > this feature works any more or if it needs to be updated. Maybe Ed Maste > knows? > > --HPS I tried a couple more builds and the *KBD_DFLT_KEYMAP options do appear to be the problem. This works. # AT Keyboard device atkbdc device atkbd #options ATKBD_DFLT_KEYMAP #makeoptions ATKBD_DFLT_KEYMAP=jp.106 # USB Keyboard device ukbd #options UKBD_DFLT_KEYMAP #makeoptions UKBD_DFLT_KEYMAP=jp.106 This does not. # AT Keyboard device atkbdc device atkbd options ATKBD_DFLT_KEYMAP #makeoptions ATKBD_DFLT_KEYMAP=jp.106 # USB Keyboard device ukbd options UKBD_DFLT_KEYMAP #makeoptions UKBD_DFLT_KEYMAP=jp.106 Regards, -Brendan ___ 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: EFI zfs loader and beadm?
On Thu, Mar 10, 2016 at 6:11 PM, krad wrote: > As Eric said you cant have /boot on a separate dataset as the whole loader > bootstrap isnt designed too look for it on the dataset defined by bootfs. > Remember no other datasets are mounted at that stage of the bootstrap. > > You could maybe bodge something by manually playing around with the bootfs > property, symlinks and rootfs variables in the loader.conf. But why would > you want to do this? It's more work and non standard, and will break a lot? > > > > On 10 March 2016 at 12:11, Andrey Fesenko wrote: >> >> On Thu, Mar 10, 2016 at 2:55 PM, krad wrote: >> > presumably it boots now? >> > >> > On 10 March 2016 at 11:01, Andrey Fesenko wrote: >> >> >> >> On Thu, Mar 10, 2016 at 1:49 PM, krad wrote: >> >> > Make sure you are running the latest snapshot of current or 10.3 as >> >> > well, as >> >> > the MFC commits were in early February for 10-stable >> >> > >> >> >> >> >> >> If remove efiwpool/ROOT/init/boot and copy his content on >> >> >> efiwpool/ROOT/init my scheme work fine too. >> >> >> /usr /var /home and other included in BE for consistent boot system >> >> >> (CURRENT world may not boot with kernel other rev), and old home >> >> >> snapshot sometimes useful for backup/restore >> >> >> ___ >> >> >> >> % uname -a >> >> FreeBSD x220.efi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296548: >> >> Wed Mar 9 01:16:17 MSK 2016 >> >> root@des.local:/usr/obj/usr/src/sys/X220 amd64 >> > >> > >> >> My current working config >> % mount >> >> >> This work fine, booted, beadm create new env, activate them, see boot >> menu and select BE. >> >> % beadm list >> BEActive Mountpoint Space Created >> init - - 420.7M 2016-03-09 02:57 >> init0 NR / 35.9G 2016-03-10 05:00 >> >> If i'm add separate dataset for /boot (efiwpool/ROOT/init0/boot) >> system not booted, efi loader (first stage) see only my pool, not >> found /boot/loader.efi > > It probably does not matter, as bootfs have snapshots (BE), just wanted to make it more clear (having taken significant mountpoint /boot, /usr, /var... in zfs dataset) and was surprised why the system does not boot It is clear that as long as the functionality is experimental and under development, but would like to see where the full instructions on its implementation / restrictions, at least as early as has been described https://wiki.freebsd.org/RootOnZFS ___ 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: EFI zfs loader and beadm?
On Thu, 10 Mar 2016 18:38+0300, Andrey Fesenko wrote: > On Thu, Mar 10, 2016 at 6:11 PM, krad wrote: > > As Eric said you cant have /boot on a separate dataset as the whole loader > > bootstrap isnt designed too look for it on the dataset defined by bootfs. > > Remember no other datasets are mounted at that stage of the bootstrap. > > > > You could maybe bodge something by manually playing around with the bootfs > > property, symlinks and rootfs variables in the loader.conf. But why would > > you want to do this? It's more work and non standard, and will break a lot? > > > > > > > > On 10 March 2016 at 12:11, Andrey Fesenko wrote: > >> > >> On Thu, Mar 10, 2016 at 2:55 PM, krad wrote: > >> > presumably it boots now? > >> > > >> > On 10 March 2016 at 11:01, Andrey Fesenko wrote: > >> >> > >> >> On Thu, Mar 10, 2016 at 1:49 PM, krad wrote: > >> >> > Make sure you are running the latest snapshot of current or 10.3 as > >> >> > well, as > >> >> > the MFC commits were in early February for 10-stable > >> >> > > >> >> >> > >> >> >> If remove efiwpool/ROOT/init/boot and copy his content on > >> >> >> efiwpool/ROOT/init my scheme work fine too. > >> >> >> /usr /var /home and other included in BE for consistent boot system > >> >> >> (CURRENT world may not boot with kernel other rev), and old home > >> >> >> snapshot sometimes useful for backup/restore > >> >> >> ___ > >> >> > >> >> % uname -a > >> >> FreeBSD x220.efi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296548: > >> >> Wed Mar 9 01:16:17 MSK 2016 > >> >> root@des.local:/usr/obj/usr/src/sys/X220 amd64 > >> > > >> > > >> > >> My current working config > >> % mount > >> > >> > >> This work fine, booted, beadm create new env, activate them, see boot > >> menu and select BE. > >> > >> % beadm list > >> BEActive Mountpoint Space Created > >> init - - 420.7M 2016-03-09 02:57 > >> init0 NR / 35.9G 2016-03-10 05:00 > >> > >> If i'm add separate dataset for /boot (efiwpool/ROOT/init0/boot) > >> system not booted, efi loader (first stage) see only my pool, not > >> found /boot/loader.efi > > > > > > It probably does not matter, as bootfs have snapshots (BE), just > wanted to make it more clear (having taken significant mountpoint > /boot, /usr, /var... in zfs dataset) and was surprised why the system > does not boot > > It is clear that as long as the functionality is experimental and > under development, but would like to see where the full instructions > on its implementation / restrictions, at least as early as has been > described https://wiki.freebsd.org/RootOnZFS If you keep /boot as a separate dataset/filesystem, with efiwpool/ROOT/init0/boot as the given bootfs, then boot1.efi will not see a /boot directory inside that dataset. The files and directories from /boot will be presented as living in /, the local root directory of that dataset. You could create a /boot/boot symlink pointing to . (dot), but it's better to let /boot be part of the regular boot environment, pretty similar to what you would find on a UFS system using a separate root filesystem. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: sparc64 linker scripts get installed and removed during upgrade
On 3/10/16 7:10 AM, Kurt Lidl wrote: > I have a sparc64 host running stable/10. > > I have noticed on the last several updates that I've > done (basic list of operations below): > checkout current stable/10 sources > make buildworld > make buildkernel > make installkernel > reboot > mergemaster -p > make installworld > mergemaster > make delete-old > > I get a bunch of sparc64 linker scripts that get installed > each time, and then are removed during the 'make delete-old' > operation. > > root@gatekeeper-372: make delete-old && make delete-old-libs > Removing old files (only deletes safe to delete libs) > remove /usr/libdata/ldscripts/elf64_sparc.x? y > remove /usr/libdata/ldscripts/elf64_sparc.xbn? y > remove /usr/libdata/ldscripts/elf64_sparc.xn? y > remove /usr/libdata/ldscripts/elf64_sparc.xr? y > remove /usr/libdata/ldscripts/elf64_sparc.xs? y > remove /usr/libdata/ldscripts/elf64_sparc.xu? y > remove /usr/libdata/ldscripts/elf64_sparc.xc? y > remove /usr/libdata/ldscripts/elf64_sparc.xsc? y > remove /usr/libdata/ldscripts/elf32_sparc.x? y > remove /usr/libdata/ldscripts/elf32_sparc.xbn? y > remove /usr/libdata/ldscripts/elf32_sparc.xn? y > remove /usr/libdata/ldscripts/elf32_sparc.xr? y > remove /usr/libdata/ldscripts/elf32_sparc.xs? y > remove /usr/libdata/ldscripts/elf32_sparc.xu? y > remove /usr/libdata/ldscripts/elf32_sparc.xc? y > remove /usr/libdata/ldscripts/elf32_sparc.xsc? y > > I would think these shouldn't be installed at all, if they > are not needed or obsolete. > This should fix it once MFC'd: https://svnweb.freebsd.org/changeset/base/296623 -- Regards, Bryan Drewery ___ 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: zfsboot patch for /usr
> You don't mkdir it, you create it as a ZFS dataset, and mark it with the > 'canmount=no' property, so it only exists to be a parent, not as an > actual dataset. This is the default in zfboot currently. Thanks to everyone for pointing this out. I'll forget about mkdir then, ignore the output of 'zfs list' and get comfortable doing things the zfs way. Still have to tweak scripts/zfsboot to create a /var/spool subvol, a /home subvol in place of /usr/home and specify atime=none in the default dataset. At least the latter works as expected. Roger ___ 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: zfsboot patch for /usr
No need to ignore the output of zfs list, here is an explanation of zfs list's output, this is in the zfs man page. I think you're confusing used with refer. used The amount of space consumed by this dataset and all its descendents. This is the value that is checked against this dataset's quota and reservation. The space used does not include this dataset's reserva‐ tion, but does take into account the reservations of any descendent datasets. The amount of space that a dataset consumes from its par‐ ent, as well as the amount of space that are freed if this dataset is recursively destroyed, is the greater of its space used and its reservation. When snapshots (see the "Snapshots" section) are created, their space is initially shared between the snapshot and the file system, and possibly with previous snapshots. As the file system changes, space that was previously shared becomes unique to the snapshot, and counted in the snapshot's space used. Additionally, deleting snap‐ shots can increase the amount of space unique to (and used by) other snapshots. The amount of space used, available, or referenced does not take into account pending changes. Pending changes are generally accounted for within a few seconds. Committing a change to a disk using fsync(2) or O_SYNC does not necessarily guarantee that the space usage informa‐ tion is updated immediately. available The amount of space available to the dataset and all its children, assuming that there is no other activity in the pool. Because space is shared within a pool, availability can be limited by any number of factors, including physical pool size, quotas, reservations, or other datasets within the pool. This property can also be referred to by its shortened column name, avail. referenced The amount of data that is accessible by this dataset, which may or may not be shared with other datasets in the pool. When a snapshot or clone is created, it initially references the same amount of space as the file system or snapshot it was created from, since its contents are identical. This property can also be referred to by its shortened column name, refer. On Thu, Mar 10, 2016 at 7:06 PM, Roger Marquis wrote: > > You don't mkdir it, you create it as a ZFS dataset, and mark it with the > > 'canmount=no' property, so it only exists to be a parent, not as an > > actual dataset. This is the default in zfboot currently. > > Thanks to everyone for pointing this out. I'll forget about mkdir then, > ignore the output of 'zfs list' and get comfortable doing things the zfs > way. > > Still have to tweak scripts/zfsboot to create a /var/spool subvol, a /home > subvol in place of /usr/home and specify atime=none in the default dataset. > At least the latter works as expected. > > Roger > > > ___ > 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" > ___ 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"
FreeBSD_HEAD_i386 - Build #2564 - Failure
FreeBSD_HEAD_i386 - Build #2564 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2564/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2564/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2564/console Change summaries: 296647 by bdrewery: Use the new bmake .dinclude feature to make these safe. At least FAST_DEPEND won't even run 'make depend', so the code was potentially broken with FAST_DEPEND anyhow. The .dinclude directive will ignore missing files rather than make them be fatal. Sponsored by: EMC / Isilon Storage Division 296646 by bdrewery: FAST_DEPEND: Use .dinclude to enable full .depend logic in bmake. The inclusion of .MAKE.DEPENDFILE (.depend) has special logic in make to ignore stale/missing dependencies. bmake 20160220 added a '.dinclude' directive that uses the special logic for .depend when including the file. This fixes a build error when a file is moved or deleted that exists in a .depend.OBJ file. This happened in r292782 when sha512c.c "moved" and an incremental build of lib/libmd would fail with: make: don't know how to make /usr/src/lib/libcrypt/../libmd/sha512c.c. Stop Now this will just be seen as a stale dependency and cause a rebuild: make: /usr/obj/usr/src/lib/libmd/.depend.sha512c.o, 13: ignoring stale .depend for /usr/src/lib/libcrypt/../libmd/sha512c.c --- sha512c.o --- ... This rebuild will only be done once since the .depend.sha512c.o will be updated on the build with the -MF flags. This also removes -MP being passed for the .depend.OBJ generation (which would create fake targets for system headers) since the logic is no longer needed to protect from missing files. Sponsored by: EMC / Isilon Storage Division 296645 by bdrewery: Fix bmake upgrade NO_MAN warnings. MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 296644 by bdrewery: Fix upgrade of bmake by not setting conflicting MAKE_VERSION. This may be used in later checks, such as in bsd.dep.mk, to enable features that rely on the built-in value. Sponsored by: EMC / Isilon Storage Division 296643 by bdrewery: Fix make -n upgrade_checks. MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 296642 by imp: Factor out lib32 generation to its own file. This is prep for a similar Makefile.libsoft which will do the same for armv6 soft fp API libraries in prep for pulling the trigger on moving to armv6 hard float. Once there's two files, I'll work with bdrewery@ to merge the two files as they are mostly the same. The high rate of churn for Makefile* makes it quite difficult to make progress out of tree. Differential Review: https://reviews.freebsd.org/D5566 296641 by np: cxgbe(4): Add sysctls to display the TP microcode version and the expansion rom version (if there's one). trantor:~# sysctl dev.t4nex dev.t5nex | grep _version dev.t4nex.0.firmware_version: 1.15.28.0 dev.t4nex.0.tp_version: 0.1.9.4 dev.t5nex.0.firmware_version: 1.15.28.0 dev.t5nex.0.exprom_version: 1.0.0.68 dev.t5nex.0.tp_version: 0.1.4.9 296640 by np: cxgbe(4): Add a sysctl for the event capture mask of the TP block's logic analyzer. dev.t5nex..misc.tp_la_mask dev.t4nex..misc.tp_la_mask 296637 by sjg: Merge bmake-20160307 The end of the build log: Started by an SCM change Building remotely on kyua6.nyi.freebsd.org (jailer) in workspace /jenkins/workspace/FreeBSD_HEAD_i386 Updating svn://svnmir.freebsd.org/base/head at revision '2016-03-11T05:14:11.863 +' U lib/clang/clang.build.mk U Makefile U share/mk/bsd.dep.mk U share/mk/dirdeps.mk U share/mk/gendirdeps.mk U share/mk/meta.autodep.mk U share/mk/meta.stage.mk U share/mk/meta.sys.mk U share/mk/sys.dependfile.mk U sys/conf/kern.post.mk U sys/dev/cxgbe/adapter.h U sys/dev/cxgbe/common/common.h U sys/dev/cxgbe/t4_main.c U usr.bin/bmake/Makefile U Makefile.inc1 AUMakefile.lib32 U contrib/bmake/ChangeLog U contrib/bmake/Makefile U contrib/bmake/arch.c U contrib/bmake/bmake.1 U contrib/bmake/bmake.cat1 U contrib/bmake/compat.c U contrib/bmake/cond.c U contrib/bmake/dirname.c U contrib/bmake/for.c U contrib/bmake/getopt.c U contrib/bmake/job.c U contrib/bmake/main.c U contrib/bmake/make.1 U contrib/bmake/make.c U contrib/bmake/make.h U contrib/bmake/meta.c U contrib/bmake/meta.h U contrib/bmake/mk/ChangeLog U contrib/bmake/mk/auto.dep.mk U contrib/bmake/mk/dirdeps.mk U contrib/bmake/mk/gendirdeps.mk U contrib/bmake/mk/install-mk U contrib/bmake/mk/meta.autodep.mk U contrib/bmake/mk/meta.stage.mk U contrib/bmake/mk/meta.sys.mk U contrib/bmake/mk/meta2deps.sh U contrib/bmake/mk/sys.clean-env.mk U contrib/bmake/mk/sys.
FreeBSD_HEAD_i386 - Build #2565 - Still Failing
FreeBSD_HEAD_i386 - Build #2565 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2565/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2565/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2565/console Change summaries: 296648 by ak: - Implement -T option to allow to specify a fs type for a vnode-backed memory disk - Rephrase -t option description (manpage) - Split long sentences (manpage) Differential Review:https://reviews.freebsd.org/D4394 Reviewed by:mav, wblock (manpage) Approved by:mav The end of the build log: Started by an SCM change Building remotely on kyua6.nyi.freebsd.org (jailer) in workspace /jenkins/workspace/FreeBSD_HEAD_i386 Updating svn://svnmir.freebsd.org/base/head at revision '2016-03-11T07:15:06.118 +' U sbin/mdmfs/mdmfs.8 U sbin/mdmfs/mdmfs.c At revision 296648 No emails were triggered. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson7675996896553092739.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + true + sudo umount FreeBSD_HEAD_i386/usr/src + true + sudo umount FreeBSD_HEAD_i386/dev + true + sudo rm -fr FreeBSD_HEAD_i386 + sudo chflags -R noschg FreeBSD_HEAD_i386 + true + sudo rm -fr FreeBSD_HEAD_i386 [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson7809357646689683467.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo env: env: + /usr/bin/env BUILD_NUMBER=2565 HUDSON_SERVER_COOKIE=0657dbe3541f1b1a JOB_NAME=FreeBSD_HEAD_i386 LOGNAME=jenkins JAVA_HOME=/usr/local/openjdk8 SVN_URL=svn://svnmir.freebsd.org/base/head BUILDER_JAIL_IP=2610:1c1:1:607c::106:1 jname=FreeBSD_HEAD_i386 JENKINS_URL=https://jenkins.FreeBSD.org/ JENKINS_HOME=/usr/local/jenkins PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin HUDSON_HOME=/usr/local/jenkins OLDPWD=/ BUILD_ID=2565 BUILDER_NETIF=igb0 JENKINS_SERVER_COOKIE=0657dbe3541f1b1a PWD=/jenkins/workspace/FreeBSD_HEAD_i386 BUILD_TAG=jenkins-FreeBSD_HEAD_i386-2565 NODE_LABELS=jailer kyua6.nyi.freebsd.org BUILD_DISPLAY_NAME=#2565 HOME=/jenkins USER=jenkins BUILD_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2565/ SVN_URL_1=svn://svnmir.freebsd.org/base/head SVN_REVISION=296648 SVN_REVISION_1=296648 BUILDER_JAIL_IP6=2610:1c1:1:607c::105:1 JOB_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/ SHELL=/bin/sh HUDSON_URL=https://jenkins.FreeBSD.org/ HUDSON_COOKIE=6456cfad-11d7-4eb4-80e3-614c39e3e1fe BUILDER_RESOLV_CONF=nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n WORKSPACE=/jenkins/workspace/FreeBSD_HEAD_i386 NODE_NAME=kyua6.nyi.freebsd.org EXECUTOR_NUMBER=0 + echo 'setup jail FreeBSD_HEAD_i386' setup jail FreeBSD_HEAD_i386 + fetch -m http://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/10.2-RELEASE/base.txz + mkdir FreeBSD_HEAD_i386 + cd FreeBSD_HEAD_i386 + sudo tar Jxf ../base.txz + cd - + sudo mount -t devfs devfs FreeBSD_HEAD_i386/dev + sudo devfs -m FreeBSD_HEAD_i386/dev rule -s 4 applyset + sudo mount -t nullfs src FreeBSD_HEAD_i386/usr/src + printf 'nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n' + sudo tee FreeBSD_HEAD_i386/etc/resolv.conf nameserver 2610:1c1:1:6002::100 nameserver 2610:1c1:1:6002::200 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 alias + sudo jail -c persist 'name=FreeBSD_HEAD_i386' 'path=FreeBSD_HEAD_i386' 'host.hostname=FreeBSD_HEAD_i386.jail.ci.FreeBSD.org' 'ip6.addr=2610:1c1:1:607c::106:1' 'ip4=disable' allow.chflags + echo 'setup build environment' setup build environment + echo 'build environment:' build environment: + sudo jexec FreeBSD_HEAD_i386 sh -c 'uname -a' FreeBSD FreeBSD_HEAD_i386.jail.ci.FreeBSD.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296318: Wed Mar 2 16:40:46 UTC 2016 pe...@build-11.freebsd.org:/usr/obj/usr/src/sys/CLUSTER11 i386 + sudo pkg -j FreeBSD_HEAD_i386 info -q pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson7408431403142023777.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'start build in FreeBSD_HEAD_i386' start build in FreeBSD_HEAD_i386 + sudo jexec FreeBSD_HEAD_i386 sh -c 'cd /usr/src && make -DNO_CLEAN -j 4 buildworld' --- upgrade_checks --- --- bmake --- -- >>> Building an up-to-date bmake(1) -- make[2]: "/usr/share/mk/bsd.own.mk" line 480: MK_MAN can't be set by a user. *** [bmake] Error code 1 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [upgrade_checks] Error code 2 make: stopped in
