Re: FreeBSD 10.0-RC3 Now Available

[Thomas Hoffmann]

All the examples I've seen for updating bootcode assume GPT. If one has MBR
(as I do) and assuming the following basic scheme:

gpart show ada0
=>   63  976773105  ada0  MBR  (466G)
 63  976773105 1  freebsd  [active]  (466G)

gpart show ada0s1
=>0  976773105  ada0s1  BSD  (466G)
  0  943218736   1  freebsd-zfs  (450G)
  943218736   33554369   2  freebsd-swap  (16G)

would the equivalent bootcode statement be:

gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1

where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and
ada0s1 is the slice on which FreeBSD is installed?

Thanks.


On Fri, Dec 27, 2013 at 9:33 AM, Mathieu Arnold  wrote:

> +--On 27 décembre 2013 12:26:49 +0100 Zenny  wrote:
> | On 12/27/13, Mathieu Arnold  wrote:
> |> +--On 27 décembre 2013 00:42:36 +0100 Zenny 
> |> wrote:
> |> | Much awaited release, thanks!. However, does the freebsd-update from
> |> | the earlier version bork in case of ZFS on Root? Or is there a safe
> |> | way to upgrade without borking. I had a very bad experience when I
> |> | upgraded from FreeBSD-10B3 to RC1. Thanks!
> |>
> |> I upgraded from 9.2 to 10.0-RC1, 10.0-RC2 and 10.0-RC3 with
> |> freebsd-update using zfs only boxes, never had any problem. The only
> |> thing is, if you run zpool upgrade, do remember to do what it tells you
> |> about updating the bootcode.
> |>
> |
> | In my case, I didn't receive any instructions to update the bootcode
> | and the bug was acknowledged by the developer.
> |
> | However, can you tell me exactly what did you do exactly to update the
> | bootcode? Appreciate it!
>
> Well, when you run :
> # zpool upgrade yourpool
>
> it will not print a lot of things, but it will end with :
>
> If you boot from pool 'yourpool', don't forget to update boot code.
> Assuming you use GPT partitioning and da0 is your boot disk
> the following command will do it:
>
> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
>
> All you have to do is adapt it to run your particular setup, replacing da0
> with the correct disk (and running it for each disk where your pool is, in
> my case, it was mfid0 and mfid1.)
>
> --
> Mathieu Arnold
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10.0-RC3 Now Available

[Thomas Hoffmann]

After I posted, it occurred to me to check out the
../bsdinstall/scripts/zfsboot  script to see how the boot code was laid
down when the MBR was created. It shows only:

dd if=/boot/zfsboot of=/dev/ada0s1 count =1

But, adding to my confusion, the FreeBSD wiki for ZFS on root (MBR-style)
shows something very close to what Mathieu suggested.

Unfortunately, I'm using an iMac with FreeBSD as the only OS. MBR is the
only way I can get it to boot after an install.

Looks like I've got some testing (and possible system restores) ahead of me.

Thanks.


On Fri, Dec 27, 2013 at 11:08 AM, Warren Block  wrote:

> On Fri, 27 Dec 2013, Mathieu Arnold wrote:
>
>  +--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann 
>> wrote:
>> | All the examples I've seen for updating bootcode assume GPT. If one has
>> | MBR (as I do) and assuming the following basic scheme:
>> |
>> | gpart show ada0
>> | =>   63  976773105  ada0  MBR  (466G)
>> |  63  976773105 1  freebsd  [active]  (466G)
>> |
>> | gpart show ada0s1
>> | =>0  976773105  ada0s1  BSD  (466G)
>> |   0  943218736   1  freebsd-zfs  (450G)
>> |   943218736   33554369   2  freebsd-swap  (16G)
>> |
>> | would the equivalent bootcode statement be:
>> |
>> | gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1
>>
>
> No, the PMBR is for GPT partitioning only.
>
>
>  | where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and
>> | ada0s1 is the slice on which FreeBSD is installed?
>>
>> Hum, no, if you're using MBR and not GPT, you can't use gpart,
>>
>
> Why not?  gpart is not GPT-specific.  It handles MBR and BSDlabel bootcode
> correctly.
>
>
>  you have to
>> do something aweful like this :
>> # dd if=/boot/zfsboot of=/dev/ada0 count=1
>>
>
> That will overwrite the MBR partition table.
>
>
>  # sysctl kern.geom.debugflags=0x10
>> # dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024
>>
>
> That seems dangerous.  I have not tried with zfsboot, but this should be
> close:
>
>   # gpart bootcode -b /boot/zfsboot ada0
>   # gpart bootcode -b /boot/zfsboot ada0s1
>
> Untested!  The first one may need to use /boot/mbr.  A better way to do
> this, provided the system does not have a broken BIOS, would be to backup,
> repartition with GPT, and restore, avoiding the complication of multiple
> partitioning schemes.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10.0-RC3 Now Available

[Thomas Hoffmann]

On Fri, Dec 27, 2013 at 12:15 PM, Scot Hetzel  wrote:

> The correct way to install/update ZFS Boot code on an MBR disk is:
>
> Install boot Manager (required on first install)
>
> # gpart bootcode -b /boot/boot0 ad0
>
> Note: /boot/mbr could also be used if you are not multibooting
>
> Install ZFS boot1 stage
>
> # sysctl kern.geom.debugflags=0x10
> # dd if=/boot/zfsboot of=/dev/ada0s1 count=1
>
> or
>
> # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1
> # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1
>
> Install ZFS boot2 stage
> # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024


This ties everything together nicely for me, especially the part about the
first bootcode install, which had me really confused. Thanks.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...

[Thomas Hoffmann]

On Mon, Jan 20, 2014 at 11:37 AM, Konstantin Belousov
wrote:

> On Mon, Jan 20, 2014 at 07:36:15AM -0800, David Wolfskill wrote:
> > Jan 20 07:02:16 freebeast syslogd: exiting on signal 15
> > Waiting (max 60 seconds) for system process `vnlru' to stop...done
> > Waiting (max 60 seconds) for system process `syncer' to stop...
> > Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done
> > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> > All buffers synced.
> > lock order reversal:
> >  1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237
> >  2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at
> db_trace_self_wrapper+0x2d/frame 0xe1fb9828
> > kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at
> kdb_backtrace+0x30/frame 0xe1fb9890
> > witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at
> witness_checkorder+0xc8a/frame 0xe1fb98e0
> > __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at
> __lockmgr_args+0x844/frame 0xe1fb99b4
> > vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at
> vop_stdlock+0x4d/frame 0xe1fb99e4
> > VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at
> VOP_LOCK1_APV+0x104/frame 0xe1fb9a10
> > _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at
> _vn_lock+0xa1/frame 0xe1fb9a50
> > ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at
> ffs_flushfiles+0x14c/frame 0xe1fb9a9c
> > softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at
> softdep_flushfiles+0x6e/frame 0xe1fb9af0
> > ffs_unmount(c753f000,8,e1fb9b70,518,c6f0a310,...) at
> ffs_unmount+0x194/frame 0xe1fb9b38
> > dounmount(c753f000,8,c6f0a310,0,e1db3eb0,...) at
> dounmount+0x4dc/frame 0xe1fb9b98
> > vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at
> vfs_unmountall+0x4e/frame 0xe1fb9bb8
> > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame
> 0xe1fb9c20
> > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at
> sys_reboot+0x6f/frame 0xe1fb9c40
> > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc
> > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc
> > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp =
> 0xbfbfd88c, ebp = 0xbfbfd960 ---
> > Uptime: 4m28s
> > panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @
> /usr/src/sys/dev/uart/uart_cpu.h:94
> >
> > cpuid = 0
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...)
> at db_trace_self_wrapper+0x2d/frame 0xe1fb9a60
> > kdb_backtrace(c12ec1f3,0,c11269a2,e1fb9b38,e1fb9b08,...) at
> kdb_backtrace+0x30/frame 0xe1fb9ac8
> > vpanic(c140d0c8,100,c11269a2,e1fb9b38,e1fb9b38,...) at
> vpanic+0x11f/frame 0xe1fb9b08
> > kassert_panic(c11269a2,c10f66d8,c10f6758,5e,8,...) at
> kassert_panic+0xea/frame 0xe1fb9b2c
> > __mtx_lock_spin_flags(c7291830,0,c10f6758,5e,c137d684,...) at
> __mtx_lock_spin_flags+0x190/frame 0xe1fb9b5c
> > ns8250_bus_grab(c7291800,c7062b28,c137d684,5e,c140b9a4,...) at
> ns8250_bus_grab+0x40/frame 0xe1fb9b78
> > uart_grab(c13fd070) at uart_grab+0x83/frame 0xe1fb9b9c
> > uart_cngrab(c137d69c,8889,e1fb9c20,c0ac7d43,c1128e43,...) at
> uart_cngrab+0x12/frame 0xe1fb9ba8
> > cngrab(c1128e43,1c,c112895a,144,c6d8b1a0,...) at cngrab+0x33/frame
> 0xe1fb9bb8
> > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x6d3/frame
> 0xe1fb9c20
> > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at
> sys_reboot+0x6f/frame 0xe1fb9c40
> > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc
> > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc
> > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp =
> 0xbfbfd88c, ebp = 0xbfbfd960 ---
> > KDB: enter: panic
> > [ thread pid 1 tid 12 ]
> > Stopped at  kdb_enter+0x3d: movl$0,kdb_why
> > db> show locks
> > exclusive sleep mutex Giant (Giant) r = 0 (0xc1724910) locked @
> /usr/src/sys/vm/swap_pager.c:2365
> > db>
> >
> >
> > When I issued "reset", the machine came back up normally (in slice
> > 1 -- stable/9).  I then rebooted to slice 4 (head), and issued the
> > same commands I usually do to set the default boot slice back to 1, then
> > "shutdown -p now" -- and re-created the panic.
> >
> > I can leave the machine up for a while if anyone has suggestions for me
> > to poke around.  I have a local private mirror of the FreeBSD SVN repos
> > and a spare bootable slice; I'm williing to try patches.  The machine
> > isn't especially fast, but it's generally OK.
> >
> > If it would be worthwhile, I could reboot my laptop to slice 4 (head) &
> > attempt the same reset-to-slice-1-default & power-off.
> >
> > This definitely did not happen @r260875, and it appears to be quite
> > repeatable @r260904
>
> You do not have option WITNESS_SKIPSPIN in your kernel config, do you ?
>

My recent source upgrade from 10.0-RELEASE r260689 to 11.0-CURRENT r260850
left me with a GENERIC kernel with the follow

Problem updating bootcode on ZFS on root system with MBR

[Thomas Hoffmann]

I am running 11.0-CURRENT (r260850) with zfs on root with MBR.

After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850)
my zpools reported that they needed to be upgraded. So, I upgraded my
zpools and I am attempting to update the bootcode (as required). I managed
to get the boot1 stage code updated, but cannot get the boot2 stage code
updated. Here is what I have done:

# sysctl kern.geom.debugflags=0x10
kern.geom.debugflags: 0 -> 16

# dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.014996 secs (34142 bytes/sec)

# gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1
bootcode written to ada0s1

# dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024
dd: /dev/ada0s1a: Operation not permitted

The final dd statement fails with "operation not permitted". In all my
research,  understood the initial sysctl command I ran would prevent this
particular error from happening.

What do I need to do to get the boot2 code written to /dev/ada0s1a?

Thanks.

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

Re: Problem updating bootcode on ZFS on root system with MBR

[Thomas Hoffmann]

On Tue, Jan 21, 2014 at 10:47 AM, Andriy Gapon  wrote:

> on 21/01/2014 13:18 Andrey V. Elsukov said the following:
> > On 21.01.2014 14:45, Andriy Gapon wrote:
>  What do I need to do to get the boot2 code written to /dev/ada0s1a?
> >>>
> >>> This will work only if ada0s1a isn't in use. The debugflags trick works
> >>> only for whole disk, i.e. for geoms with rank=1. Another way is
> >>> calculate needed offset and write bootcode directly to ada0.
> >>
> >>
> >> And ultimately we should extend our ZFS interface with an ioctl to
> write a blob
> >> to a boot code area of a specified ZFS leaf vdev.  This would the right
> way to
> >> install zfsboot.
> >
> > Hi Andriy,
> >
> > do you have some patches to test? :-)
> >
>
> I don't, but the following patch can serve as a very good example.
> It adds an ioctl that serves a slightly different but quite similar
> purpose:
>
> commit 54802d6659ec134fd221c3daaa8fdf9cee985d39
> Author: Andriy Gapon 
> Date:   Fri Sep 14 23:15:43 2012 +0300
>
> [wip] zfs: add a new ioctl that allows to place text data into pad2
> area
>
> The data is placed into Pad2 area of the first vdev label of a given
> vdev in a given pool.
>
> diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
> b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
> index fb30ea9..4a46cc2 100644
> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
> @@ -162,6 +162,8 @@ typedef enum {
>
>  extern int vdev_label_init(vdev_t *vd, uint64_t txg, vdev_labeltype_t
> reason);
>
> +extern int vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t
> size);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
> b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
> index c7dd3ad..55c87d8 100644
> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
> @@ -855,6 +855,44 @@ retry:
> return (error);
>  }
>
> +int
> +vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t size)
> +{
> +   spa_t *spa = vd->vdev_spa;
> +   zio_t *zio;
> +   char *pad2;
> +   int flags = ZIO_FLAG_CONFIG_WRITER | ZIO_FLAG_CANFAIL;
> +   int error;
> +
> +   if (size > VDEV_PAD_SIZE)
> +   return (EINVAL);
> +
> +   if (!vd->vdev_ops->vdev_op_leaf)
> +   return (ENODEV);
> +   if (vdev_is_dead(vd))
> +   return (ENXIO);
> +
> +   ASSERT(spa_config_held(spa, SCL_ALL, RW_WRITER) == SCL_ALL);
> +
> +   pad2 = zio_buf_alloc(VDEV_PAD_SIZE);
> +   bzero(pad2, VDEV_PAD_SIZE);
> +   memcpy(pad2, buf, size);
> +
> +retry:
> +   zio = zio_root(spa, NULL, NULL, flags);
> +   vdev_label_write(zio, vd, 0, pad2,
> +   offsetof(vdev_label_t, vl_pad2),
> +   VDEV_PAD_SIZE, NULL, NULL, flags);
> +   error = zio_wait(zio);
> +   if (error != 0 && !(flags & ZIO_FLAG_TRYHARD)) {
> +   flags |= ZIO_FLAG_TRYHARD;
> +   goto retry;
> +   }
> +
> +   zio_buf_free(pad2, VDEV_PAD_SIZE);
> +   return (error);
> +}
> +
>  /*
>   *
> ==
>   * uberblock load/sync
> diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
> b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
> index e208ed8..ff90839 100644
> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
> @@ -3404,6 +3404,53 @@ zfs_ioc_log_history(const char *unused, nvlist_t
> *innvl,
> nvlist_t *outnvl)
> return (error);
>  }
>
> +#ifdef __FreeBSD__
> +static int
> +zfs_ioc_nextboot(const char *unused, nvlist_t *innvl, nvlist_t *outnvl)
> +{
> +   char name[MAXNAMELEN];
> +   spa_t *spa;
> +   vdev_t *vd;
> +   char *command;
> +   uint64_t pool_guid;
> +   uint64_t vdev_guid;
> +   int error;
> +
> +   if (nvlist_lookup_uint64(innvl,
> +   ZPOOL_CONFIG_POOL_GUID, &pool_guid) != 0)
> +   return (EINVAL);
> +   if (nvlist_lookup_uint64(innvl,
> +   ZPOOL_CONFIG_GUID, &vdev_guid) != 0)
> +   return (EINVAL);
> +   if (nvlist_lookup_string(innvl,
> +   "command", &command) != 0)
> +   return (EINVAL);
> +
> +   mutex_enter(&spa_namespace_lock);
> +   spa = spa_by_guid(pool_guid, vdev_guid);
> +   if (spa != NULL)
> +   strcpy(name, spa_name(spa));
> +   mutex_exit(&spa_namespace_lock);
> +   if (spa == NULL)
> +   return (ENOENT);
> +
> +   if ((error = spa_open(name, &spa, FTAG)) != 0)
> +   return (error);
> +   spa_vdev_state_enter(spa, SCL_ALL);
> +   vd = spa_lookup_by_guid(spa, vdev_guid, B_TRUE);
> +   if (vd == NULL) {
> +   

Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.

[Thomas Hoffmann]

On Thu, Jan 23, 2014 at 9:56 AM, Warren Block  wrote:
>
>
> Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache:
> less than two minutes for a buildworld on my frequently updated i5/SSD
> system, sometimes less than one minute.


Can you elaborate on this, please? I always clear my /usr/obj before
starting a buildworld, which takes 2 hours to run on my system. Are you
saying if I do "make -DNOCLEAN buildworld" I do not have to clear /usr/obj
first AND my buildworld will run faster (AND with no downside)?

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

lock order reversals w/ backtrace

[Thomas Hoffmann]

A few days ago I started running 11.0-CURRENT at r260971 for the first time.

The last couple of times I shutdown my system I noticed 2 or 3 short "lock
order reversal" messages with accompanying backtraces scroll by. Do these
messages represent a problem that I should report or can I ignore them as
debug in nature? If I should report them, how or where do these messages
get logged? I can find no reference to them in syslog or anywhere else upon
my subsequent reboot.

I also had a couple of these messages pop up the other day while
mounting/umounting USB thumb drives. I did not think anything of them at
the time as the mounts/umounts completed successfully.

Please advise. Thanks.

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

Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.

[Thomas Hoffmann]

On Thu, Jan 23, 2014 at 11:52 AM, Warren Block  wrote:

> On Thu, 23 Jan 2014, Kevin Oberman wrote:
>
>  On Thu, Jan 23, 2014 at 7:47 AM, Thomas Hoffmann 
>> wrote:
>>   On Thu, Jan 23, 2014 at 9:56 AM, Warren Block 
>> wrote:
>>   >
>>   >
>>   > Using -DNOCLEAN with an existing /usr/obj can go even faster than
>> ccache:
>>   > less than two minutes for a buildworld on my frequently updated
>> i5/SSD
>>   > system, sometimes less than one minute.
>>
>>
>> Can you elaborate on this, please? I always clear my /usr/obj before
>> starting a buildworld, which takes 2 hours to run on my system. Are you
>> saying if I do "make -DNOCLEAN buildworld" I do not have to clear /usr/obj
>> first
>>
>
> Yes.  Removing /usr/obj is a faster way of doing 'make clean', mostly.
>
>
>  AND my buildworld will run faster
>>
>
> Yes, because make will see that many/most files have already been built.
>
>  (AND with no downside)?
>>
>
> Well... mostly.  :)
>
> I noticed that after 10.0-RELEASE, uname on my system still said
> "PRERELEASE".  That code had not been rebuilt because make did not see it
> as needing a rebuild.  You can still delete /usr/obj and run a full
> buildworld from scratch every so often.
>
> I should give credit to bdrewery@ for reminding me about -DNOCLEAN when I
> was whining about ccache not working on 10.0.  It turned out to be a better
> solution.
>

Hmm, I particularly like your suggestion of running a full buildworld
periodically. With two hour buildworlds (from scratch) I was planning on
rebuilding every couple of weeks. If using -DNOCLEAN can significantly
reduce my buildworld time, I'll rebuild weekly and do a full build every
fourth week. I'm anxious to give this approach a go and see how much time I
can save on the buildworlds.

Thanks for the info and tips.

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

Re: Fw: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.

[Thomas Hoffmann]

On Thu, Jan 23, 2014 at 2:15 PM, Matthew Rezny  wrote:

> Forwarded because my attempt to reply on list was rejected by
> heavy-handed and oblivious moderation:
>
> "The freebsd-current mailing list is for issues involving
> FreeBSD-CURRENT, not FreeBSD-STABLE.  Neither FreeBSD 9.x nor 10.x is
> "current" -- CURRENT became FreeBSD 11.x as of Thu Oct 10 18:05:13
> 2013 UTC."
>
> Feel free to forward on to the list if you feel this is valuable to
> others. Apparently list owner looked only at the topic, ignore the fact
> it's a reply several levels deep, and did NOT look at the content.
>
> Begin forwarded message:
>
> Date: Thu, 23 Jan 2014 18:22:50 +0100
> From: Matthew Rezny 
> To: freebsd-current@freebsd.org
> Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2
> Stable  to FreeBSD i386 10.0 Release.
>
>
> > On Thu, Jan 23, 2014 at 9:56 AM, Warren Block 
> > wrote:
> > >
> > >
> > > Using -DNOCLEAN with an existing /usr/obj can go even faster than
> > > ccache: less than two minutes for a buildworld on my frequently
> > > updated i5/SSD system, sometimes less than one minute.
> >
> >
> > Can you elaborate on this, please? I always clear my /usr/obj before
> > starting a buildworld, which takes 2 hours to run on my system. Are
> > you saying if I do "make -DNOCLEAN buildworld" I do not have to
> > clear /usr/obj first AND my buildworld will run faster (AND with no
> > downside)?
> >
> > Thanks.
> > -Tom
>
> If you always clear your /usr/obj, you can safely add -DNOCLEAN to the
> build and it will shave off a minute or two (depending on drive speed)
> that would have been spent attempting to delete thousands of non-
> existent files and directories. I've never actually benchmarked, but rm
> -rf /usr/obj followed by make -DNOCLEAN buildworld should take slightly
> less time than a regular buildworld (unless perhaps you use a tmpfs
> backed /usr/obj).
>
> Yes, you can safely do a make -DNOCLEAN bulidworld without first
> clearing out /usr/obj iff conditions are right. If you change anything
> in src.conf or make.conf, then you must clean. If you switch what
> branch you are checking out from then you must clean. If you are
> tracking -STABLE or -CURRENT with regularity (as Warren does) then you
> can usually get away with not cleaning. If you go too long between
> updates to your /usr/src then you might have to clean. If there is a
> disruptive commit, you might have to clean. Sometimes it will be
> obvious because the buildworld won't complete without error, but
> sometimes it will finish with apparent success however some binaries
> will be bad. So, if you get some rather strange behavior shortly after
> installworld, go clean it and build again.
>
> If you are doing your own local development, then you can safely use
> -DNOCLEAN throughout the process. Only if you make a disruptive
> change yourself or possibly if you merge changes from svn would you
> need to clean the build.
>

This is good to know, especially the info on when using -DNOCLEAN might
cause problems and how they might manifest themselves. Thanks.

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

Re: lock order reversals w/ backtrace

[Thomas Hoffmann]

On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky <
hans.petter.sela...@bitfrost.no> wrote:

>  Hi,
>
> Can you see if you can snap some keywords of the backtraces, like usb_xxx 
> usbdx_xxx cam scsi or something like that.
>
> Else I believe there are some sysctl options to prevent the final reboot 
> somehow so that you can write down the messages.
>
> --HPS
>
>
> -Original message-
> > From:Thomas Hoffmann 
> > Sent: Thursday 23rd January 2014 17:15
> > To: freebsd-current 
> > Subject: lock order reversals w/ backtrace
> >
> > A few days ago I started running 11.0-CURRENT at r260971 for the first time.
> >
> > The last couple of times I shutdown my system I noticed 2 or 3 short "lock
> > order reversal" messages with accompanying backtraces scroll by. Do these
> > messages represent a problem that I should report or can I ignore them as
> > debug in nature? If I should report them, how or where do these messages
> > get logged? I can find no reference to them in syslog or anywhere else upon
> > my subsequent reboot.
> >
> > I also had a couple of these messages pop up the other day while
> > mounting/umounting USB thumb drives. I did not think anything of them at
> > the time as the mounts/umounts completed successfully.
> >
> > Please advise. Thanks.
> >
> > -Tom
>
> I managed to snap a photo of my screen during shutdown.
Here is the full text of the first of two lock order reversals I got last
night during system shutdown, both of which are zfs-related to (it
appears?) unmounts. A few lines got chopped as they were out-of-frame when
I took the photo:

shutting down local daemons:
lock order reversal:
  1st 0xf801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237
  2nd 0xf801194f6420 syncer (syncer) @
/usr/src/sys/kern/vfs_subr.c:22[..chopped...]
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame
0xfe01ac78[...chopped...]
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01ac784650
witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01ac7846e0
__lockmgr_args() __lockmgr_args+0x878/frame 0xfe01ac784810
vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01ac784830
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01ac784860
_vn_lock() at _vn_lock+0xab/frame 0xfe01ac7848d0
vputx() at vputx+0x240/frame 0xfe01ac784930
dounmount at dounmount+0x327/frame 0xfe01ac7849b0
sys_unmount() at sys_unmount+0x356/frame 0xfe01ac784ac0
amd64_syscall() at amd64_syscall+0x265/frame 0xfe01ac784bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01ac784bf0
--- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a,
rsp[...chopped...]

I have a zpool on an external USB HDD that I export at shutdown via
rc.shutdown.local. Don't know if that is contributing to this or not. When
I get a chance to bring down the system I will manually export it before
shutdown to see if that makes any difference.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversals w/ backtrace

[Thomas Hoffmann]

On Fri, Jan 24, 2014 at 9:52 AM, Thomas Hoffmann  wrote:

> On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky <
> hans.petter.sela...@bitfrost.no> wrote:
>
>>  Hi,
>>
>> Can you see if you can snap some keywords of the backtraces, like usb_xxx 
>> usbdx_xxx cam scsi or something like that.
>>
>> Else I believe there are some sysctl options to prevent the final reboot 
>> somehow so that you can write down the messages.
>>
>> --HPS
>>
>>
>> -Original message-
>> > From:Thomas Hoffmann 
>> > Sent: Thursday 23rd January 2014 17:15
>>
>> > To: freebsd-current 
>> > Subject: lock order reversals w/ backtrace
>> >
>> > A few days ago I started running 11.0-CURRENT at r260971 for the first 
>> > time.
>>
>> >
>> > The last couple of times I shutdown my system I noticed 2 or 3 short "lock
>> > order reversal" messages with accompanying backtraces scroll by. Do these
>> > messages represent a problem that I should report or can I ignore them as
>>
>> > debug in nature? If I should report them, how or where do these messages
>> > get logged? I can find no reference to them in syslog or anywhere else upon
>> > my subsequent reboot.
>> >
>> > I also had a couple of these messages pop up the other day while
>>
>> > mounting/umounting USB thumb drives. I did not think anything of them at
>> > the time as the mounts/umounts completed successfully.
>> >
>> > Please advise. Thanks.
>> >
>> > -Tom
>>
>> I managed to snap a photo of my screen during shutdown.
> Here is the full text of the first of two lock order reversals I got last
> night during system shutdown, both of which are zfs-related to (it
> appears?) unmounts. A few lines got chopped as they were out-of-frame when
> I took the photo:
>
> shutting down local daemons:
> lock order reversal:
>   1st 0xf801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237
>   2nd 0xf801194f6420 syncer (syncer) @
> /usr/src/sys/kern/vfs_subr.c:22[..chopped...]
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame
> 0xfe01ac78[...chopped...]
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01ac784650
> witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01ac7846e0
> __lockmgr_args() __lockmgr_args+0x878/frame 0xfe01ac784810
> vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01ac784830
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01ac784860
> _vn_lock() at _vn_lock+0xab/frame 0xfe01ac7848d0
> vputx() at vputx+0x240/frame 0xfe01ac784930
> dounmount at dounmount+0x327/frame 0xfe01ac7849b0
> sys_unmount() at sys_unmount+0x356/frame 0xfe01ac784ac0
> amd64_syscall() at amd64_syscall+0x265/frame 0xfe01ac784bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01ac784bf0
> --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a,
> rsp[...chopped...]
>
> I have a zpool on an external USB HDD that I export at shutdown via
> rc.shutdown.local. Don't know if that is contributing to this or not. When
> I get a chance to bring down the system I will manually export it before
> shutdown to see if that makes any difference.
>

Was able to capture the full text of the lock order reversal I've been
experiencing at shutdown. Turns out to be associated with the export of one
of my zpools that is hosted on an external USB HDD. Normally I export the
zpool from rc.shutdown.local, but tonight I exported it manually before I
shutdown and got the following.

lock order reversal:
: 1st 0xf8011952b5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237
: 2nd 0xf8011952b068 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2212
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe01add6e5a0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01add6e650
witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01add6e6e0
__lockmgr_args() at __lockmgr_args+0x878/frame 0xfe01add6e810
vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01add6e830
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01add6e860
_vn_lock() at _vn_lock+0xab/frame 0xfe01add6e8d0
vputx() at vputx+0x240/frame 0xfe01add6e930
dounmount() at dounmount+0x327/frame 0xfe01add6e9b0
sys_unmount() at sys_unmount+0x356/frame 0xfe01add6eae0
amd64_syscall() at amd64_syscall+0x265/frame 0xfe01add6ebf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01add6ebf0
--- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80191c72a, rsp =
0x7fffc4c8, rbp = 0x7fffc960 ---

When imported and mounted, the zpool reports no errors and I have not
experienced any anomalies reading or writing to the zpool. Should I be
concerned?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversals w/ backtrace

[Thomas Hoffmann]

On Fri, Jan 24, 2014 at 11:47 PM, Thomas Hoffmann  wrote:

> On Fri, Jan 24, 2014 at 9:52 AM, Thomas Hoffmann  wrote:
>
>> On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky <
>> hans.petter.sela...@bitfrost.no> wrote:
>>
>>>  Hi,
>>>
>>> Can you see if you can snap some keywords of the backtraces, like usb_xxx 
>>> usbdx_xxx cam scsi or something like that.
>>>
>>> Else I believe there are some sysctl options to prevent the final reboot 
>>> somehow so that you can write down the messages.
>>>
>>>
>>> --HPS
>>>
>>>
>>> -Original message-
>>> > From:Thomas Hoffmann 
>>> > Sent: Thursday 23rd January 2014 17:15
>>>
>>> > To: freebsd-current 
>>> > Subject: lock order reversals w/ backtrace
>>> >
>>> > A few days ago I started running 11.0-CURRENT at r260971 for the first 
>>> > time.
>>>
>>>
>>> >
>>> > The last couple of times I shutdown my system I noticed 2 or 3 short "lock
>>> > order reversal" messages with accompanying backtraces scroll by. Do these
>>> > messages represent a problem that I should report or can I ignore them as
>>>
>>>
>>> > debug in nature? If I should report them, how or where do these messages
>>> > get logged? I can find no reference to them in syslog or anywhere else 
>>> > upon
>>> > my subsequent reboot.
>>> >
>>> > I also had a couple of these messages pop up the other day while
>>>
>>>
>>> > mounting/umounting USB thumb drives. I did not think anything of them at
>>> > the time as the mounts/umounts completed successfully.
>>> >
>>> > Please advise. Thanks.
>>> >
>>> > -Tom
>>>
>>>  I managed to snap a photo of my screen during shutdown.
>> Here is the full text of the first of two lock order reversals I got last
>> night during system shutdown, both of which are zfs-related to (it
>> appears?) unmounts. A few lines got chopped as they were out-of-frame when
>> I took the photo:
>>
>> shutting down local daemons:
>> lock order reversal:
>>   1st 0xf801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237
>>   2nd 0xf801194f6420 syncer (syncer) @
>> /usr/src/sys/kern/vfs_subr.c:22[..chopped...]
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame
>> 0xfe01ac78[...chopped...]
>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01ac784650
>> witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01ac7846e0
>> __lockmgr_args() __lockmgr_args+0x878/frame 0xfe01ac784810
>> vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01ac784830
>> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01ac784860
>> _vn_lock() at _vn_lock+0xab/frame 0xfe01ac7848d0
>> vputx() at vputx+0x240/frame 0xfe01ac784930
>> dounmount at dounmount+0x327/frame 0xfe01ac7849b0
>> sys_unmount() at sys_unmount+0x356/frame 0xfe01ac784ac0
>> amd64_syscall() at amd64_syscall+0x265/frame 0xfe01ac784bf0
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01ac784bf0
>> --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a,
>> rsp[...chopped...]
>>
>> I have a zpool on an external USB HDD that I export at shutdown via
>> rc.shutdown.local. Don't know if that is contributing to this or not. When
>> I get a chance to bring down the system I will manually export it before
>> shutdown to see if that makes any difference.
>>
>
> Was able to capture the full text of the lock order reversal I've been
> experiencing at shutdown. Turns out to be associated with the export of one
> of my zpools that is hosted on an external USB HDD. Normally I export the
> zpool from rc.shutdown.local, but tonight I exported it manually before I
> shutdown and got the following.
>
> lock order reversal:
> : 1st 0xf8011952b5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237
> : 2nd 0xf8011952b068 syncer (syncer) @
> /usr/src/sys/kern/vfs_subr.c:2212
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe01add6e5a0
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01add6e650
> witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01add6e6e0
> __lockmgr_args() at __lockmgr_args+0x878/frame 0xfe01add6e810
> vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01add6e830
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01add

Re: Problem updating bootcode on ZFS on root system with MBR

[Thomas Hoffmann]

On Sun, Jan 26, 2014 at 3:46 AM, Scot Hetzel  wrote:

> On Tue, Jan 21, 2014 at 3:11 PM, Thomas Hoffmann  wrote:
> > On Tue, Jan 21, 2014 at 10:47 AM, Andriy Gapon  wrote:
> >
> >> on 21/01/2014 13:18 Andrey V. Elsukov said the following:
> >> > On 21.01.2014 14:45, Andriy Gapon wrote:
> >> >>>> What do I need to do to get the boot2 code written to /dev/ada0s1a?
> >> >>>
>
> >> >>>> # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024
> >> >>>> dd: /dev/ada0s1a: Operation not permitted
>
> > Thanks for the responses. My apologies for going silent, but I had to
> step
> > away from the problem for a bit. I was able to resolve my problem by
> doing
> > the following:
> >
> > After upgrading my zpools and after my aborted attempt to update the
> > bootcode as reported above, I copied /boot/zfsboot (or more precisely
> > /bootpool/boot/zfsboot) to a USB thumb drive. I attempted to reboot my
> > system, which failed due to unsupported zfs features. This was expected,
> > but I thought, hey, I might get lucky. I then booted into a Live CD,
> > mounted my USB thumb drive on /tmp/usb and executed:
> >
> > sysctl kern.geom.debugflags=0x10
> > dd if=/tmp/usb/zfsboot of=/dev/ada0s1 count=1
> > dd if=/tmp/usb/zfsboot of=/dev/ada0s1d skip=1 seek=1024
> >
> > Then I rebooted and all is well. All zpools support all features. While
> > this procedure was not tedious, it would still be nice if, as Andriy
> > stated, FreeBSD contained a native way do this zfs bootcode update for
> MBR
> > schemes that is as simple as for the GPT schemes.
> >
> In your original message, you were trying to write the boot code to
> ada0s1a, but you made it work by using ada0s1d.
>
> Do you have an ada0s1a?  If you do, is it your ZFS partition or is it
> ada0s1d?
>

I can see why you are confused. In between the original problem and the
solution I did a fresh install of FreeBSD-10.0-REL, which creates a
bootpool on ada0s1a, swap on ada0s1b and the zfs partition on ada0s1d. So
that is why the discrepancy between the original problem and solution. The
original system had the zfs partition on ada0s1a and swap on ada0s1b.

In retrospect I should have been more clear on this in my postings.

BTW, I got the [definitive] update process for zfs bootcode on MBR
partitioned systems from you a while back. So thanks for that. I actually
understand what I'm doing now when I update the zfs bootcode.

-Tom

>
> --
> DISCLAIMER:
>
> No electrons were maimed while sending this message. Only slightly bruised.
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

libelf.so.1 missing after -CURRENT update

[Thomas Hoffmann]

Did my weekly update of -CURRENT today to r261350 from r261236. After the
upgrade when I tried to run 'pkg' I got the error:

libelf.so.1 required by libpkg.so.1

So, I reinstalled 'pkg', which fixed the problem. Then I ran pkg_libchk to
see if any other libs were missing and got:

glib -2.36.3_1: /usr/local/bin/gresource misses libelf.so.1

So i re-installed glib and re-ran pkg_libchk against it. No more missing
libelf.so.1.

Anyway, I'm wondering if I inadvertently deleted libelf.so.1 during the
'make delete-old' or 'make delete-old-libs' steps of the rebuild.
Unfortunately, these are the only two steps of the build process
(mergemaster excepted) that I do not 'script' the output, so I cannot go
back to see if that is the case. Obviously I need to begin "script'ing
these two steps on future builds.

Anyone else seen this or that can confirm an inadvertent delete of
libelf.so.1 on my part?

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

Re: libelf.so.1 missing after -CURRENT update

[Thomas Hoffmann]

On Sat, Feb 1, 2014 at 3:55 PM, Glen Barber  wrote:

> On Sat, Feb 01, 2014 at 03:52:32PM -0500, Thomas Hoffmann wrote:
> > Did my weekly update of -CURRENT today to r261350 from r261236. After the
> > upgrade when I tried to run 'pkg' I got the error:
> >
> > libelf.so.1 required by libpkg.so.1
> >
> > So, I reinstalled 'pkg', which fixed the problem. Then I ran pkg_libchk
> to
> > see if any other libs were missing and got:
> >
> > glib -2.36.3_1: /usr/local/bin/gresource misses libelf.so.1
> >
> > So i re-installed glib and re-ran pkg_libchk against it. No more missing
> > libelf.so.1.
> >
> > Anyway, I'm wondering if I inadvertently deleted libelf.so.1 during the
> > 'make delete-old' or 'make delete-old-libs' steps of the rebuild.
> > Unfortunately, these are the only two steps of the build process
> > (mergemaster excepted) that I do not 'script' the output, so I cannot go
> > back to see if that is the case. Obviously I need to begin "script'ing
> > these two steps on future builds.
> >
> > Anyone else seen this or that can confirm an inadvertent delete of
> > libelf.so.1 on my part?
> >
>
> r261246 updates libelf.so to version 2.
>
> Glen
>

 Okay, so I wasn't stupid, just negligent. I usually run pkg_libchk
immediately after my builds to pick up these types of changes and to know
what ports I need to rebuild. Got distracted today and did not do this
immediately.

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

Re: [PATCH] PCI bus number management

[Thomas Hoffmann]

On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin  wrote:

> I have a patch to teach the PCI bus code and PCI-PCI bridge driver to
> manage
> PCI bus numbers.  The approach is somewhat similar to how NEW_PCIB manages
> I/O
> windows for briges.  Each bridge creates an rman to manage the bus numbers
> for
> all buses and bridges that live below it.  Each bus allocates a bus
> resource
> from its parent bridge, and child bridges allocate their ranges from their
> parent devices.  At the "top" of the PCI tree, the Host-PCI bridges
> allocate
> their respective bus ranges from their PCI domain/segment.  There isn't
> really
> a device node for PCI domains, so I created a helper API that basically
> auto-
> creates a PCI bus rman for each domain on first use and then sub-allocates
> from that for Host-PCI bridges.
>
> The current patch (with some extra debugging) is at
> http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch
>
> I would like to commit this to HEAD soon but thought I would post it for
> some
> pre-commit testing for the brave. :)  If you are really brave, try booting
> with 'hw.pci.clear_buses=1' which will force the kernel to renumber all
> buses
> in the system.  If you are really, really brave, try booting with
> 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'.
>  (My
> laptop survives with all those set)
>
> Note that the patch only enables bus number management on amd64 and i386.
>  I
> believe ia64 just needs to define PCI_RES_BUS for this to work since it
> mandates ACPI.  Porting this to other platforms requires handling
> PCI_RES_BUS
> rseources for Host-PCI bridges in bus_alloc_resource(),
> bus_adjust_resource(),
> and bus_release_resource().
>
> --
> John Baldwin
>

I get a "404 - Not Found" trying to follow the link.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] PCI bus number management

[Thomas Hoffmann]

On Thu, Feb 6, 2014 at 2:47 PM, Thomas Hoffmann  wrote:

> On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin  wrote:
>
>> I have a patch to teach the PCI bus code and PCI-PCI bridge driver to
>> manage
>> PCI bus numbers.  The approach is somewhat similar to how NEW_PCIB
>> manages I/O
>> windows for briges.  Each bridge creates an rman to manage the bus
>> numbers for
>> all buses and bridges that live below it.  Each bus allocates a bus
>> resource
>> from its parent bridge, and child bridges allocate their ranges from their
>> parent devices.  At the "top" of the PCI tree, the Host-PCI bridges
>> allocate
>> their respective bus ranges from their PCI domain/segment.  There isn't
>> really
>> a device node for PCI domains, so I created a helper API that basically
>> auto-
>> creates a PCI bus rman for each domain on first use and then sub-allocates
>> from that for Host-PCI bridges.
>>
>> The current patch (with some extra debugging) is at
>> http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch
>>
>> I would like to commit this to HEAD soon but thought I would post it for
>> some
>> pre-commit testing for the brave. :)  If you are really brave, try booting
>> with 'hw.pci.clear_buses=1' which will force the kernel to renumber all
>> buses
>> in the system.  If you are really, really brave, try booting with
>> 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'.
>>  (My
>> laptop survives with all those set)
>>
>> Note that the patch only enables bus number management on amd64 and i386.
>>  I
>> believe ia64 just needs to define PCI_RES_BUS for this to work since it
>> mandates ACPI.  Porting this to other platforms requires handling
>> PCI_RES_BUS
>> rseources for Host-PCI bridges in bus_alloc_resource(),
>> bus_adjust_resource(),
>> and bus_release_resource().
>>
>> --
>> John Baldwin
>>
>
> I get a "404 - Not Found" trying to follow the link.
>

Got it by backing up one level on the link and selecting form the list.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: File not found in ftp repository

[Thomas Hoffmann]

On Sun, Mar 16, 2014 at 9:38 AM, Nilton Jose Rizzo wrote:

> root@valfenda:/home2/rizzo # wget
>
> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/xfce4/xfce4-equake-plugin-1.3.4.tar.bz2
> --2014-03-16 10:34:32--
>
> ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/xfce4/xfce4-equake-plugin-1.3.4.tar.bz2
>=> 'xfce4-equake-plugin-1.3.4.tar.bz2'
> Resolvendo ftp.freebsd.org (ftp.freebsd.org)... 204.152.184.73,
> 2001:4f8:0:2::e
> Conectando-se a ftp.freebsd.org (ftp.freebsd.org)|204.152.184.73|:21...
> conectado.
> Acessando como anonymous ... Acesso autorizado! ( Access grant)
> ==> SYST ... feito.   ==> PWD ... feito.
> ==> TYPE I ... feito. ==> CWD (1) /pub/FreeBSD/ports/distfiles/xfce4 ...
> feito.
> ==> SIZE xfce4-equake-plugin-1.3.4.tar.bz2 ... feito.
> ==> PASV ... feito.   ==> RETR xfce4-equake-plugin-1.3.4.tar.bz2 ...
> O arquivo 'xfce4-equake-plugin-1.3.4.tar.bz2' não foi encontrado. (file
> not found)
>
> this file was required by xfce4 and not found in any repository
> where can I found it?
>
>
> Rizzo


Does this get you what you need:
http://archive.xfce.org/src/panel-plugins/xfce4-equake-plugin/1.3/

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

Re: File not found in ftp repository

[Thomas Hoffmann]

On Sun, Mar 16, 2014 at 11:56 PM, Nilton Jose Rizzo wrote:

> Em Mon, 17 Mar 2014 00:03:29 -0300, Nilton Jose Rizzo escreveu
> > Em Sun, 16 Mar 2014 11:31:58 -0400, Thomas Hoffmann escreveu
> > > On Sun, Mar 16, 2014 at 9:38 AM, Nilton Jose Rizzo  >wrote:
> > >
> > > > root@valfenda:/home2/rizzo # wget
> > > >
> > > >
> > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/xfce4/xfce4-equake-
> > plugin-1.3.4.tar.bz2
> > > > --2014-03-16 10:34:32--
> > > >
> > > >
> > ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/xfce4/xfce4-equake-
> > plugin-1.3.4.tar.bz2
> > > >=> 'xfce4-equake-plugin-1.3.4.tar.bz2'
> > > > Resolvendo ftp.freebsd.org (ftp.freebsd.org)... 204.152.184.73,
> > > > 2001:4f8:0:2::e
> > > > Conectando-se a ftp.freebsd.org (ftp.freebsd.org
> )|204.152.184.73|:21...
> > > > conectado.
> > > > Acessando como anonymous ... Acesso autorizado! ( Access grant)
> > > > ==> SYST ... feito.   ==> PWD ... feito.
> > > > ==> TYPE I ... feito. ==> CWD (1) /pub/FreeBSD/ports/distfiles/xfce4
> ...
> > > > feito.
> > > > ==> SIZE xfce4-equake-plugin-1.3.4.tar.bz2 ... feito.
> > > > ==> PASV ... feito.   ==> RETR xfce4-equake-plugin-1.3.4.tar.bz2 ...
> > > > O arquivo 'xfce4-equake-plugin-1.3.4.tar.bz2' não foi encontrado.
> (file
> > > > not found)
> > > >
> > > > this file was required by xfce4 and not found in any repository
> > > > where can I found it?
> > > >
> > > >
> > > > Rizzo
> > >
> > > Does this get you what you need:
> > > http://archive.xfce.org/src/panel-plugins/xfce4-equake-plugin/1.3/
> > >
> > > -Tom
> >
> > Thankx Tom
>
>   Hey Tom, look this,
>
>
>
> root@valfenda:/usr/ports/science/xfce4-equake-plugin # make build
> deinstall
> reinstall
>   pkg-static: PACKAGESITE in pkg.conf is deprecated. Please create a
> repository configuration file
> ===>  License GPLv3 accepted by the user
> ===>   xfce4-equake-plugin-1.3.4 depends on file: /usr/local/sbin/pkg -
> found
> ===> Fetching all distfiles required by xfce4-equake-plugin-1.3.4 for
> building
> ===>  Extracting for xfce4-equake-plugin-1.3.4
> => SHA256 Checksum mismatch for xfce4/xfce4-equake-plugin-1.3.4.tar.bz2.
> ===>  Refetch for 1 more times files:
> xfce4/xfce4-equake-plugin-1.3.4.tar.bz2
> pkg-static: PACKAGESITE in pkg.conf is deprecated. Please create a
> repository
> configuration file
> ===>  License GPLv3 accepted by the user
> ===>   xfce4-equake-plugin-1.3.4 depends on file: /usr/local/sbin/pkg -
> found
> => xfce4-equake-plugin-1.3.4.tar.bz2 doesn't seem to exist in
> /usr/ports/distfiles/xfce4.
> => Attempting to fetch
>
> http://mirror.perldude.de/archive.xfce.org/src/panel-plugins/xfce4-equake-plugin/1.3/xfce4-equake-plugin-1.3.4.tar.bz2
> fetch:
>
> http://mirror.perldude.de/archive.xfce.org/src/panel-plugins/xfce4-equake-plugin/1.3/xfce4-equake-plugin-1.3.4.tar.bz2
> :
> size mismatch: expected 385454, actual 385283
>
>
> The size of file is grater than origi, and the make try to download other
> file to replace.
>
> Rizzo
>
>
> >
> > Rizzo
>

I would change the SIZE in science/xfce4-equake-plugin/distinfo to match
the size of the file you fetched (i.e., 385283) from the xfce site and see
what happens.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Newcons with Nvidia

[Thomas Hoffmann]

The newcons wiki page shows that newcons with Nvidia as UNKNOWN. That may
or may not change after this report.

I'm running -CURRENT r263278 amd64 with an Nvidia GeForce 8800M GTS using
the nv driver from x11-drivers/xorg-driver. I built/booted a newcons
kernel, applied the vidcontrol-for-vt-2014-03-11patch and "installed" the
/usr/share/vt/fonts/gallant.fnt font.

With syscons, I would start with an 80x24 text console for the boot and
then switch to a 1920x1200 (240x75 - 8x16) virtual terminal once
allscreens_flags got processed in /etc/rc.conf. With newcons, there were
four changes of note:

1) a new console font (gallant maybe?) for the 80x24 text console;
2) no mode switch to 1920x1200 with allscreens_flags. The message
"vidcontrol: Setting video mode: inappropriate ioctl for device" was
written to the console/terminal, ostensibly when it tried to process
allscreens_flags.
3) The message "Configuring syscons: blanktimevt4_mode = 1;
allscreensvt4_mode = 1" was written to the console around the time (I
think)  /etc/rc.conf was being processed. Not sure what these mean.
4) "vidcontrol -i mode" shows no usable modes (all show x) or fonts
(all show 0x0).

So, some questions:
1) Is what I am seeing expected given the current state of newcons
development and the Nvidia card/driver?
2) Is there a way to get back to a 1920x1200 video mode for my virtual
terminals with newcons? Or even get it early in the boot process?
3) Are there any tests I can run that would be of value to the newcons team
-OR-
4) Should I just take my newcons kernel and Nvidia card and go away :)))

I'll admit I spend so little time using virtual terminals I almost don't
care what mode newcons gives me. As long as X gives me 1920x1200, and it
still does, I'll be happy.

Thanks for all your efforts on newcons.

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

r264391 breaks buildworld for -CURRENT amd64

[Thomas Hoffmann]

Reference:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=9766061+0+current/svn-src-head


An attempt to make buildworld on -CURRENT amd64 at r264394 failed with the
following error:

===> lib/liby (depend)
--- sys.depend__D ---
make[6]: make[6]: don't know how to make reloc.c. Stop

make[6]: stopped in /usr/src/sys/boot/amd64/boot1.efi
*** [depend] Error code 2


Reverting to r264390 resolves the issue.

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

Re: r264391 breaks buildworld for -CURRENT amd64

[Thomas Hoffmann]

On Sun, Apr 13, 2014 at 2:24 AM, Nathan Whitehorn wrote:

> Thanks for the report. It should be fixed now. Apologies for the breakage!
> -Nathan


Thanks for the fix. No apology necessary. Any bump(s) related to getting
efi boot for amd64 working in HEAD get a free pass with me!

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

make delete-old/delete-old-libs issue after r264673 build

[Thomas Hoffmann]

After building at -CURRENT amd64 r264673, I got the following errors
running 'make delete-old' and 'make delete-old-libs':

 # make delete-old
make[2]: "/usr/share/mk/bsd.opts.mk" line 239: Could not find bsd.mkopt.mk
make[2]: "/usr/share/mk/bsd.opts.mk" line 262: Malformed conditional
(${MK_LIBPTHREAD} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 266: Malformed conditional
(${MK_LDNS} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 271: Malformed conditional
(${MK_SOURCELESS} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 276: Malformed conditional
(${MK_CDDL} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 281: Malformed conditional
(${MK_CRYPT} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 287: Malformed conditional
(${MK_CXX} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 292: Malformed conditional
(${MK_MAIL} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 298: Malformed conditional
(${MK_NETGRAPH} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 303: Malformed conditional
(${MK_OPENSSL} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 308: Malformed conditional
(${MK_PF} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 312: Malformed conditional
(${MK_TEXTPROC} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 316: Malformed conditional
(${MK_CROSS_COMPILER} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 322: Malformed conditional
(${MK_TOOLCHAIN} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 329: Malformed conditional
(${MK_CLANG} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 352: Malformed conditional
(defined(WITHOUT_${:UBZIP2}_SUPPORT) || ${MK_${:UBZIP2}} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 352: Malformed conditional
(defined(WITHOUT_${:UGNU}_SUPPORT) || ${MK_${:UGNU}} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 352: Malformed conditional
(defined(WITHOUT_${:UINET}_SUPPORT) || ${MK_${:UINET}} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 352: Malformed conditional
(defined(WITHOUT_${:UINET6}_SUPPORT) || ${MK_${:UINET6}} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 352: Malformed conditional
(defined(WITHOUT_${:UKERBEROS}_SUPPORT) || ${MK_${:UKERBEROS}} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 352: Malformed conditional
(defined(WITHOUT_${:UKVM}_SUPPORT) || ${MK_${:UKVM}} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 352: Malformed conditional
(defined(WITHOUT_${:UNETGRAPH}_SUPPORT) || ${MK_${:UNETGRAPH}} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 352: Malformed conditional
(defined(WITHOUT_${:UPAM}_SUPPORT) || ${MK_${:UPAM}} == "no")
make[2]: "/usr/share/mk/bsd.opts.mk" line 352: Malformed conditional
(defined(WITHOUT_${:UWIRELESS}_SUPPORT) || ${MK_${:UWIRELESS}} == "no")
make[2]: "/usr/share/mk/bsd.own.mk" line 129: Malformed conditional
(${MK_CTF} != "no")
make[2]: "/usr/share/mk/bsd.own.mk" line 137: Malformed conditional
(${MK_INSTALL_AS_USER} != "no")
make[2]: Fatal errors encountered -- cannot continuemake[1]:
"/usr/src/Makefile.inc1" line 135: warning: "make -C /usr/src/release -V
REVISION" returned non-zero status
make[2]: "/usr/share/mk/bsd.opts.mk" line 239: Could not find bsd.mkopt.mk

Maybe r26466{1|2|3|4} could be the source?

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

Re: make delete-old/delete-old-libs issue after r264673 build

[Thomas Hoffmann]

On Sat, Apr 19, 2014 at 1:05 AM, Jung-uk Kim  wrote:

> On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote:
> > After building at -CURRENT amd64 r264673, I got the following
> > errors running 'make delete-old' and 'make delete-old-libs':
> ...
>
> This should be fixed in r264674.
>
> Jung-uk Kim
>

With r264674, I no longer see those errors reported at delete-old or
delete-old-libs, however, I now see those errors reported at the beginning
of buildworld, buildkernel, installkernel, and installworld.

With r264673 I only saw the errors at delete-old and delete-old-libs.

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

Re: make delete-old/delete-old-libs issue after r264673 build

[Thomas Hoffmann]

On Sat, Apr 19, 2014 at 2:27 AM, Jung-uk Kim  wrote:

> On 2014-04-19 02:14:58 -0400, Thomas Hoffmann wrote:
> > On Sat, Apr 19, 2014 at 1:05 AM, Jung-uk Kim  > <mailto:j...@freebsd.org>> wrote:
> >
> >     On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote:
> > > After building at -CURRENT amd64 r264673, I got the following
> > > errors running 'make delete-old' and 'make delete-old-libs':
> > ...
> >
> > This should be fixed in r264674.
> >
> > Jung-uk Kim
> >
> >
> > With r264674, I no longer see those errors reported at delete-old or
> > delete-old-libs, however, I now see those errors reported at the
> > beginning of buildworld, buildkernel, installkernel, and installworld.
> >
> > With r264673 I only saw the errors at delete-old and delete-old-libs.
>
> I can't reproduce it.  Do you have the bsd.mkopt.mk in /usr/share/mk,
> i.e., did you do installworld?
>
> Jung-uk Kim
>

Had I taken a bit more time to think on it before my last post, I would
have realized that what I was seeing is exactly what I should have
expected. In order to reproduce my problem, you would have had to build at
r264673 and then again at r264674.

When I built at r264673, I was using the last good *.mk installed from
r264633. That is why I did not see the errors for buildworld, buildkernel,
installkernel and installworld. But, since installworld at r264673
installed the bad *.mk, that is why I saw the errors for the subsequent
delete-old and delete-old-libs.

When I re-built at r264674, I was still using the bad *.mk installed from
r264673. That is why I saw the errors for buildworld, buildkernel,
installkernel and installworld. But, since installworld at r264674
installed the good (i.e., fixed) *.mk, that is why I no longer saw the
errors for the subsequent delete-old and delete-old-libs.

My apologies for not realizing this earlier.

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

Re: make delete-old/delete-old-libs issue after r264673 build

[Thomas Hoffmann]

On Sat, Apr 19, 2014 at 9:29 PM, Warner Losh  wrote:

>
> bad mk files?
>

jkim@ resolved this for me w/ r264674.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS bug or feature

[Thomas Hoffmann]

In /boot/loader.conf:
kern.geom.label.disk_ident.enable=0

will disable the use of disk ids.

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

delete-old issue with src.opts.mk

[Thomas Hoffmann]

The other night I built a new -CURRENT at r265728. At delete-old it asked
me if I wanted to "remove /usr/share/mk/src.opts.mk?" I said yes.
Subsequently an upgrade attempt for virtualbox-ose-4.3.10_1 failed with a
"missing src.opts.mk " error.

Last night I built a new -CURRENT at 265793. At delete-old it asked me if I
wanted to "remove /usr/share/mk/src.opts.mk?"again. I said no. Subsequently
an upgrade for virtualbox-ose-4.3.10_1 succeded.

Three questions:
1. Why is delete-old repeatedly asking me if I want to remove /usr/share/mk/
src.opts.mk?
2. Why is delete-old asking me if I want to remove something that is
required to build ports, well at least one port? I did not try to build any
other ports, so maybe it was just a virtualbox-ose issue?
3. Should I keep src.opts.mk at delete-old or remove it?

I saw some discussion about src.opts.mk, but it centered around the use of
WITHOUT_NIS, which is not my issue.

Thanks.

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

Re: delete-old issue with src.opts.mk

[Thomas Hoffmann]

On Sat, May 10, 2014 at 3:54 PM, Warner Losh  wrote:

>
> On May 10, 2014, at 9:45 AM, Thomas Hoffmann  wrote:
>
> > The other night I built a new -CURRENT at r265728. At delete-old it asked
> > me if I wanted to "remove /usr/share/mk/src.opts.mk?" I said yes.
> > Subsequently an upgrade attempt for virtualbox-ose-4.3.10_1 failed with a
> > "missing src.opts.mk <http://src.opt.mk>" error.
>
> I’ve fixed that.
>
> > Last night I built a new -CURRENT at 265793. At delete-old it asked me
> if I
> > wanted to "remove /usr/share/mk/src.opts.mk?"again. I said no.
> Subsequently
> > an upgrade for virtualbox-ose-4.3.10_1 succeded.
>
> You should say yes.
>
> > Three questions:
> > 1. Why is delete-old repeatedly asking me if I want to remove
> /usr/share/mk/
> > src.opts.mk?
>
> It seems to keep getting installed. It shouldn’t be now that I’ve got
> things ironed out.
>
> > 2. Why is delete-old asking me if I want to remove something that is
> > required to build ports, well at least one port? I did not try to build
> any
> > other ports, so maybe it was just a virtualbox-ose issue?
>
> It isn’t required to build ports. Well, it was for a couple of days due to
> a bug, but I’ve fixed that bug.
>
> > 3. Should I keep src.opts.mk at delete-old or remove it?
>
> Remove it. It should ask you at most one more time.
>
> > I saw some discussion about src.opts.mk, but it centered around the use
> of
> > WITHOUT_NIS, which is not my issue.
>
> Yea. I understand. The WITHOUT_NIS was a different, and subtle, bug that I
> fixed as well.
>
> My advise: update to the tip of head, buildworld, install world,
> delete-old (making sure you say ‘yes’) and then try virtualbox-ose build
> again. It should just work. If it doesn’t then send in a bug report since I
> missed something when I fixed nvidia and cuse builds.
>
> Thanks for the report. I hope I can get this all ironed out for you. I
> think I have already, but the build system is rather fragile, I’m coming to
> discover, and used in several non-obvious use cases that seem obvious after
> the bug report comes in… Sorry these slipped through the cracks in my
> testing...
>
> Warner


Thanks for the response. I'll follow your advice above when I build
-CURRENT again tonight. No apology necessary. I build a new -CURRENT nearly
every night and expect to run into a glitch every now and again.

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

Re: Makefile Problem of FreeBSD-Current

[Thomas Hoffmann]

On Sun, May 11, 2014 at 9:39 AM, Sean Bruno  wrote:

> On Sun, 2014-05-11 at 20:49 +0800, bycn82 wrote:
> > As you can see below . it still did not find the src.opts.mk
> >
> >
> > root@FB10Head:/usr/src/sbin/ipfw # make
> > make: "/usr/src/sbin/ipfw/Makefile" line 3: Could not find src.opts.mk
> > make: "/usr/src/sbin/ipfw/Makefile" line 9: Malformed conditional
> > (${MK_PF} != "no")
> > make: "/usr/src/sbin/ipfw/../Makefile.inc" line 4: Could not find
> > src.opts.mk
> > make: "/usr/src/sbin/ipfw/../Makefile.inc" line 9: Malformed conditional
> > (${MK_DYNAMICROOT} == "no")
> > make: Fatal errors encountered -- cannot continue
> > make: stopped in /usr/src/sbin/ipfw
> > root@FB10Head:/usr/src/sbin/ipfw # uname -a
> > FreeBSD FB10Head 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265868: Sun May
> > 11 11:44:35 UTC 2014 root@FB10Head:/usr/obj/usr/src/sys/GENERIC
>  amd64
> > ___
> > freebsd-current@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
>
>
> I suspect you are seeing the same issue as described in the thread
> "delete-old issue with src.opts.mk" on -current.
>

I successfully built -CURRENT 265866 last night and did not run into this
problem. However, I ran -DNO_CLEAN and had no need to rebuild ipfw from my
previous build(s). If I now go into the /usr/src/sbin/ipfw directory and
simply do a 'make', I can duplicate this error.

The /usr/src/sbin/ipfw/Makefile includes an .include for src.opts.mk:

# $FreeBSD: head/sbin/ipfw/Makefile 265420 2014-05-06 04:22:01Z imp $

.include 

PROG= ipfw
SRCS= ipfw2.c dummynet.c ipv6.c main.c nat.c
WARNS?= 2
...

Maybe it should not?

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

Re: Makefile Problem of FreeBSD-Current

[Thomas Hoffmann]

On Sun, May 11, 2014 at 11:14 AM, Warner Losh  wrote:

>
> From UPDATING:
>
> 20140505:
> /etc/src.conf now affects only builds of the FreeBSD src tree. In
> the
> past, it affected all builds that used the bsd.*.mk files. The old
> behavior was a bug, but people may have relied upon it. To get this
> behavior back, you can .include /etc/src.conf from /etc/make.conf
> (which is still global and isn't changed). This also changes the
> behavior of incremental builds inside the tree of individual
> directories. Set MAKESYSPATH to ".../share/mk" to do that.
> Although this has survived make universe and some upgrade
> scenarios,
> other upgrade scenarios may have broken. At least one form of
> temporary breakage was fixed with MAKESYSPATH settings for
> buildworld
> as well...
>
> Since you are building inside the tree, did you set MAKESYSPATH as
> outlined in UPDATING?


Thanks for this clarification. Setting MAKESYSPATH resolves the issue. I am
indeed guilty of _not_ regularly checking /usr/src/UPDATING. My bad.

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