Re: NFS and amd on older FreeBSD

[Daniel Braniss]

> On 12 Jan 2017, at 1:47 AM, Karl Young  wrote:
> 
> I inherited a lab that has a few hundred hosts running FreeBSD 7.2.
> These hosts run test scripts that access files that are stored on
> FreeBSD 6.3 host.  The 6.3 host exports a /data directory with NFS
> 
> 
> On the 7.2 hosts, I can see the exported directory:
> 
> $ showmount -e 6.3-host
> Exports list on 6.3-host
> /data  Everyone
> 
> And access it with amd
> 
> $ ls -l /net/6-3.host/data
> 
> drwxr-xr-x 5 root  wheel  512 Jun  4  2009 git
> drwxr-xr-x  4586 root  wheel83968 Nov  2 04:50 home
> 
> I'm trying to retire the 6.3 host and replace it with 9.3 (I know it's
> old, but it's the best I can do for now).
> 
> I export the /data directory on the 9.3 system, and I can see it on my
> 7.2 hosts.
> 
> $ showmount -e  9.3-host
> Exports list on 9.3-host:
> /data   Everyone
> 
> But I can't automount it:
> 
> $ ls -l /net/9.3-host/data
> ls: /net/9.3-host/data: No such file or directory
> 
> If I manually mount the exported directory, it works:
> 
> $ sudo mount -t nfs 9.3-host:/data /mnt/data/
> $ mount | grep nfs
> 9.3-host:/data on /mnt/data (nfs)
> 
> $ ls -l /mnt/data
> total 4
> drwxr-xr-x  9 root  wheel  512 Dec 20 17:41 iaf2
> 
> I've spent some time on Google, but haven't found a solution.  I realize
> these are very old versions, but I'm not in a position to upgrade them
> right now.  My last resort will be to use /etc/fstab to do the NFS
> mount, but I'd rather avoid that if I can.
> 
> Thanks for any pointers on how to resolve this.
> 
> -karl
> 
> 

if you changed the export file on the server after you tried to mount in on the 
client,
and will not realise this, if that’s the case, usually rebooting the client 
helps.

my .5 cents

danny

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

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

Re: 10.3-RELEASE-p13 "unsupported file layout"

[Kevin Oberman]

On Wed, Jan 11, 2017 at 8:24 PM, George Mitchell 
wrote:

> On 01/11/17 17:46, George Mitchell wrote:
> > On 01/11/17 17:20, Kevin Oberman wrote:
> >> [...]
> >>
> >> While I have no suggestions about the error building libc, your
> statement
> >> that you can't use freebsd-update due to your use of a custom kernel is
> >> incorrect. This is a common misconception and, in cases of very limited
> >> disk space, may be true, it is rare. It is helped by the fact that the
> man
> >> page makes no mention of how to so this. (You do still need to build a
> new
> >> kernel if the update does, indeed, touch the kernel.)
> >>
> >> All you need is a GENERIC kernel in /boot/GENERIC. You can either build
> it
> >> or download it. See the FreeBSD Handbook Section 23.2.3.1, “Custom
> Kernels
> >> with FreeBSD 9.X and Later”
> >>  handbook/updating-upgrading-freebsdupdate.html#freebsd-
> update-custom-kernel-9x>
> >> for details on downloading a GENERIC kernel. Before any upgrade, major
> or
> >> minor, you might wat to re-reas that section.
> >>
> >> Once the GENERIC kernel is in /boot, you may use freebsd-update and, if
> the
> >> GENERIC kernel is not updated, you're good to go. If it is, you will
> need
> >> to build and install a new custom kernel and reboot. Since most security
> >> patches don't touch the kernel, this is usually not needed. I believe
> that
> >> the 10.3 kernel was last touched in p11.
> >> --
> >> Kevin Oberman, Part time kid herder and retired Network Engineer
> >> E-mail: rkober...@gmail.com
> >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >> ___
> >> freebsd-stable@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@
> freebsd.org"
> >>
> > Thanks, I'll try that the next time I have a chance.  When I naively
> > tried a straight "freebsd-update" a few months ago, of course it
> > overwrote my SCHED_4BSD kernel with a SCHED_ULE one.-- George
> >
> Just to refresh my memory of what happened a few months ago, I tried
> the following experiment.  I copied my current modified kernel:
>
> rsync -av /boot/kernel/ /boot/my.kernel/
>
> Then with my modified kernel still in place, I said:
>
> freebsd-update fetch
> freebsd-update install
>
> With not a qualm in the world, freebsd-update installed a fresh
> SCHED_ULE kernel in /boot.  (Happily, it did save my current kernel
> in /boot/kernel.old.)  That's what happened last year, too.  Why
> didn't freebsd-update notice that I had a modified kernel and at
> least notify me that something funky was going on?  -- George


I'm a bit surprised that there was no message about the kernel being
non-GENERIC, but I've never tried. The key is the presence of
/boot/GENERIC. If it is present, the kernel in /boot/kernel is left
untouched and /boot/GENERIC is updated to the new version. If /boot/GENERIC
does not exist, then the update is performed on /boot/kernel/kernel. (N.B.
Kernel modules are always updated when or if needed!)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 17:46, George Mitchell wrote:
> On 01/11/17 17:20, Kevin Oberman wrote:
>> [...]
>>
>> While I have no suggestions about the error building libc, your statement
>> that you can't use freebsd-update due to your use of a custom kernel is
>> incorrect. This is a common misconception and, in cases of very limited
>> disk space, may be true, it is rare. It is helped by the fact that the man
>> page makes no mention of how to so this. (You do still need to build a new
>> kernel if the update does, indeed, touch the kernel.)
>>
>> All you need is a GENERIC kernel in /boot/GENERIC. You can either build it
>> or download it. See the FreeBSD Handbook Section 23.2.3.1, “Custom Kernels
>> with FreeBSD 9.X and Later”
>> 
>> for details on downloading a GENERIC kernel. Before any upgrade, major or
>> minor, you might wat to re-reas that section.
>>
>> Once the GENERIC kernel is in /boot, you may use freebsd-update and, if the
>> GENERIC kernel is not updated, you're good to go. If it is, you will need
>> to build and install a new custom kernel and reboot. Since most security
>> patches don't touch the kernel, this is usually not needed. I believe that
>> the 10.3 kernel was last touched in p11.
>> --
>> Kevin Oberman, Part time kid herder and retired Network Engineer
>> E-mail: rkober...@gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>> ___
>> freebsd-stable@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>>
> Thanks, I'll try that the next time I have a chance.  When I naively
> tried a straight "freebsd-update" a few months ago, of course it
> overwrote my SCHED_4BSD kernel with a SCHED_ULE one.-- George
> 
Just to refresh my memory of what happened a few months ago, I tried
the following experiment.  I copied my current modified kernel:

rsync -av /boot/kernel/ /boot/my.kernel/

Then with my modified kernel still in place, I said:

freebsd-update fetch
freebsd-update install

With not a qualm in the world, freebsd-update installed a fresh
SCHED_ULE kernel in /boot.  (Happily, it did save my current kernel
in /boot/kernel.old.)  That's what happened last year, too.  Why
didn't freebsd-update notice that I had a modified kernel and at
least notify me that something funky was going on?  -- George



signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 15:24, George Mitchell wrote:
> After today's OpenSSH security message, I did:
> 
> cd /usr
> rm -rf obj
> cd src
> svn update -r311916
> make buildworld
> 
> After a while, I got to:
> 
> building shared library libc.so.7
> cc (a very long compile line)
> ./libc.so.7: unsupported file layout
> *** Error code 1
> 
> Stop.
> make[4]: stopped in /usr/src/lib/libc
> *** Error code 1
> 
> Stop.
> make[3]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src
> 
> freebsd-version -ku
> 10.3-RELEASE-p13
> 10.3-RELEASE-p15
> 
> I am using a generic kernel, except for using SCHED_4BSD.  If it
> weren't for that, I would just use freebsd-update.
> 
> Googling suggests that my build tree is somehow mixing up 32 and 64
> bit files.  (I'm running on an amd64 machine.)  How do I get this
> cleared up? -- George
> 
For the sake of completeness, here's the complete build log that
terminated in the above error:  http://m5p.com/typescript.xz
-- George



signature.asc
Description: OpenPGP digital signature

Re: Can't boot on ZFS -- /boot/zfsloader not found

[Steven Hartland]

On 11/01/2017 22:58, Jeremie Le Hen wrote:

(Sorry I had to copy-paste this email from the archives to a new
thread, because I'm not subscribed to -stable@. Would you mind cc:ing
me next time please?)


As your not at the boot loader stage yet for keyboard enabling legacy
USB keyboard / mouse support in BIOS may help.

That worked, thanks for the tip.



If you see issues with keyboard after the kernel takes over setting
hint.ehci.0.disabled=1 may help.

If your installing 11.x then the guides boot partition size is out of
date and you should use 512K for your freebsd-boot partition.

Oh, really?  I'll update it once I'll have figure it all out.  That's
weird though because /boot/gptzfsboot is less than 90 KB.

11.x
du -h /boot/gptzfsboot
 97K/boot/gptzfsboot

12.x
du -h /boot/gptzfsboot
113K/boot/gptzfsboot

The reason I'd recommend 512k for boot is to provide room for expansion 
moving forward, as repartitioning to upgrade is a scary / hard thing to 
do. Remember it wasn't long ago when it was well under 64k and that's 
what was recommend, its not like with disk sizes these days you'll miss 
the extra 384k ;-)




For the GPT version (I've never used MBR one) what actual error do you get?

When I just start up the NUC, I get:
"""
\Can't find /boot/zfsloader

FreeBSD/x86 boot
Default: zroot:/boot/kernel/kernel
boot:
\
Can't find /boot/kernel/kernel
"""

I though it was the first stage boot loader, but it may be the second stage.
Boot to a live cd, I'd recommend mfsbsd, and make sure the boot loader 
was written to ALL boot disks correctly e.g.

if you have a mirrored pool with ada0 and ada1:
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0

If this doesn't help the output from gpart show, uname -a and zpool 
status would also be helpful.


This is all assuming standard BIOS mode and not UEFI which is done 
differently.




-jlh


On 11/01/2017 19:22, Jeremie Le Hen wrote:

Hi,

I'm in the process of transferring my home server to an Intel NUC. I've zfs
send/receive'd the whole pool to the new drive and first followed
[ZfsOnGpt] but it fails in the first stage boot loader. The USB keyboard
doesn't seem to be recognized so I can't really debug anything.

Then I tried both [ZfsInMbrSlice]
but it complains that it can't find /boot/zfsloader. Again USB keyboard
doesn't work.

Both times I've been very careful to install the bootcodes at the right
place.

1. Any idea why the USB keyboard doesn't work?
2. Any idea what can be wrong in the setups I tried? How can I debug this?

[ZfsOnGpt] https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
[ZfsInMbrSlice] https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition

-jlh
___
freebsd-stable at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"




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

NFS and amd on older FreeBSD

[Karl Young]

I inherited a lab that has a few hundred hosts running FreeBSD 7.2.
These hosts run test scripts that access files that are stored on
FreeBSD 6.3 host.  The 6.3 host exports a /data directory with NFS


On the 7.2 hosts, I can see the exported directory:

$ showmount -e 6.3-host
Exports list on 6.3-host
/data  Everyone

And access it with amd

$ ls -l /net/6-3.host/data

drwxr-xr-x 5 root  wheel  512 Jun  4  2009 git
drwxr-xr-x  4586 root  wheel83968 Nov  2 04:50 home

I'm trying to retire the 6.3 host and replace it with 9.3 (I know it's
old, but it's the best I can do for now).

I export the /data directory on the 9.3 system, and I can see it on my
7.2 hosts.

$ showmount -e  9.3-host
Exports list on 9.3-host:
/data   Everyone

But I can't automount it:

$ ls -l /net/9.3-host/data
ls: /net/9.3-host/data: No such file or directory

If I manually mount the exported directory, it works:

$ sudo mount -t nfs 9.3-host:/data /mnt/data/
$ mount | grep nfs
9.3-host:/data on /mnt/data (nfs)

$ ls -l /mnt/data
total 4
drwxr-xr-x  9 root  wheel  512 Dec 20 17:41 iaf2

I've spent some time on Google, but haven't found a solution.  I realize
these are very old versions, but I'm not in a position to upgrade them
right now.  My last resort will be to use /etc/fstab to do the NFS
mount, but I'd rather avoid that if I can.

Thanks for any pointers on how to resolve this.

-karl



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

Re: Can't boot on ZFS -- /boot/zfsloader not found

[Jeremie Le Hen]

(Sorry I had to copy-paste this email from the archives to a new
thread, because I'm not subscribed to -stable@. Would you mind cc:ing
me next time please?)

> As your not at the boot loader stage yet for keyboard enabling legacy
> USB keyboard / mouse support in BIOS may help.

That worked, thanks for the tip.


> If you see issues with keyboard after the kernel takes over setting
> hint.ehci.0.disabled=1 may help.
>
> If your installing 11.x then the guides boot partition size is out of
> date and you should use 512K for your freebsd-boot partition.

Oh, really?  I'll update it once I'll have figure it all out.  That's
weird though because /boot/gptzfsboot is less than 90 KB.


> For the GPT version (I've never used MBR one) what actual error do you get?

When I just start up the NUC, I get:
"""
\Can't find /boot/zfsloader

FreeBSD/x86 boot
Default: zroot:/boot/kernel/kernel
boot:
\
Can't find /boot/kernel/kernel
"""

I though it was the first stage boot loader, but it may be the second stage.

-jlh

>
> On 11/01/2017 19:22, Jeremie Le Hen wrote:
> > Hi,
> >
> > I'm in the process of transferring my home server to an Intel NUC. I've zfs
> > send/receive'd the whole pool to the new drive and first followed
> > [ZfsOnGpt] but it fails in the first stage boot loader. The USB keyboard
> > doesn't seem to be recognized so I can't really debug anything.
> >
> > Then I tried both [ZfsInMbrSlice]
> > but it complains that it can't find /boot/zfsloader. Again USB keyboard
> > doesn't work.
> >
> > Both times I've been very careful to install the bootcodes at the right
> > place.
> >
> > 1. Any idea why the USB keyboard doesn't work?
> > 2. Any idea what can be wrong in the setups I tried? How can I debug this?
> >
> > [ZfsOnGpt] https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
> > [ZfsInMbrSlice] https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition
> >
> > -jlh
> > ___
> > freebsd-stable at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"


-- 
Jeremie Le Hen
j...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 17:40, Dimitry Andric wrote:
> On 11 Jan 2017, at 23:35, George Mitchell  wrote:
>>
>> On 01/11/17 17:25, Dimitry Andric wrote:
>>> On 11 Jan 2017, at 21:24, George Mitchell  wrote:
> ...
 building shared library libc.so.7
 cc (a very long compile line)
 ./libc.so.7: unsupported file layout
>>>
>>> If things went correctly, the libc.so.7 file should be in
>>> /usr/obj/usr/src/lib/libc.  If so, can you post the output of:
>>>
>>> file /usr/obj/usr/src/lib/libc/libc.so.7
>>> readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
>>>
>>> -Dimitry
>>>
>> root@sullivan:/usr/src # file /usr/obj/usr/src/lib/libc/libc.so.7
>> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit LSB shared object,
>> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
>> root@sullivan:/usr/src # readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
>> ELF Header:
>>  Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00
>>  Class: ELF64
>>  Data:  2's complement, little endian
>>  Version:   1 (current)
>>  OS/ABI:UNIX - FreeBSD
>>  ABI Version:   0
>>  Type:  DYN (Shared object file)
>>  Machine:   Advanced Micro Devices X86-64
>>  Version:   0x1
>>  Entry point address:   0x3aee0
>>  Start of program headers:  64 (bytes into file)
>>  Start of section headers:  1644696 (bytes into file)
>>  Flags: 0x0
>>  Size of this header:   64 (bytes)
>>  Size of program headers:   56 (bytes)
>>  Number of program headers: 6
>>  Size of section headers:   64 (bytes)
>>  Number of section headers: 40
>>  Section header string table index: 37
>>
>> That isn't the only libc.so.7 in my build tree, though:
>>
>> /usr/obj/usr/src/tmp/lib/libc.so.7:ELF 64-bit LSB shared object,
>> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
>> /usr/obj/usr/src/lib/libc/libc.so.7:   ELF 64-bit LSB shared object,
>> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
>> /usr/obj/lib32/usr/src/lib/libc/libc.so.7: ELF 32-bit LSB shared object,
>> Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
> 
> Hm, that all looks perfectly normal, supposing that you are on amd64.
> Maybe it's the stripping that fails?  Do you have STRIP defined in your
> environment, or make.conf?
> 
> -Dimitry
> 
No, STRIP is not defined anywhere.  -- George



signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 17:20, Kevin Oberman wrote:
> [...]
> 
> While I have no suggestions about the error building libc, your statement
> that you can't use freebsd-update due to your use of a custom kernel is
> incorrect. This is a common misconception and, in cases of very limited
> disk space, may be true, it is rare. It is helped by the fact that the man
> page makes no mention of how to so this. (You do still need to build a new
> kernel if the update does, indeed, touch the kernel.)
> 
> All you need is a GENERIC kernel in /boot/GENERIC. You can either build it
> or download it. See the FreeBSD Handbook Section 23.2.3.1, “Custom Kernels
> with FreeBSD 9.X and Later”
> 
> for details on downloading a GENERIC kernel. Before any upgrade, major or
> minor, you might wat to re-reas that section.
> 
> Once the GENERIC kernel is in /boot, you may use freebsd-update and, if the
> GENERIC kernel is not updated, you're good to go. If it is, you will need
> to build and install a new custom kernel and reboot. Since most security
> patches don't touch the kernel, this is usually not needed. I believe that
> the 10.3 kernel was last touched in p11.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
Thanks, I'll try that the next time I have a chance.  When I naively
tried a straight "freebsd-update" a few months ago, of course it
overwrote my SCHED_4BSD kernel with a SCHED_ULE one.-- George



signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[Dimitry Andric]

On 11 Jan 2017, at 23:35, George Mitchell  wrote:
> 
> On 01/11/17 17:25, Dimitry Andric wrote:
>> On 11 Jan 2017, at 21:24, George Mitchell  wrote:
...
>>> building shared library libc.so.7
>>> cc (a very long compile line)
>>> ./libc.so.7: unsupported file layout
>> 
>> If things went correctly, the libc.so.7 file should be in
>> /usr/obj/usr/src/lib/libc.  If so, can you post the output of:
>> 
>> file /usr/obj/usr/src/lib/libc/libc.so.7
>> readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
>> 
>> -Dimitry
>> 
> root@sullivan:/usr/src # file /usr/obj/usr/src/lib/libc/libc.so.7
> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit LSB shared object,
> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
> root@sullivan:/usr/src # readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
> ELF Header:
>  Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00
>  Class: ELF64
>  Data:  2's complement, little endian
>  Version:   1 (current)
>  OS/ABI:UNIX - FreeBSD
>  ABI Version:   0
>  Type:  DYN (Shared object file)
>  Machine:   Advanced Micro Devices X86-64
>  Version:   0x1
>  Entry point address:   0x3aee0
>  Start of program headers:  64 (bytes into file)
>  Start of section headers:  1644696 (bytes into file)
>  Flags: 0x0
>  Size of this header:   64 (bytes)
>  Size of program headers:   56 (bytes)
>  Number of program headers: 6
>  Size of section headers:   64 (bytes)
>  Number of section headers: 40
>  Section header string table index: 37
> 
> That isn't the only libc.so.7 in my build tree, though:
> 
> /usr/obj/usr/src/tmp/lib/libc.so.7:ELF 64-bit LSB shared object,
> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
> /usr/obj/usr/src/lib/libc/libc.so.7:   ELF 64-bit LSB shared object,
> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
> /usr/obj/lib32/usr/src/lib/libc/libc.so.7: ELF 32-bit LSB shared object,
> Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped

Hm, that all looks perfectly normal, supposing that you are on amd64.
Maybe it's the stripping that fails?  Do you have STRIP defined in your
environment, or make.conf?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 17:25, Dimitry Andric wrote:
> On 11 Jan 2017, at 21:24, George Mitchell  wrote:
>>
>> After today's OpenSSH security message, I did:
>>
>> cd /usr
>> rm -rf obj
> 
> Hmm, not sure if it is wise to completely remove the /usr/obj directory.
> Did you re-create it afterwards?

In the past, "make buildworld" has taken care of that (as far as I
could tell).

> 
> 
>> cd src
>> svn update -r311916
>> make buildworld
>>
>> After a while, I got to:
>>
>> building shared library libc.so.7
>> cc (a very long compile line)
>> ./libc.so.7: unsupported file layout
> 
> If things went correctly, the libc.so.7 file should be in
> /usr/obj/usr/src/lib/libc.  If so, can you post the output of:
> 
> file /usr/obj/usr/src/lib/libc/libc.so.7
> readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
> 
> -Dimitry
> 
root@sullivan:/usr/src # file /usr/obj/usr/src/lib/libc/libc.so.7
/usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit LSB shared object,
x86-64, version 1 (FreeBSD), dynamically linked, not stripped
root@sullivan:/usr/src # readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - FreeBSD
  ABI Version:   0
  Type:  DYN (Shared object file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x3aee0
  Start of program headers:  64 (bytes into file)
  Start of section headers:  1644696 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 6
  Size of section headers:   64 (bytes)
  Number of section headers: 40
  Section header string table index: 37

That isn't the only libc.so.7 in my build tree, though:

/usr/obj/usr/src/tmp/lib/libc.so.7:ELF 64-bit LSB shared object,
x86-64, version 1 (FreeBSD), dynamically linked, not stripped
/usr/obj/usr/src/lib/libc/libc.so.7:   ELF 64-bit LSB shared object,
x86-64, version 1 (FreeBSD), dynamically linked, not stripped
/usr/obj/lib32/usr/src/lib/libc/libc.so.7: ELF 32-bit LSB shared object,
Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped




signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[Dimitry Andric]

On 11 Jan 2017, at 21:24, George Mitchell  wrote:
> 
> After today's OpenSSH security message, I did:
> 
> cd /usr
> rm -rf obj

Hmm, not sure if it is wise to completely remove the /usr/obj directory.
Did you re-create it afterwards?


> cd src
> svn update -r311916
> make buildworld
> 
> After a while, I got to:
> 
> building shared library libc.so.7
> cc (a very long compile line)
> ./libc.so.7: unsupported file layout

If things went correctly, the libc.so.7 file should be in
/usr/obj/usr/src/lib/libc.  If so, can you post the output of:

file /usr/obj/usr/src/lib/libc/libc.so.7
readelf -h /usr/obj/usr/src/lib/libc/libc.so.7

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 10.3-RELEASE-p13 "unsupported file layout"

[Kevin Oberman]

On Wed, Jan 11, 2017 at 12:24 PM, George Mitchell 
wrote:

> After today's OpenSSH security message, I did:
>
> cd /usr
> rm -rf obj
> cd src
> svn update -r311916
> make buildworld
>
> After a while, I got to:
>
> building shared library libc.so.7
> cc (a very long compile line)
> ./libc.so.7: unsupported file layout
> *** Error code 1
>
> Stop.
> make[4]: stopped in /usr/src/lib/libc
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
> freebsd-version -ku
> 10.3-RELEASE-p13
> 10.3-RELEASE-p15
>
> I am using a generic kernel, except for using SCHED_4BSD.  If it
> weren't for that, I would just use freebsd-update.
>
> Googling suggests that my build tree is somehow mixing up 32 and 64
> bit files.  (I'm running on an amd64 machine.)  How do I get this
> cleared up? -- George
>

While I have no suggestions about the error building libc, your statement
that you can't use freebsd-update due to your use of a custom kernel is
incorrect. This is a common misconception and, in cases of very limited
disk space, may be true, it is rare. It is helped by the fact that the man
page makes no mention of how to so this. (You do still need to build a new
kernel if the update does, indeed, touch the kernel.)

All you need is a GENERIC kernel in /boot/GENERIC. You can either build it
or download it. See the FreeBSD Handbook Section 23.2.3.1, “Custom Kernels
with FreeBSD 9.X and Later”

for details on downloading a GENERIC kernel. Before any upgrade, major or
minor, you might wat to re-reas that section.

Once the GENERIC kernel is in /boot, you may use freebsd-update and, if the
GENERIC kernel is not updated, you're good to go. If it is, you will need
to build and install a new custom kernel and reboot. Since most security
patches don't touch the kernel, this is usually not needed. I believe that
the 10.3 kernel was last touched in p11.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

After today's OpenSSH security message, I did:

cd /usr
rm -rf obj
cd src
svn update -r311916
make buildworld

After a while, I got to:

building shared library libc.so.7
cc (a very long compile line)
./libc.so.7: unsupported file layout
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib/libc
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

freebsd-version -ku
10.3-RELEASE-p13
10.3-RELEASE-p15

I am using a generic kernel, except for using SCHED_4BSD.  If it
weren't for that, I would just use freebsd-update.

Googling suggests that my build tree is somehow mixing up 32 and 64
bit files.  (I'm running on an amd64 machine.)  How do I get this
cleared up? -- George



signature.asc
Description: OpenPGP digital signature

Re: Can't boot on ZFS -- /boot/zfsloader not found

[Steven Hartland]

As your not at the boot loader stage yet for keyboard enabling legacy 
USB keyboard / mouse support in BIOS may help.


If you see issues with keyboard after the kernel takes over setting 
hint.ehci.0.disabled=1 may help.


If your installing 11.x then the guides boot partition size is out of 
date and you should use 512K for your freebsd-boot partition.


For the GPT version (I've never used MBR one) what actual error do you get?

On 11/01/2017 19:22, Jeremie Le Hen wrote:

Hi,

I'm in the process of transferring my home server to an Intel NUC. I've zfs
send/receive'd the whole pool to the new drive and first followed
[ZfsOnGpt] but it fails in the first stage boot loader. The USB keyboard
doesn't seem to be recognized so I can't really debug anything.

Then I tried both [ZfsInMbrSlice]
but it complains that it can't find /boot/zfsloader. Again USB keyboard
doesn't work.

Both times I've been very careful to install the bootcodes at the right
place.

1. Any idea why the USB keyboard doesn't work?
2. Any idea what can be wrong in the setups I tried? How can I debug this?

[ZfsOnGpt] https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
[ZfsInMbrSlice] https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition

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


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

Can't boot on ZFS -- /boot/zfsloader not found

[Jeremie Le Hen]

Hi,

I'm in the process of transferring my home server to an Intel NUC. I've zfs
send/receive'd the whole pool to the new drive and first followed
[ZfsOnGpt] but it fails in the first stage boot loader. The USB keyboard
doesn't seem to be recognized so I can't really debug anything.

Then I tried both [ZfsInMbrSlice]
but it complains that it can't find /boot/zfsloader. Again USB keyboard
doesn't work.

Both times I've been very careful to install the bootcodes at the right
place.

1. Any idea why the USB keyboard doesn't work?
2. Any idea what can be wrong in the setups I tried? How can I debug this?

[ZfsOnGpt] https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
[ZfsInMbrSlice] https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition

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

Re: Regression in pciconf utility in releng/11.0

[David Boyd]

-Original Message-From: David Boyd 
To: freebsd-stable@freebsd.org
Subject: Regression in pciconf utility in releng/11.0
Date: Wed, 28 Dec 2016 10:14:57 -0500

pciconf -lv em0@pci0:6:0:0: returns the following error:

pciconf: cannont parse selector em0:pci0:6:0:0:

This is contrary to the man page documentation which specifies that the
trailing colon is optional and ignored.

I have verified that this worked properly (as documented) in
releng/10.3.

A diff of pciconf.c between releng/11.0 and releng/10.3 show that the
"parsesel" function received a major rewrite.

Thanks.

If I should submit a PR, just let me know.



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

Re: Ugh -- attempted to update this morning, and got a nasty panic in ZFS....

[Karl Denninger]

A second attempt to come up on the new kernel was successful -- so this
had to be due to queued I/Os that were pending at the time of the
shutdown


On 1/11/2017 08:31, Karl Denninger wrote:
> During the reboot, immediately after the daemons started up on the
> machine (the boot got beyond mounting all the disks and was well into
> starting up all the background stuff it runs), I got a double-fault.
>
> . (there were a LOT more of this same; it pretty clearly was a
> recursive call sequence that ran the system out of stack space)
>
> #294 0x822fdcfd in zio_execute (zio=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
> #295 0x8230130e in zio_vdev_io_start (zio=0xf8010c8f27b0)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3127
> #296 0x822fdcfd in zio_execute (zio=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
> #297 0x822e464d in vdev_queue_io_done (zio=)
> at
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:913
> #298 0x823014c9 in zio_vdev_io_done (zio=0xf8010cff0b88)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3152
> #299 0x822fdcfd in zio_execute (zio=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
> #300 0x8230130e in zio_vdev_io_start (zio=0xf8010cff0b88)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3127
> #301 0x822fdcfd in zio_execute (zio=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
> #302 0x822e464d in vdev_queue_io_done (zio=)
> at
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:913
> #303 0x823014c9 in zio_vdev_io_done (zio=0xf8010c962000)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3152
> #304 0x822fdcfd in zio_execute (zio=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
> #305 0x8230130e in zio_vdev_io_start (zio=0xf8010c962000)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3127
> #306 0x822fdcfd in zio_execute (zio=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
> #307 0x822e464d in vdev_queue_io_done (zio=)
> at
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:913
> #308 0x823014c9 in zio_vdev_io_done (zio=0xf80102175000)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3152
> #309 0x822fdcfd in zio_execute (zio=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
> #310 0x80b2585a in taskqueue_run_locked (queue= out>)
> at /usr/src/sys/kern/subr_taskqueue.c:454
> #311 0x80b26a48 in taskqueue_thread_loop (arg=)
> at /usr/src/sys/kern/subr_taskqueue.c:724
> #312 0x80a7eb05 in fork_exit (
> callout=0x80b26960 ,
> arg=0xf800b8824c30, frame=0xfe0667430c00)
> at /usr/src/sys/kern/kern_fork.c:1040
> #313 0x80f87c3e in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:611
> #314 0x in ?? ()
> Current language:  auto; currently minimal
> (kgdb)
>
> .
>
>
> NewFS.denninger.net dumped core - see /var/crash/vmcore.3
>
> Wed Jan 11 08:15:33 CST 2017
>
> FreeBSD NewFS.denninger.net 11.0-STABLE FreeBSD 11.0-STABLE #14
> r311927M: Wed Ja
> n 11 07:55:20 CST 2017
> k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP
>   amd64
>
> panic: double fault
>
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
>
> Fatal double fault
> rip = 0x822e3c5d
> rsp = 0xfe066742af90
> rbp = 0xfe066742b420
> cpuid = 15; apic id = 35
> panic: double fault
> cpuid = 15
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe0649ddee30
> vpanic() at vpanic+0x186/frame 0xfe0649ddeeb0
> panic() at panic+0x43/frame 0xfe0649ddef10
> dblfault_handler() at dblfault_handler+0xa2/frame 0xfe0649ddef30
> Xdblfault() at Xdblfault+0xac/frame 0xfe0649ddef30
> --- trap 0x17, rip = 0x822e3c5d, rsp = 0xfe066742af90, rbp =
> 0xf
> e066742b420 ---
>
> # Work around for this CPU from 11.x eratta
> vm.pmap.pcid_enabled=0
> #
> #
> # Try to avoid kernel stack exhaustion due to TRIM storms.
> kern.kstack_pages="6"
>
> I have kstack_pages set to "6" to try to avoid another panic that I got
> occasionally during zfs backup operations which appeared to be linked to
> 

Season's Greetings

[Mousumi Nandan]

[image: Inline image 1]



Please reply to this email if you want to unsubscribe.


Best Regards
*Mousumi Nandan *
SARA | Business Development Executive
Mobile: +91 987 45678 47
Office: +91 33 400 88 333
Email: mousumi.sarainternatio...@gmail.com
  sales.sarainternatio...@gmail.com
   info.sarainternatio...@gmail.com
Sara International
“We believe in building long term relationship”
55 Ezra Street, 2nd Floor, Kolkata

West Bengal, India

Add a magic button to Gmail

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

Ugh -- attempted to update this morning, and got a nasty panic in ZFS....

[Karl Denninger]

During the reboot, immediately after the daemons started up on the
machine (the boot got beyond mounting all the disks and was well into
starting up all the background stuff it runs), I got a double-fault.

. (there were a LOT more of this same; it pretty clearly was a
recursive call sequence that ran the system out of stack space)

#294 0x822fdcfd in zio_execute (zio=)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
#295 0x8230130e in zio_vdev_io_start (zio=0xf8010c8f27b0)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3127
#296 0x822fdcfd in zio_execute (zio=)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
#297 0x822e464d in vdev_queue_io_done (zio=)
at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:913
#298 0x823014c9 in zio_vdev_io_done (zio=0xf8010cff0b88)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3152
#299 0x822fdcfd in zio_execute (zio=)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
#300 0x8230130e in zio_vdev_io_start (zio=0xf8010cff0b88)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3127
#301 0x822fdcfd in zio_execute (zio=)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
#302 0x822e464d in vdev_queue_io_done (zio=)
at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:913
#303 0x823014c9 in zio_vdev_io_done (zio=0xf8010c962000)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3152
#304 0x822fdcfd in zio_execute (zio=)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
#305 0x8230130e in zio_vdev_io_start (zio=0xf8010c962000)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3127
#306 0x822fdcfd in zio_execute (zio=)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
#307 0x822e464d in vdev_queue_io_done (zio=)
at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:913
#308 0x823014c9 in zio_vdev_io_done (zio=0xf80102175000)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3152
#309 0x822fdcfd in zio_execute (zio=)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1666
#310 0x80b2585a in taskqueue_run_locked (queue=)
at /usr/src/sys/kern/subr_taskqueue.c:454
#311 0x80b26a48 in taskqueue_thread_loop (arg=)
at /usr/src/sys/kern/subr_taskqueue.c:724
#312 0x80a7eb05 in fork_exit (
callout=0x80b26960 ,
arg=0xf800b8824c30, frame=0xfe0667430c00)
at /usr/src/sys/kern/kern_fork.c:1040
#313 0x80f87c3e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:611
#314 0x in ?? ()
Current language:  auto; currently minimal
(kgdb)

.


NewFS.denninger.net dumped core - see /var/crash/vmcore.3

Wed Jan 11 08:15:33 CST 2017

FreeBSD NewFS.denninger.net 11.0-STABLE FreeBSD 11.0-STABLE #14
r311927M: Wed Ja
n 11 07:55:20 CST 2017
k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP
  amd64

panic: double fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:

Fatal double fault
rip = 0x822e3c5d
rsp = 0xfe066742af90
rbp = 0xfe066742b420
cpuid = 15; apic id = 35
panic: double fault
cpuid = 15
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe0649ddee30
vpanic() at vpanic+0x186/frame 0xfe0649ddeeb0
panic() at panic+0x43/frame 0xfe0649ddef10
dblfault_handler() at dblfault_handler+0xa2/frame 0xfe0649ddef30
Xdblfault() at Xdblfault+0xac/frame 0xfe0649ddef30
--- trap 0x17, rip = 0x822e3c5d, rsp = 0xfe066742af90, rbp =
0xf
e066742b420 ---

# Work around for this CPU from 11.x eratta
vm.pmap.pcid_enabled=0
#
#
# Try to avoid kernel stack exhaustion due to TRIM storms.
kern.kstack_pages="6"

I have kstack_pages set to "6" to try to avoid another panic that I got
occasionally during zfs backup operations which appeared to be linked to
"too many" TRIMs, and looks very similar to this one.

I rebooted back to kernel.old, which was built in October, and the
machine came up normally.  I'll try the newer build again and see if
this was transient and related to delayed TRIM operations on the disks
related to the installworld/installkernel.  But if it is then it remains
a problem -- and setting stackpages didn't help!

I've got the dump if