Booting native 4K SSD disk from FreeBSD ?

[Hans Petter Selasky]

Hi,

I accidentially ordered a Sata SSD disk which diskinfo reports a 
sector-size 4K instead of 512 bytes. Trying to get it to boot under 
FreeBSD appeared impossible. Then I started looking into the boot0,1,2 
and loader and the assumptions they make about 512 byte sector size LBA :-(


Anyone has any recommendations or experience about how to use native 4K 
disks with FreeBSD?


--HPS
___
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: Booting native 4K SSD disk from FreeBSD ?

[Allan Jude]

On 10/03/2017 17:18, Hans Petter Selasky wrote:
> Hi,
> 
> I accidentially ordered a Sata SSD disk which diskinfo reports a
> sector-size 4K instead of 512 bytes. Trying to get it to boot under
> FreeBSD appeared impossible. Then I started looking into the boot0,1,2
> and loader and the assumptions they make about 512 byte sector size LBA :-(
> 
> Anyone has any recommendations or experience about how to use native 4K
> disks with FreeBSD?
> 
> --HPS
> ___
> 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"

It is not possible in legacy/BIOS mode, because the BIOS calls do not
let you specify a sector size.

However, you SHOULD be able to boot from the 4k device using UEFI.
I am trying to debug a problem I am having with this on my new Mac,
which has a 4k NVMe disk.

-- 
Allan Jude
___
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: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

[Jeffrey Bouquet]

On Tue, 3 Oct 2017 10:51:24 +0200, "O. Hartmann"  wrote:

> When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeBSD 
> base, it
> seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD world 
> uses x86:64,
> FreeBSD is using amd64, but why is this used inconsistently all over the 
> places?
> 
> I run into trouble setting up some package- and base-servers and ran into the 
> problem
> when deleting - not thinking of this discovered inconsistency - some links on 
> the servers
> regarding FreeBSD:12:x86:64 (the same is for 11-STABLE).
> 
> Can someone shed some light onto this? 
> 
> What am I supposed to use now? The handbook referes to amd64, so I thought 
> poudriere
> would, too. 
> 
> Thanks in advance,
> 
> oh
> -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


[ not using poudriere yet ]
/me too
I think three places [ etc/pkg, /usr/local/etc/pkg/repos, 2nd place in base, ]
  fourth:  hard coded DESPITE the above in the current DB in var/db/pkg?
  fifth: derived somehow from uname -a?

here: freebsd:12:x86:32
... when this issue resolved, could it please be added to 'man 
pkg|poudriere|syntch|portmaster?|portupgrade?  [ the latter two when developed 
further ]'
___
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: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

[O. Hartmann]

Am Tue, 3 Oct 2017 13:08:53 +0200
Kurt Jaeger  schrieb:

> Hi!
> 
> > When using "poudriere", it seems ABI is freebsd:12:x86:64.  

As I wrote: poudriere repo.

> 
> Where do you get that value from ? If I access a repo,
> I access e.g.
> 
> https://repo.opsec.eu/${ABI}
> 
> and ABI maps to
> 
> FreeBSD:12:amd64
> 



-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpcewSS0GN14.pgp
Description: OpenPGP digital signature

Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

[Kurt Jaeger]

Hi!

> When using "poudriere", it seems ABI is freebsd:12:x86:64.

Where do you get that value from ? If I access a repo,
I access e.g.

https://repo.opsec.eu/${ABI}

and ABI maps to

FreeBSD:12:amd64

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
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"

ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

[O. Hartmann]

When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeBSD 
base, it
seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD world 
uses x86:64,
FreeBSD is using amd64, but why is this used inconsistently all over the places?

I run into trouble setting up some package- and base-servers and ran into the 
problem
when deleting - not thinking of this discovered inconsistency - some links on 
the servers
regarding FreeBSD:12:x86:64 (the same is for 11-STABLE).

Can someone shed some light onto this? 

What am I supposed to use now? The handbook referes to amd64, so I thought 
poudriere
would, too. 

Thanks in advance,

oh
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpnBI5iRcECp.pgp
Description: OpenPGP digital signature

anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

[Julian Elischer]

Our 10.4 system is using gcc (for now).

when we compile the devel/binutils port, we get a failure with a bunch 
of these errors:



`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section 
`.rodata' of aarch64.o: defined in discarded section 
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE]' 
of aarch64.o
`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section 
`.rodata' of aarch64.o: defined in discarded section 
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE]' 
of aarch64.o



I managed to defeat these one before but I forget how.

possibly the answer is to use clang/clang++ for this item but I tried 
defining CC and CXX  to clang/clang++ in the Makefile but that didn't 
seem to help


there's probably a USE_CLANG option or something that I haven't seen.


___
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: anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

[Ian Lepore]

On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote:
> Our 10.4 system is using gcc (for now).
> 
> when we compile the devel/binutils port, we get a failure with a
> bunch 
> of these errors:
> 
> 
> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section 
> `.rodata' of aarch64.o: defined in discarded section 
> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__
> N_110Stub_tableILi64ELb1EEE]' 
> of aarch64.o
> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section 
> `.rodata' of aarch64.o: defined in discarded section 
> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__
> N_110Stub_tableILi64ELb0EEE]' 
> of aarch64.o
> 
> 
> I managed to defeat these one before but I forget how.
> 
> possibly the answer is to use clang/clang++ for this item but I
> tried 
> defining CC and CXX  to clang/clang++ in the Makefile but that
> didn't 
> seem to help
> 
> there's probably a USE_CLANG option or something that I haven't seen.

We ran into the same thing recently at $work.  The root cause for us
involved having same-named classes in anonymous namespaces in different
compilation units.  The classes made reference to something that was
declared extern "C", bringing into play some rules about how C things
in anon namespaces really refer to the same global C object outside of
any namespace.  Then link-time optimization led to discarding the
object from one compilation unit, and that somehow resulted in
discarding the referenced extern "C" thing completely, even though it
was still referenced from the non-discarded instance of an object from
a different compilation unit.  Phew.

The same code has no problems with clang on freebsd 11, just with gcc
on 10.3.  

So, for us the fix was a bit heavy-handed: we just renamed one of the
classes involved in the problem so that there were no longer any same-
named classes in anon namespaces in separate compilation units.
 Probably not a good option for you.  A fix involving compile options
might result in not discarding unreferenced segments at all, and with
templated code that might result in huge binaries.

Mixing clang-compiled and gcc-compiled c++ may give you grief with
exceptions and other things (it would on ARM on 10.x, but maybe not on
x86 arches).

-- Ian

___
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: anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

[Julian Elischer]

On 4/10/17 12:56 am, Ian Lepore wrote:

On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote:

Our 10.4 system is using gcc (for now).

when we compile the devel/binutils port, we get a failure with a
bunch
of these errors:


`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section
`.rodata' of aarch64.o: defined in discarded section
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__
N_110Stub_tableILi64ELb1EEE]'
of aarch64.o
`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section
`.rodata' of aarch64.o: defined in discarded section
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__
N_110Stub_tableILi64ELb0EEE]'
of aarch64.o


I managed to defeat these one before but I forget how.

possibly the answer is to use clang/clang++ for this item but I
tried
defining CC and CXX  to clang/clang++ in the Makefile but that
didn't
seem to help

there's probably a USE_CLANG option or something that I haven't seen.

We ran into the same thing recently at $work.  The root cause for us
involved having same-named classes in anonymous namespaces in different
compilation units.  The classes made reference to something that was
declared extern "C", bringing into play some rules about how C things
in anon namespaces really refer to the same global C object outside of
any namespace.  Then link-time optimization led to discarding the
object from one compilation unit, and that somehow resulted in
discarding the referenced extern "C" thing completely, even though it
was still referenced from the non-discarded instance of an object from
a different compilation unit.  Phew.

The same code has no problems with clang on freebsd 11, just with gcc
on 10.3.

So, for us the fix was a bit heavy-handed: we just renamed one of the
classes involved in the problem so that there were no longer any same-
named classes in anon namespaces in separate compilation units.
  Probably not a good option for you.  A fix involving compile options
might result in not discarding unreferenced segments at all, and with
templated code that might result in huge binaries.

Mixing clang-compiled and gcc-compiled c++ may give you grief with
exceptions and other things (it would on ARM on 10.x, but maybe not on
x86 arches).

-- Ian



thanks

the issue comes up in the binutils port which is a dependency of gdb.

I don't think we actually need to install the binutils port on our 
appliance, (and we only install gdb to generate backtraces on debug 
reports)


I just added CC=clang and CXX=clang++ in the makefile that called it 
and the problem seemed to go away.



All i wanted to do is get gdb compiled and I end up with gcc6, llvm 
and binutils (plus a whole lot more) as a bonus (plus an extra 30 
minutes of compile time)




___
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: Booting native 4K SSD disk from FreeBSD ?

[Toomas Soome]

> On 4 Oct 2017, at 00:18, Hans Petter Selasky  wrote:
> 
> Hi,
> 
> I accidentially ordered a Sata SSD disk which diskinfo reports a sector-size 
> 4K instead of 512 bytes. Trying to get it to boot under FreeBSD appeared 
> impossible. Then I started looking into the boot0,1,2 and loader and the 
> assumptions they make about 512 byte sector size LBA :-(
> 
> Anyone has any recommendations or experience about how to use native 4K disks 
> with FreeBSD?
> 

The fastest way right now is via UEFI boot, it should be able to cope with 4k, 
but as Allan noted, there may be some corners.

The BIOS version is totally out right now, it only is supporting 512B sectors. 
I have been working to fix it starting with loader libi386 biosdisk interface 
(for loader itself), but due to lack of time it has been delayed somewhat. The 
plain loader bits are done, but the +GELI needs more work (the code has to cope 
with 512/4k sector and GELI is only doing 4k logical IO). The hard part is 
about the boot1 code (boot1,gptboot etc) and thats due to boot block area size 
limits (in existing setups). We are struggling to fit into UFS boot block area, 
and freebsd-boot and ESP sizes are also very small, making all this pain in the 
… 

rgds,
toomas

___
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"