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

2017-01-17 Thread George Mitchell 
On 01/11/17 15:24, George Mitchell wrote:
> After today's OpenSSH security message, I [tried a buildworld and]
>  got to:
> 
> building shared library libc.so.7
> cc (a very long compile line)
> ./libc.so.7: unsupported file layout
> [...]

I never did figure out the cause of this problem, but I did my
buildworld on another machine with no problem.  Then I rsync'd
/usr/src and /usr/obj back to the first machine and installed
the world.  Afterwards, I did one more buildworld on the first
machine, and it succeeded.  I think my original /usr/src tree
might have been corrupt, though I really don't know.  At least
everything is working now.   -- George



signature.asc
Description: OpenPGP digital signature

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

2017-01-11 Thread 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"

2017-01-11 Thread 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"

2017-01-11 Thread 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: 10.3-RELEASE-p13 "unsupported file layout"

2017-01-11 Thread 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"

2017-01-11 Thread 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"

2017-01-11 Thread 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"

2017-01-11 Thread 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"

2017-01-11 Thread 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"

2017-01-11 Thread 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"

2017-01-11 Thread 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