date:20160124

Re: Multicast routing on FreeBSD 11 current

2016-01-24 Thread Otacílio


Em 24/01/2016 07:24, Olivier Cochard-Labbé escreveu:

On Sun, Jan 24, 2016 at 9:41 AM, Ben Woods  wrote:


Hi everyone,

Could someone running FreeBSD current on a test machine try loading the
ip_mroute driver on their machine?


Hi,

no problem here:

root@lame5 # uname -a
FreeBSD lame5.bsdrp.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294522: Thu
Jan 21 20:07:04 CET 2016
r...@lame5.bsdrp.net:/usr/obj/usr/src/sys/GENERIC-NODEBUG
  amd64
root@lame5 # kldload ip_mroute
root@lame5

# kldstat -m ip_mroute
Id  Refs Name
4971 ip_mroute


Regards,

Olivier



No problem here also.

root@nostromo:~ # kldload ip_mroute
root@nostromo:~ # kldstat
Id Refs AddressSize Name
 1   34 0x8020 1e39ca8  kernel
 21 0x8203b000 e3b8 cuse.ko
 31 0x8204a000 3d90 pty.ko
 41 0x82221000 57b8 fdescfs.ko
 51 0x82227000 a3ac linprocfs.ko
 61 0x82232000 695a linux_common.ko
 71 0x82239000 26f8avboxguest.ko
 81 0x8226 7a9  vboxvideo.ko
 91 0x82261000 52092drm2.ko
101 0x822b4000 2679 iicbus.ko
111 0x822b7000 1f6a imgact_binmisc.ko
121 0x822b9000 657f nullfs.ko
131 0x822c abe8 tmpfs.ko
141 0x822cb000 ceff ip_mroute.ko
root@nostromo:~ # uname -a
FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294319M: Tue Jan 
19 20:29:21 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/GENERIC  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: Multicast routing on FreeBSD 11 current

2016-01-24 Thread Ben Woods

On Saturday, 23 January 2016, Ben Woods  wrote:
>
> I am running the GENERIC kernel, except with VIMAGE enabled and SCTP
> disabled.
>
> When I try to load the kernel module, I am getting an error:
> % sudo kldload -v ip_mroute
> kldload: an error occurred while loading the module. Please check dmesg(8)
> for more details.
> % dmesg
> linker_load_file: Unsupported file type
>
> Any ideas what could be causing this error?
>
> Thanks for your help.
>
> Regards,
> Ben
>
> --
> From: Benjamin Woods
> woods...@gmail.com 
>

Hi everyone,

Could someone running FreeBSD current on a test machine try loading the
ip_mroute driver on their machine?

This is to enable multicast routing, but I am wondering if it fails to load
for everyone, or it is specific to my build some how.

I am running r294463, please let me know which version you are running if
it works or doesn't work.

Regards,
Ben

-- 

--
From: Benjamin Woods
woods...@gmail.com
___
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: Multicast routing on FreeBSD 11 current

2016-01-24 Thread Olivier Cochard-Labbé

On Sun, Jan 24, 2016 at 9:41 AM, Ben Woods  wrote:

>
> Hi everyone,
>
> Could someone running FreeBSD current on a test machine try loading the
> ip_mroute driver on their machine?
>

Hi,

no problem here:

root@lame5 # uname -a
FreeBSD lame5.bsdrp.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294522: Thu
Jan 21 20:07:04 CET 2016
r...@lame5.bsdrp.net:/usr/obj/usr/src/sys/GENERIC-NODEBUG
 amd64
root@lame5 # kldload ip_mroute
root@lame5

# kldstat -m ip_mroute
Id  Refs Name
4971 ip_mroute


Regards,

Olivier
___
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: ZFSROOT UEFI boot

2016-01-24 Thread Tomoaki AOKI

Unfortunately, this (and its committed successor and original for UFS)
fails to boot in some situation, like below. OTOH, gptzfsboot (and
maybe gptboot for UFS, too) is OK.

When I select Disk1 from UEFI firmware, bootx64.efi in Disk1 EFI
partition is used and it searches /boot/loader.efi from Disk2 (in ZFS,
if none, in UFS) only.
And when I select Disk2, bootx64.efi in Disk2 EFI partition is used and
it searches /boot/loader.efi from Disk1 only.


In fact, this is a long-standing and living problem.
At past, USB memstick with head memstick.img (UEFI enabled, but
without root-on-ZFS support) booted fine, but after I added UFS2
partition in internal disk, the USB memstick didn't boot anymore.
It searches /boot/loader.efi from internal UFS and fails as it was
blank (only newfs'ed) at that time. Another USB memstick with stable/10
memstick.img is still fine, as it's still ancient BIOS based.

Possibly, it's not a fault of boot1.efi but caused by differense in
implementation of UEFI firmware. If that's it, different boot1.efi
would be needed for each implementation.

A bit more details of tests are as below. Not all combinations are
covered, but would be sufficient to determine above conclusion.


Common configurations for all tests:
  *Each disk has one EFI partition (p1), one freebsd-boot partition
   (p2), one swap partition (p3), one UFS partition (p4), and one
   ZFS pool (p5) with this order.

  *Each partition has different GEOM label.

  *In each disk, FreeBSD is installed as root on ZFS. No other OS.

  *stable/10 (r294614) is installed in Disk1.

  *head (r294567) is installed in Disk2.

  *ZFS-enabled boot1.efi (head r294567) is used as bootx64.efi.


Set 1: Boot from Disk1 (select it in UEFI firmware).
   In all tests, /boot/loader.efi in Disk1 (both UFS and ZFS)
   are NOT searched at all.

 1-1) Both UFS and ZFS has no /boot/loader.efi
-> Fail to boot. Fall back to boot1 prompt.

 1-2) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS
  is copied to UFS.
-> head in Disk2 boots fine.

 1-3) Same as 1-2, except its /boot/loader.efi is overwritten by the
  one of stable/10.
-> head in Disk2 boots fine, as loader.efi loads kernel from
   /boot/kernel/kernel in UFS and kernel with zfs.ko can mount
   root on ZFS specified by vfs.root.mountfrom.

 1-4) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS
  is copied to UFS and its /boot/loader.efi is overwritten by
  the one of head.
-> stable/10 in Disk1 ZFS boots fine.

 1-5) Disk2 ZFS only has /boot/loader.efi.
-> head in Disk2 ZFS boots fine.

 1-6) Both UFS and ZFS in Disk2 has /boot/loader.efi.
  (Mix of 1-4 and 1-5)
-> head in Disk2 ZFS boots fine.


Set 2: Boot from Disk2 (select it in UEFI firmware).
   In all tests, /boot/loader.efi in Disk2 (both UFS and ZFS)
   are NOT searched at all.

 2-1) Both UFS and ZFS has no /boot/loader.efi
-> Fail to boot. Fall back to boot1 prompt.
   ZFS pool in Disk2 is shown before one in Disk1.

 2-2) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS
  is copied to UFS.
-> head in Disk2 ZFS boots fine.

 2-3) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS
  is copied to UFS.
-> stable/10 in Disk1 ZFS boots fine, as loader.efi loads
   kernel from /boot/kernel/kernel in UFS and kernel with zfs.ko
   can mount root on ZFS specified by vfs.root.mountfrom.

 2-4) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS
  is copied to UFS and its /boot/loader.efi is overwritten by
  the one of head.
-> stable/10 in Disk1 ZFS boots fine.

 2-5) Disk1 ZFS only has /boot/loader.efi of stable/10 itself.
-> Fail to boot. Fall back to boot1 prompt.
   ZFS pool in Disk2 is shown before one in Disk1.

 2-6) Disk1 ZFS only has /boot/loader.efi of head.
-> stable/10 in Disk1 ZFS boots fine.

 2-7) Both UFS and ZFS in Disk1 has /boot/loader.efi of head.
  (Mix of 2-2 and 2-6)
-> stable/10 in Disk1 ZFS boots fine.

 2-8) UFS has /boot/loader.efi of head (head kernel copied), but ZFS
  has /boot/loader.efi of stable/10 itself. (Mix of 2-2 and 2-5)
-> Same as 2-5. Fail to boot. Fall back to boot1 prompt.
   ZFS pool in Disk2 is shown before one in Disk1.

Set 3: Disk2 is removed. (Disk1 only environment)

  3-1) ZFS only has /boot/loader.efi of head.
-> stable/10 in Disk1 ZFS boots fine.

  3-2) Same as 2-2 without Disk2.
-> Fail to boot. Fall back to loader prompt.
   (Of course. Specified root device doesn't exists.)

  3-3) Same as 2-4 without Disk2.
-> stable/10 in Disk1 ZFS boots fine.

  3-4) Both UFS and ZFS have /boot/loader.efi of head.
-> stable/10 in Disk1 ZFS boots fine.


Regards.


On Thu, 10 Dec 2015 12:41:15 +
Steven Hartland  wrote:

> Ive literally just got this

Re: HPN and None options in OpenSSH

2016-01-24 Thread Slawa Olhovchenkov

On Fri, Jan 22, 2016 at 03:31:22PM +0100, Dag-Erling Smørgrav wrote:

> The HPN and None cipher patches have been removed from FreeBSD-CURRENT.
> I intend to remove them from FreeBSD-STABLE this weekend.

Can you do some small discurs about ssh+kerberos?
I am try to use FreeBSD with $HOME over kerberoized NFS.
For kerberoized NFS gssd need to find cache file "called
/tmp/krb5cc_, where  is the effective uid for the RPC
caller" (from `man gssd`).

sshd contrary create cache file for received ticket called
/tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is
this strong security  requirement or [FreeBSD/upstream] can be patched
(or introduce option) to use /tmp/krb5cc_ as cache file for
received ticket?
___
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: HPN and None options in OpenSSH

2016-01-24 Thread Slawa Olhovchenkov

On Sun, Jan 24, 2016 at 03:50:45PM +0100, Dag-Erling Smørgrav wrote:

> Slawa Olhovchenkov  writes:
> > Can you do some small discurs about ssh+kerberos?
> > I am try to use FreeBSD with $HOME over kerberoized NFS.
> > For kerberoized NFS gssd need to find cache file "called
> > /tmp/krb5cc_, where  is the effective uid for the RPC
> > caller" (from `man gssd`).
> >
> > sshd contrary create cache file for received ticket called
> > /tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is
> > this strong security  requirement or [FreeBSD/upstream] can be patched
> > (or introduce option) to use /tmp/krb5cc_ as cache file for
> > received ticket?
> 
> I wasn't aware of that.  It should be easy to patch, but in the

Yes, I am already do ugly patch for me (2 files need to patch), but patch in
upstream preffered.

> meantime, you can try something like this in .bashrc or whatever:

Imposible. For accessing .bashrc on kerberoized NFS need correct 
/tmp/krb5cc_.

> krb5cc_uid="/tmp/krb5cc_$(id -u)"
> if [ -n "${KRB5CCNAME}" -a "${KRB5CCNAME}" != "${krb5ccuid}" ] ; then
> if mv "${KRB5CCNAME}" "${krb5ccuid}" ; then
> export KRB5CCNAME="${krb5ccuid}"
> else
> echo "Unable to rename krb5 credential cache" >&2
> fi
> fi
> unset krb5ccuid
> 
> DES
> -- 
> Dag-Erling Smørgrav - d...@des.no
___
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: HPN and None options in OpenSSH

2016-01-24 Thread Slawa Olhovchenkov

On Sun, Jan 24, 2016 at 04:21:17PM +0100, Dag-Erling Smørgrav wrote:

> Slawa Olhovchenkov  writes:
> > OK, what about tcsh, zsh, fish and scp/sftp?
> 
> I apologize for trying to help you out by suggesting a hack that works
> at least some of the time until I can get a permanent fix in.  I should
> instead have hopped in my time machine, jumped back a few years, and
> fixed the bug before it affected you.  No hard feelings?

Sorry about not clear exposition.
I think this is not hack nor permanent solution and decline
modification ssh source.

I am already have working solution (localy apllied patch at time `make
release`). 

I can show my ugly patch, but I think his partially not clear and not
all edge cases checked.

___
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: Multicast routing on FreeBSD 11 current

2016-01-24 Thread Ben Woods

On 24 January 2016 at 11:36, Otacílio  wrote:

> Em 24/01/2016 07:24, Olivier Cochard-Labbé escreveu:
>
>> On Sun, Jan 24, 2016 at 9:41 AM, Ben Woods  wrote:
>>
>> Hi everyone,
>>>
>>> Could someone running FreeBSD current on a test machine try loading the
>>> ip_mroute driver on their machine?
>>>
>>> Hi,
>>
>> no problem here:
>>
>> root@lame5 # uname -a
>> FreeBSD lame5.bsdrp.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294522: Thu
>> Jan 21 20:07:04 CET 2016
>> r...@lame5.bsdrp.net:/usr/obj/usr/src/sys/GENERIC-NODEBUG
>>   amd64
>> root@lame5 # kldload ip_mroute
>> root@lame5
>> 
>> # kldstat -m ip_mroute
>> Id  Refs Name
>> 4971 ip_mroute
>>
>>
>> Regards,
>>
>> Olivier
>>
>>
> No problem here also.
>
> root@nostromo:~ # kldload ip_mroute
> root@nostromo:~ # kldstat
> Id Refs AddressSize Name
>  1   34 0x8020 1e39ca8  kernel
>  21 0x8203b000 e3b8 cuse.ko
>  31 0x8204a000 3d90 pty.ko
>  41 0x82221000 57b8 fdescfs.ko
>  51 0x82227000 a3ac linprocfs.ko
>  61 0x82232000 695a linux_common.ko
>  71 0x82239000 26f8avboxguest.ko
>  81 0x8226 7a9  vboxvideo.ko
>  91 0x82261000 52092drm2.ko
> 101 0x822b4000 2679 iicbus.ko
> 111 0x822b7000 1f6a imgact_binmisc.ko
> 121 0x822b9000 657f nullfs.ko
> 131 0x822c abe8 tmpfs.ko
> 141 0x822cb000 ceff ip_mroute.ko
> root@nostromo:~ # uname -a
> FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294319M: Tue Jan 19
> 20:29:21 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/GENERIC  amd64
>


Thanks for your feedback everyone. Having spent some time now
investigating, I have confirmed that this problem is related to VIMAGE.

With VIMAGE enabled in the kernel, loading the ip_mroute kernel module will
fail.

With VIMAGE disabled on the same kernel source (no other changes), loading
the ip_mroute kernel module works fine.

I have submitted this bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206583

Regards,
Ben

--
From: Benjamin Woods
woods...@gmail.com
___
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: ZFSROOT UEFI boot

2016-01-24 Thread Allan Jude

On 2016-01-24 07:53, Tomoaki AOKI wrote:
> Unfortunately, this (and its committed successor and original for UFS)
> fails to boot in some situation, like below. OTOH, gptzfsboot (and
> maybe gptboot for UFS, too) is OK.
> 
> When I select Disk1 from UEFI firmware, bootx64.efi in Disk1 EFI
> partition is used and it searches /boot/loader.efi from Disk2 (in ZFS,
> if none, in UFS) only.
> And when I select Disk2, bootx64.efi in Disk2 EFI partition is used and
> it searches /boot/loader.efi from Disk1 only.
> 
> 
> In fact, this is a long-standing and living problem.
> At past, USB memstick with head memstick.img (UEFI enabled, but
> without root-on-ZFS support) booted fine, but after I added UFS2
> partition in internal disk, the USB memstick didn't boot anymore.
> It searches /boot/loader.efi from internal UFS and fails as it was
> blank (only newfs'ed) at that time. Another USB memstick with stable/10
> memstick.img is still fine, as it's still ancient BIOS based.
> 

In the past I have seen this same behaviour when testing UEFI.
I booted from the memstick, and installed the OS. I then used the 'boot
select menu', and selected the hard drive, and it booted the system from
the USB memstick. If I rebooted and selected the memstick, it booted
from the hard drive.

It seemed that altering the intended boot drive always caused the
opposite of the desired behaviour.

> Possibly, it's not a fault of boot1.efi but caused by differense in
> implementation of UEFI firmware. If that's it, different boot1.efi
> would be needed for each implementation.
> 
> A bit more details of tests are as below. Not all combinations are
> covered, but would be sufficient to determine above conclusion.
> 
> 
> Common configurations for all tests:
>   *Each disk has one EFI partition (p1), one freebsd-boot partition
>(p2), one swap partition (p3), one UFS partition (p4), and one
>ZFS pool (p5) with this order.
> 
>   *Each partition has different GEOM label.
> 
>   *In each disk, FreeBSD is installed as root on ZFS. No other OS.
> 
>   *stable/10 (r294614) is installed in Disk1.
> 
>   *head (r294567) is installed in Disk2.
> 
>   *ZFS-enabled boot1.efi (head r294567) is used as bootx64.efi.
> 
> 
> Set 1: Boot from Disk1 (select it in UEFI firmware).
>In all tests, /boot/loader.efi in Disk1 (both UFS and ZFS)
>are NOT searched at all.
> 
>  1-1) Both UFS and ZFS has no /boot/loader.efi
> -> Fail to boot. Fall back to boot1 prompt.
> 
>  1-2) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS
>   is copied to UFS.
> -> head in Disk2 boots fine.
> 
>  1-3) Same as 1-2, except its /boot/loader.efi is overwritten by the
>   one of stable/10.
> -> head in Disk2 boots fine, as loader.efi loads kernel from
>/boot/kernel/kernel in UFS and kernel with zfs.ko can mount
>root on ZFS specified by vfs.root.mountfrom.
> 
>  1-4) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS
>   is copied to UFS and its /boot/loader.efi is overwritten by
>   the one of head.
> -> stable/10 in Disk1 ZFS boots fine.
> 
>  1-5) Disk2 ZFS only has /boot/loader.efi.
> -> head in Disk2 ZFS boots fine.
> 
>  1-6) Both UFS and ZFS in Disk2 has /boot/loader.efi.
>   (Mix of 1-4 and 1-5)
> -> head in Disk2 ZFS boots fine.
> 
> 
> Set 2: Boot from Disk2 (select it in UEFI firmware).
>In all tests, /boot/loader.efi in Disk2 (both UFS and ZFS)
>are NOT searched at all.
> 
>  2-1) Both UFS and ZFS has no /boot/loader.efi
> -> Fail to boot. Fall back to boot1 prompt.
>ZFS pool in Disk2 is shown before one in Disk1.
> 
>  2-2) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS
>   is copied to UFS.
> -> head in Disk2 ZFS boots fine.
> 
>  2-3) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS
>   is copied to UFS.
> -> stable/10 in Disk1 ZFS boots fine, as loader.efi loads
>kernel from /boot/kernel/kernel in UFS and kernel with zfs.ko
>can mount root on ZFS specified by vfs.root.mountfrom.
> 
>  2-4) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS
>   is copied to UFS and its /boot/loader.efi is overwritten by
>   the one of head.
> -> stable/10 in Disk1 ZFS boots fine.
> 
>  2-5) Disk1 ZFS only has /boot/loader.efi of stable/10 itself.
> -> Fail to boot. Fall back to boot1 prompt.
>ZFS pool in Disk2 is shown before one in Disk1.
> 
>  2-6) Disk1 ZFS only has /boot/loader.efi of head.
> -> stable/10 in Disk1 ZFS boots fine.
> 
>  2-7) Both UFS and ZFS in Disk1 has /boot/loader.efi of head.
>   (Mix of 2-2 and 2-6)
> -> stable/10 in Disk1 ZFS boots fine.
> 
>  2-8) UFS has /boot/loader.efi of head (head kernel copied), but ZFS
>   has /boot/loader.efi of stable/10 itself. (Mix of 2-2 and 2-5)
> -> Same as 2-5. Fail to boot. Fall back to boot1 prompt.
>

Re: HPN and None options in OpenSSH

2016-01-24 Thread Dag-Erling Smørgrav

Slawa Olhovchenkov  writes:
> Can you do some small discurs about ssh+kerberos?
> I am try to use FreeBSD with $HOME over kerberoized NFS.
> For kerberoized NFS gssd need to find cache file "called
> /tmp/krb5cc_, where  is the effective uid for the RPC
> caller" (from `man gssd`).
>
> sshd contrary create cache file for received ticket called
> /tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is
> this strong security  requirement or [FreeBSD/upstream] can be patched
> (or introduce option) to use /tmp/krb5cc_ as cache file for
> received ticket?

I wasn't aware of that.  It should be easy to patch, but in the
meantime, you can try something like this in .bashrc or whatever:

krb5cc_uid="/tmp/krb5cc_$(id -u)"
if [ -n "${KRB5CCNAME}" -a "${KRB5CCNAME}" != "${krb5ccuid}" ] ; then
if mv "${KRB5CCNAME}" "${krb5ccuid}" ; then
export KRB5CCNAME="${krb5ccuid}"
else
echo "Unable to rename krb5 credential cache" >&2
fi
fi
unset krb5ccuid

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: HPN and None options in OpenSSH

2016-01-24 Thread Dag-Erling Smørgrav

Slawa Olhovchenkov  writes:
> Dag-Erling Smørgrav  writes:
> > In the meantime, you can try something like this in .bashrc or
> > whatever:
> Imposible. For accessing .bashrc on kerberoized NFS need correct
> /tmp/krb5cc_.

/etc/profile, then.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: HPN and None options in OpenSSH

2016-01-24 Thread Slawa Olhovchenkov

On Sun, Jan 24, 2016 at 04:09:05PM +0100, Dag-Erling Smørgrav wrote:

> Slawa Olhovchenkov  writes:
> > Dag-Erling Smørgrav  writes:
> > > In the meantime, you can try something like this in .bashrc or
> > > whatever:
> > Imposible. For accessing .bashrc on kerberoized NFS need correct
> > /tmp/krb5cc_.
> 
> /etc/profile, then.

OK, what about tcsh, zsh, fish and scp/sftp?
___
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: HPN and None options in OpenSSH

2016-01-24 Thread Dag-Erling Smørgrav

Slawa Olhovchenkov  writes:
> OK, what about tcsh, zsh, fish and scp/sftp?

I apologize for trying to help you out by suggesting a hack that works
at least some of the time until I can get a permanent fix in.  I should
instead have hopped in my time machine, jumped back a few years, and
fixed the bug before it affected you.  No hard feelings?

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: ZFSROOT UEFI boot

2016-01-24 Thread Steven Hartland


On 24/01/2016 12:53, Tomoaki AOKI wrote:

Unfortunately, this (and its committed successor and original for UFS)
fails to boot in some situation, like below. OTOH, gptzfsboot (and
maybe gptboot for UFS, too) is OK.

When I select Disk1 from UEFI firmware, bootx64.efi in Disk1 EFI
partition is used and it searches /boot/loader.efi from Disk2 (in ZFS,
if none, in UFS) only.
And when I select Disk2, bootx64.efi in Disk2 EFI partition is used and
it searches /boot/loader.efi from Disk1 only.


In fact, this is a long-standing and living problem.
At past, USB memstick with head memstick.img (UEFI enabled, but
without root-on-ZFS support) booted fine, but after I added UFS2
partition in internal disk, the USB memstick didn't boot anymore.
It searches /boot/loader.efi from internal UFS and fails as it was
blank (only newfs'ed) at that time. Another USB memstick with stable/10
memstick.img is still fine, as it's still ancient BIOS based.

Possibly, it's not a fault of boot1.efi but caused by differense in
implementation of UEFI firmware. If that's it, different boot1.efi
would be needed for each implementation.

A bit more details of tests are as below. Not all combinations are
covered, but would be sufficient to determine above conclusion.


Common configurations for all tests:
   *Each disk has one EFI partition (p1), one freebsd-boot partition
(p2), one swap partition (p3), one UFS partition (p4), and one
ZFS pool (p5) with this order.

   *Each partition has different GEOM label.

   *In each disk, FreeBSD is installed as root on ZFS. No other OS.

   *stable/10 (r294614) is installed in Disk1.

   *head (r294567) is installed in Disk2.

   *ZFS-enabled boot1.efi (head r294567) is used as bootx64.efi.


Set 1: Boot from Disk1 (select it in UEFI firmware).
In all tests, /boot/loader.efi in Disk1 (both UFS and ZFS)
are NOT searched at all.

Could you clarify what you mean by this?

When looking performing the scan boot1 uses the following coding:
* "+" = partition probe success (potential boot partition)
* "." = partition probe unsupported (valid partition not detected)
* "x" = partition probe error (unexpected error)

  1-1) Both UFS and ZFS has no /boot/loader.efi
 -> Fail to boot. Fall back to boot1 prompt.

This is expected

  1-2) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS
   is copied to UFS.
 -> head in Disk2 boots fine.

What do you mean by "whole /boot of Disk2 ZFS is copied to UFS"?

  1-3) Same as 1-2, except its /boot/loader.efi is overwritten by the
   one of stable/10.
 -> head in Disk2 boots fine, as loader.efi loads kernel from
/boot/kernel/kernel in UFS and kernel with zfs.ko can mount
root on ZFS specified by vfs.root.mountfrom.

  1-4) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS
   is copied to UFS and its /boot/loader.efi is overwritten by
   the one of head.
 -> stable/10 in Disk1 ZFS boots fine.

  1-5) Disk2 ZFS only has /boot/loader.efi.
 -> head in Disk2 ZFS boots fine.

  1-6) Both UFS and ZFS in Disk2 has /boot/loader.efi.
   (Mix of 1-4 and 1-5)
 -> head in Disk2 ZFS boots fine.


Set 2: Boot from Disk2 (select it in UEFI firmware).
In all tests, /boot/loader.efi in Disk2 (both UFS and ZFS)
are NOT searched at all.

  2-1) Both UFS and ZFS has no /boot/loader.efi
 -> Fail to boot. Fall back to boot1 prompt.
ZFS pool in Disk2 is shown before one in Disk1.

  2-2) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS
   is copied to UFS.
 -> head in Disk2 ZFS boots fine.

  2-3) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS
   is copied to UFS.
 -> stable/10 in Disk1 ZFS boots fine, as loader.efi loads
kernel from /boot/kernel/kernel in UFS and kernel with zfs.ko
can mount root on ZFS specified by vfs.root.mountfrom.

  2-4) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS
   is copied to UFS and its /boot/loader.efi is overwritten by
   the one of head.
 -> stable/10 in Disk1 ZFS boots fine.

  2-5) Disk1 ZFS only has /boot/loader.efi of stable/10 itself.
 -> Fail to boot. Fall back to boot1 prompt.
ZFS pool in Disk2 is shown before one in Disk1.

  2-6) Disk1 ZFS only has /boot/loader.efi of head.
 -> stable/10 in Disk1 ZFS boots fine.

  2-7) Both UFS and ZFS in Disk1 has /boot/loader.efi of head.
   (Mix of 2-2 and 2-6)
 -> stable/10 in Disk1 ZFS boots fine.

  2-8) UFS has /boot/loader.efi of head (head kernel copied), but ZFS
   has /boot/loader.efi of stable/10 itself. (Mix of 2-2 and 2-5)
 -> Same as 2-5. Fail to boot. Fall back to boot1 prompt.
ZFS pool in Disk2 is shown before one in Disk1.

Set 3: Disk2 is removed. (Disk1 only environment)

   3-1) ZFS only has /boot/loader.efi of head.
 -> stable/10 in Disk1 ZFS boots

Re: Multicast routing on FreeBSD 11 current

Re: Multicast routing on FreeBSD 11 current

Re: Multicast routing on FreeBSD 11 current

Re: ZFSROOT UEFI boot

Re: HPN and None options in OpenSSH

Re: HPN and None options in OpenSSH

Re: HPN and None options in OpenSSH

Re: Multicast routing on FreeBSD 11 current

Re: ZFSROOT UEFI boot

Re: HPN and None options in OpenSSH

Re: HPN and None options in OpenSSH

Re: HPN and None options in OpenSSH

Re: HPN and None options in OpenSSH

Re: ZFSROOT UEFI boot

14 matches

Site Navigation

Mail list logo

Footer information