Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> 
> On Mon, 23 Jul 2018 10:56:04 +0300
> Toomas Soome  wrote:
> 
>>> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
>>> 
>>> On Fri, 13 Jul 2018 18:44:23 +0300
>>> Toomas Soome mailto:tso...@me.com>> wrote:
>>> 
> On 13 Jul 2018, at 17:44, O. Hartmann  > wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am Fri, 13 Jul 2018 14:26:51 +0300
> Toomas Soome mailto:tso...@me.com>  >> schrieb: 
>>> On 13 Jul 2018, at 14:00, O. Hartmann  wrote:
>>> 
>>> The problem is some kind of weird. I face UEFI boot problems on GPT
>>> drives where the first partition begins at block 40 of the hdd/ssd.
>>> 
>>> I have two host in private use based on an
>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket
>>> LGA1155). Both boards are equipted with the lates official available AMI
>>> firmware revision, dating to 2013. This is for the Z77-Pro4-M revision
>>> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both
>>> boards a BETA revision for the Spectre/Meltdown mitigation is available,
>>> but I didn't test that. But please read.
>>> 
>>> The third box I realised this problem is a brand new Fujitsu Esprimo
>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date
>>> 05/25/2018 (or 20180525).
>>> 
>>> Installing on any kind of HDD or SSD manually or via bsdinstall the OS
>>> using UEFI-only boot method on a GPT partitioned device fails. The
>>> ASRock boards jump immediately into the firmware, the Fujitsu offers
>>> some kind of CPU/Memory/HDD test facility.
>>> 
>>> If on both type of vendor/boards CSM is disabled and UEFI boot only is
>>> implied, the MBR partitioned FreeBSD installation USB flash device does
>>> boot in UEFI! I guess I can assume this when the well known clumsy 80x25
>>> char console suddenly gets bright and shiny with a much higher resoltion
>>> as long the GPU supports EFI GOP. Looking with gpart at the USB flash
>>> drives reveals that the EFI partition starts at block 1 of the device
>>> and the device has a MBR layout. I haven't found a way to force the GPT
>>> scheme, when initialised via gpart, to let the partitions start at block
>>> 1. This might be a naiv thinking, so please be patient with me.
>>> 
>>> I do not know whether this is a well-known issue. On the ASRock boards,
>>> I tried years ago some LinuxRed Hat and Suse with UEFI and that worked -
>>> FreeBSD not. I gave up on that that time. Now, having the very same
>>> issues with a new Fujitsu system, leaves me with the impression that
>>> FreeBSD's UEFI implementation might have problems I'm not aware of.
>>> 
>>> Can someone shed some light onto this? 
>>> 
>> 
>> The first thing to check is if the secure boot is disabled. We do not
>> support secure boot at all at this time.
> 
> Secure boot is in every scenario disabled!
> 
>> 
>> If you have efi or bios version running - you can check from either
>> console variable value (it can have efi or vidconsole or comconsole) or
>> better yet, see if efi-version is set (show efi-version) - if efi-version
>> is not set, it is BIOS loader running. Another indirect way is to see
>> lsdev -v, with device paths present, it is uefi:)
> 
> What are you talking about?
> What is the point of entry - running system, loader?
> 
> sysct machdep.bootmethod: BIOS
> 
> This makes me quite sure that the system has booted via BIOS - as I'm sure
> since I've checked that many times. UEFI doesn't work on those systems
> with FreeBSD. I'm not sure antmore, but I tried also Windows 7 on those
> mainboards booting via UEFI - and I might recall that they failed also. I
> also recall that there were issues with earlier UEFI versions regarding
> booting only Windows 8/8.1 - and nothing else, but the fact that Linux
> worked confuses me a bit.
> 
> If this ASRock crap (never ever again this brand!) doesn't work at all -
> who cares, I intend to purchase new server grade hardware. But the more
> puzzling issue is with the Fujitsu, which I consider serious and from the
> behaviour the Fujitsu failure looks exactly like the ASRock - Windows 7
> works, RedHat 7.5 works (I assume I can trust the Firmware settings when I
> disable CSM support, that the Firmware will only EFI/UEFI capable loader?
> Or is there a ghosty override somwhere to be expected?). Also on ASRock
> disabling CSM should ensure not booting a dual-bootstrap-capable system.
> This said, on the recent Fujitsu, it seems to boil down to a FreeBSD
> UEFI-firmware interaction problem, while the ASRock is still under
> 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Mon, 23 Jul 2018 10:56:04 +0300
Toomas Soome  wrote:

> > On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> > 
> > On Fri, 13 Jul 2018 18:44:23 +0300
> > Toomas Soome mailto:tso...@me.com>> wrote:
> >   
> >>> On 13 Jul 2018, at 17:44, O. Hartmann  >>> > wrote:
> >>> 
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA512
> >>> 
> >>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>> Toomas Soome mailto:tso...@me.com>  >>> >> schrieb: 
> > On 13 Jul 2018, at 14:00, O. Hartmann  wrote:
> > 
> > The problem is some kind of weird. I face UEFI boot problems on GPT
> > drives where the first partition begins at block 40 of the hdd/ssd.
> > 
> > I have two host in private use based on an
> > outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket
> > LGA1155). Both boards are equipted with the lates official available AMI
> > firmware revision, dating to 2013. This is for the Z77-Pro4-M revision
> > 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both
> > boards a BETA revision for the Spectre/Meltdown mitigation is available,
> > but I didn't test that. But please read.
> > 
> > The third box I realised this problem is a brand new Fujitsu Esprimo
> > Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date
> > 05/25/2018 (or 20180525).
> > 
> > Installing on any kind of HDD or SSD manually or via bsdinstall the OS
> > using UEFI-only boot method on a GPT partitioned device fails. The
> > ASRock boards jump immediately into the firmware, the Fujitsu offers
> > some kind of CPU/Memory/HDD test facility.
> > 
> > If on both type of vendor/boards CSM is disabled and UEFI boot only is
> > implied, the MBR partitioned FreeBSD installation USB flash device does
> > boot in UEFI! I guess I can assume this when the well known clumsy 80x25
> > char console suddenly gets bright and shiny with a much higher resoltion
> > as long the GPU supports EFI GOP. Looking with gpart at the USB flash
> > drives reveals that the EFI partition starts at block 1 of the device
> > and the device has a MBR layout. I haven't found a way to force the GPT
> > scheme, when initialised via gpart, to let the partitions start at block
> > 1. This might be a naiv thinking, so please be patient with me.
> > 
> > I do not know whether this is a well-known issue. On the ASRock boards,
> > I tried years ago some LinuxRed Hat and Suse with UEFI and that worked -
> > FreeBSD not. I gave up on that that time. Now, having the very same
> > issues with a new Fujitsu system, leaves me with the impression that
> > FreeBSD's UEFI implementation might have problems I'm not aware of.
> > 
> > Can someone shed some light onto this? 
> >   
>  
>  The first thing to check is if the secure boot is disabled. We do not
>  support secure boot at all at this time.
> >>> 
> >>> Secure boot is in every scenario disabled!
> >>>   
>  
>  If you have efi or bios version running - you can check from either
>  console variable value (it can have efi or vidconsole or comconsole) or
>  better yet, see if efi-version is set (show efi-version) - if efi-version
>  is not set, it is BIOS loader running. Another indirect way is to see
>  lsdev -v, with device paths present, it is uefi:)
> >>> 
> >>> What are you talking about?
> >>> What is the point of entry - running system, loader?
> >>> 
> >>> sysct machdep.bootmethod: BIOS
> >>> 
> >>> This makes me quite sure that the system has booted via BIOS - as I'm sure
> >>> since I've checked that many times. UEFI doesn't work on those systems
> >>> with FreeBSD. I'm not sure antmore, but I tried also Windows 7 on those
> >>> mainboards booting via UEFI - and I might recall that they failed also. I
> >>> also recall that there were issues with earlier UEFI versions regarding
> >>> booting only Windows 8/8.1 - and nothing else, but the fact that Linux
> >>> worked confuses me a bit.
> >>> 
> >>> If this ASRock crap (never ever again this brand!) doesn't work at all -
> >>> who cares, I intend to purchase new server grade hardware. But the more
> >>> puzzling issue is with the Fujitsu, which I consider serious and from the
> >>> behaviour the Fujitsu failure looks exactly like the ASRock - Windows 7
> >>> works, RedHat 7.5 works (I assume I can trust the Firmware settings when I
> >>> disable CSM support, that the Firmware will only EFI/UEFI capable loader?
> >>> Or is there a ghosty override somwhere to be expected?). Also on ASRock
> >>> disabling CSM should ensure not booting a dual-bootstrap-capable system.
> >>> This said, on the recent Fujitsu, it seems to boil down to a FreeBSD
> >>> UEFI-firmware interaction problem, while the ASRock is still under
> >>> suspicion to be broken by design.   
>  
>  GPT 

Re: ntpd as ntpd user question

[Kevin Oberman]

On Mon, Jul 23, 2018 at 7:25 PM, Ian Lepore  wrote:

> On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote:
> > On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote:
> > >
> > >
> > > Yes, first you press m. Then you will see differences of installed
> > > file (left) and new file (right). Then you press either l or
> > > r:
> > >
> > > l | 1:  choose left diff
> > > r | 2:  choose right diff
> > >
> > > If the diff tries to remove/add to many lines you can:
> > >
> > > el: edit left diff
> > > er: edit right diff
> > >
> > > And if done you can view the merged file (v) before installing (i)
> > > it.
> > >
> > > I am sure, someone can explain it better! :)
> > >
> > Perhaps, but you've made the essential point. Your reply let me
> > understand that
> > mergemaster does not really "master" the merge, it rather identifies
> > files needing
> > to be merged and then starts sdiff to let me modify files. Never
> > having even looked
> > at sdiff, the learning curve proved very steep. Too steep, in fact.
> >
> > I'm going to try a more incremental approach.
> >
> > Thank you _very_ much!
> >
> > bob prohaska
>
> Your reaction to mergemaster is about the same as mine was when I first
> encountered it very long ago, and re-discovered when I tried it a
> couple years ago. It just seems like more trouble than it's worth, I
> can usually figure out what's broken and fix it by hand faster than
> messing with all the merge stuff.
>
> But, someone told me that if you give mergemaster the right flags it
> can potentially be intervention-free. Those apparently aren't the flag
> or two that're suggested at the bottom of UPDATING. So I didn't really
> dig into that any deeper, but I toss it out there in case someone can
> expand on it.
>
> It certainly makes some sense that it could be done intervention-free.
> When doing other diff-based merges (like 'svn update') you only have to
> intervene when there's an actual conflict between some local change
> you've made and the incoming changes.
>
>
It gets a LOT simpler if you use "mergemaster -iPUF" Only those files you
have modified will show up. In most cases, it just zips right by. In most
that it does not, the use of 'r' or 'l' in merge is all you need and always
'r' eccepton lines you have modified, yourself, so you should know about
them.

I should note that 'U' does have a small "race" in it, so it i possible to
get biten by it, but it is very unlikely. Has to do with multiple commits
that touch the same lines in the file in a timing that is out of sync with
your running it. I use '-iPF' because I m paranoid.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: ntpd as ntpd user question

[bob prohaska]

On Mon, Jul 23, 2018 at 08:25:59PM -0600, Ian Lepore wrote:
> On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote:
> > at sdiff, the learning curve proved very steep. Too steep, in fact.
> > 
> > I'm going to try a more incremental approach.?
> > 
> > Thank you _very_ much!
> > 
> > bob prohaska
> 
> Your reaction to mergemaster is about the same as mine was when I first
> encountered it very long ago, and re-discovered when I tried it a
> couple years ago. It just seems like more trouble than it's worth, I
> can usually figure out what's broken and fix it by hand faster than
> messing with all the merge stuff.
> 
Your suggestion to use vipw seems to have worked. Copied the required
line, ran /usr/sbin/pwd_mkdb -p /etc/master.passwd and installworld ran
without issue.

The machine has now rebooted and ntp has set the clock correctly. 
I don't see ntpd in a ps -aux output.

It's unclear what I need to do next, but at least I'm over the first
hurdle. I'll go back to your earlier email and attempt the rest of the
updates by hand.

Thanks for all your help!

bob prohaska


> But, someone told me that if you give mergemaster the right flags it
> can potentially be intervention-free. Those apparently aren't the flag
> or two that're suggested at the bottom of UPDATING. So I didn't really
> dig into that any deeper, but I toss it out there in case someone can
> expand on it.
> 
> It certainly makes some sense that it could be done intervention-free.
> When doing other diff-based merges (like 'svn update') you only have to
> intervene when there's an actual conflict between some local change
> you've made and the incoming changes.
> 
> -- 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"
> 
___
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: ntpd as ntpd user question

[Ian Lepore]

On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote:
> On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote:
> > 
> > 
> > Yes, first you press m. Then you will see differences of installed
> > file (left) and new file (right). Then you press either l or
> > r:
> > 
> > l | 1:  choose left diff
> > r | 2:  choose right diff
> > 
> > If the diff tries to remove/add to many lines you can:
> > 
> > el: edit left diff
> > er: edit right diff
> > 
> > And if done you can view the merged file (v) before installing (i)
> > it.
> > 
> > I am sure, someone can explain it better! :)
> > 
> Perhaps, but you've made the essential point. Your reply let me
> understand that 
> mergemaster does not really "master" the merge, it rather identifies
> files needing 
> to be merged and then starts sdiff to let me modify files. Never
> having even looked 
> at sdiff, the learning curve proved very steep. Too steep, in fact.
> 
> I'm going to try a more incremental approach. 
> 
> Thank you _very_ much!
> 
> bob prohaska

Your reaction to mergemaster is about the same as mine was when I first
encountered it very long ago, and re-discovered when I tried it a
couple years ago. It just seems like more trouble than it's worth, I
can usually figure out what's broken and fix it by hand faster than
messing with all the merge stuff.

But, someone told me that if you give mergemaster the right flags it
can potentially be intervention-free. Those apparently aren't the flag
or two that're suggested at the bottom of UPDATING. So I didn't really
dig into that any deeper, but I toss it out there in case someone can
expand on it.

It certainly makes some sense that it could be done intervention-free.
When doing other diff-based merges (like 'svn update') you only have to
intervene when there's an actual conflict between some local change
you've made and the incoming changes.

-- 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: ntpd as ntpd user question

[bob prohaska]

On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote:
> 
> Yes, first you press m. Then you will see differences of installed
> file (left) and new file (right). Then you press either l or
> r:
> 
> l | 1:choose left diff
> r | 2:choose right diff
> 
> If the diff tries to remove/add to many lines you can:
> 
> el:   edit left diff
> er:   edit right diff
> 
> And if done you can view the merged file (v) before installing (i) it.
> 
> I am sure, someone can explain it better! :)
> 

Perhaps, but you've made the essential point. Your reply let me understand that 
mergemaster does not really "master" the merge, it rather identifies files 
needing 
to be merged and then starts sdiff to let me modify files. Never having even 
looked 
at sdiff, the learning curve proved very steep. Too steep, in fact.

I'm going to try a more incremental approach. 

Thank you _very_ much!

bob prohaska
 


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

awk manual

[Samy Mahmoudi]

Hello,

The awk manual seems out of date.

For example, the -V option is documented but is unknown at execution.
Reciprocally, --version is not documented but is functional at execution.
Under FreeBSD 12.0-CURRENT, the date at the end of the manual also seems
older than expected, as the FreeBSD Manual Pages indicates a newer date for
FreeBSD 11.2.

I could edit awk.1 and copy/paste a patch to solve these but reviewing the
whole manual may be better to eradicate other omissions. From the FreeBSD
Manual Pages, I have found out that options (including -V) were introduced
between 11.0 RELEASE and 11.1 RELEASE.

By the way, choosing the "FreeBSD 12-current" manual on that web page

actually gives the "FreeBSD 11.2" manual, seemingly.

Best regards,
Samy
___
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: ntpd as ntpd user question

[Herbert J. Skuhra]

On Mon, 23 Jul 2018 06:55:52 +0200,
bob prohaska  wrote:
> 
> On Sun, Jul 22, 2018 at 01:49:41AM +0200, Herbert J. Skuhra wrote:
> > On Sat, Jul 21, 2018 at 03:09:26PM -0700, bob prohaska wrote:
> 
> > > The failure is a little surprising, is ntpd a reserved name?
> > 
> > Why? You obviously entered the string "ntpd" instead of an integer when
> > asked for the uid!?
> > 
> 
> Sigh...you're right. Must have been sleepier than I thought.
> 
> > > The machine is re-running buildworld/installworld from a clean start,
> > > so presumably it'll halt over the same error again. When that happens, 
> > > what's the simplest way to recover? Mergemaster is a big hammer, something
> > > less comprehensive might suffice, even manual editing of files.
> > 
> > In this case 'mergemaster -p' is enough.
> > 
> 
> An example or two on the use of mergemaster might be a considerable help. 
> There's something
> very basic that I don't understand.
> 
> What is the correct response to the prompts for this simple case? The output 
> displayed
> is said to be differences, so the "temporary" file's nature isn't 
> self-evident. It looks
> as if the most obvious option is m, followed by eb, but that leaves me 
> editing by hand, 
> which is what I thought mergemaster was supposed to avoid. 

Yes, first you press m. Then you will see differences of installed
file (left) and new file (right). Then you press either l or
r:

l | 1:  choose left diff
r | 2:  choose right diff

If the diff tries to remove/add to many lines you can:

el: edit left diff
er: edit right diff

And if done you can view the merged file (v) before installing (i) it.

I am sure, someone can explain it better! :)

--
Herbert
___
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: ntpd as ntpd user question

[David Wolfskill]

On Mon, Jul 23, 2018 at 04:00:04PM +, Filippo Moretti wrote:
>  I have ntpd both in etc(passwd and /etc/group but installworld fail saying 
> that user ntpd is missing can you please let me know how
> to manually edit the entries for ntpd in both files.Etcupdate fails
> .It is rather odd because with the same hardware using ufs I did not run into 
> problem with zfs system I get this error
> 

Depending on how you updated /etc/master.passwd, you may also need to
run pwd_mkdb.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Can a "stable genius" get a Nobel Peace Prize for firing off ALL CAPS tweets?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ntpd as ntpd user question

[Filippo Moretti]

 
It does not matter the system no longer boot.
Filippo
On Monday, July 23, 2018, 6:00:04 PM GMT+2, Filippo Moretti 
 wrote:  
 
  I have ntpd both in etc(passwd and /etc/group but installworld fail saying 
that user ntpd is missing can you please let me know how
to manually edit the entries for ntpd in both files.Etcupdate fails
.It is rather odd because with the same hardware using ufs I did not run into 
problem with zfs system I get this error
Filippo

On Monday, July 23, 2018, 1:00:10 PM GMT+2, Niclas Zeising 
 wrote:  
 
 On 07/21/18 19:56, RW wrote:
> On Sat, 21 Jul 2018 11:14:45 -0600
> Ian Lepore wrote:
> 
> 
>> There's a "pre-world" stage of mergemaster (-Fp option I think) which
>> isn't needed often, but one of the times it is needed is apparently
>> when new user ids are added.
> 
> I wish mergemaster had an option to just add new users and groups,
> rather than merging the files.

etcupdate is usually pretty good at automatically merge updates to files 
without user interaction, even when the files are locally edited as 
well.  For instance, I had no problem merging /etc/master.passwd and 
/etc/group for the ntp change.
Regards
-- 
Niclas
___
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"

___
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: ntpd as ntpd user question

[Filippo Moretti]

 I have ntpd both in etc(passwd and /etc/group but installworld fail saying 
that user ntpd is missing can you please let me know how
to manually edit the entries for ntpd in both files.Etcupdate fails
.It is rather odd because with the same hardware using ufs I did not run into 
problem with zfs system I get this error
Filippo

On Monday, July 23, 2018, 1:00:10 PM GMT+2, Niclas Zeising 
 wrote:  
 
 On 07/21/18 19:56, RW wrote:
> On Sat, 21 Jul 2018 11:14:45 -0600
> Ian Lepore wrote:
> 
> 
>> There's a "pre-world" stage of mergemaster (-Fp option I think) which
>> isn't needed often, but one of the times it is needed is apparently
>> when new user ids are added.
> 
> I wish mergemaster had an option to just add new users and groups,
> rather than merging the files.

etcupdate is usually pretty good at automatically merge updates to files 
without user interaction, even when the files are locally edited as 
well.  For instance, I had no problem merging /etc/master.passwd and 
/etc/group for the ntp change.
Regards
-- 
Niclas
___
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"
  
___
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: ntpd as ntpd user question

[Niclas Zeising]

On 07/21/18 19:56, RW wrote:

On Sat, 21 Jul 2018 11:14:45 -0600
Ian Lepore wrote:



There's a "pre-world" stage of mergemaster (-Fp option I think) which
isn't needed often, but one of the times it is needed is apparently
when new user ids are added.


I wish mergemaster had an option to just add new users and groups,
rather than merging the files.


etcupdate is usually pretty good at automatically merge updates to files 
without user interaction, even when the files are locally edited as 
well.  For instance, I had no problem merging /etc/master.passwd and 
/etc/group for the ntp change.

Regards
--
Niclas
___
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: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> 
> On Fri, 13 Jul 2018 18:44:23 +0300
> Toomas Soome mailto:tso...@me.com>> wrote:
> 
>>> On 13 Jul 2018, at 17:44, O. Hartmann >> > wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>> 
>>> Am Fri, 13 Jul 2018 14:26:51 +0300
>>> Toomas Soome mailto:tso...@me.com> >> >> schrieb:
>>> 
> On 13 Jul 2018, at 14:00, O. Hartmann  wrote:
> 
> The problem is some kind of weird. I face UEFI boot problems on GPT drives
> where the first partition begins at block 40 of the hdd/ssd.
> 
> I have two host in private use based on an
> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket
> LGA1155). Both boards are equipted with the lates official available AMI
> firmware revision, dating to 2013. This is for the Z77-Pro4-M revision
> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both
> boards a BETA revision for the Spectre/Meltdown mitigation is available,
> but I didn't test that. But please read.
> 
> The third box I realised this problem is a brand new Fujitsu Esprimo
> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date
> 05/25/2018 (or 20180525).
> 
> Installing on any kind of HDD or SSD manually or via bsdinstall the OS
> using UEFI-only boot method on a GPT partitioned device fails. The ASRock
> boards jump immediately into the firmware, the Fujitsu offers some kind
> of CPU/Memory/HDD test facility.
> 
> If on both type of vendor/boards CSM is disabled and UEFI boot only is
> implied, the MBR partitioned FreeBSD installation USB flash device does
> boot in UEFI! I guess I can assume this when the well known clumsy 80x25
> char console suddenly gets bright and shiny with a much higher resoltion
> as long the GPU supports EFI GOP. Looking with gpart at the USB flash
> drives reveals that the EFI partition starts at block 1 of the device and
> the device has a MBR layout. I haven't found a way to force the GPT
> scheme, when initialised via gpart, to let the partitions start at block
> 1. This might be a naiv thinking, so please be patient with me.
> 
> I do not know whether this is a well-known issue. On the ASRock boards, I
> tried years ago some LinuxRed Hat and Suse with UEFI and that worked -
> FreeBSD not. I gave up on that that time. Now, having the very same
> issues with a new Fujitsu system, leaves me with the impression that
> FreeBSD's UEFI implementation might have problems I'm not aware of.
> 
> Can someone shed some light onto this? 
> 
 
 The first thing to check is if the secure boot is disabled. We do not
 support secure boot at all at this time.  
>>> 
>>> Secure boot is in every scenario disabled!
>>> 
 
 If you have efi or bios version running - you can check from either
 console variable value (it can have efi or vidconsole or comconsole) or
 better yet, see if efi-version is set (show efi-version) - if efi-version
 is not set, it is BIOS loader running. Another indirect way is to see
 lsdev -v, with device paths present, it is uefi:)  
>>> 
>>> What are you talking about?
>>> What is the point of entry - running system, loader?
>>> 
>>> sysct machdep.bootmethod: BIOS
>>> 
>>> This makes me quite sure that the system has booted via BIOS - as I'm sure
>>> since I've checked that many times. UEFI doesn't work on those systems with
>>> FreeBSD. I'm not sure antmore, but I tried also Windows 7 on those
>>> mainboards booting via UEFI - and I might recall that they failed also. I
>>> also recall that there were issues with earlier UEFI versions regarding
>>> booting only Windows 8/8.1 - and nothing else, but the fact that Linux
>>> worked confuses me a bit.
>>> 
>>> If this ASRock crap (never ever again this brand!) doesn't work at all -
>>> who cares, I intend to purchase new server grade hardware. But the more
>>> puzzling issue is with the Fujitsu, which I consider serious and from the
>>> behaviour the Fujitsu failure looks exactly like the ASRock - Windows 7
>>> works, RedHat 7.5 works (I assume I can trust the Firmware settings when I
>>> disable CSM support, that the Firmware will only EFI/UEFI capable loader?
>>> Or is there a ghosty override somwhere to be expected?). Also on ASRock
>>> disabling CSM should ensure not booting a dual-bootstrap-capable system.
>>> This said, on the recent Fujitsu, it seems to boil down to a FreeBSD
>>> UEFI-firmware interaction problem, while the ASRock is still under
>>> suspicion to be broken by design. 
 
 GPT partitions can never start from disk absolute sector 1; this is
 because at sector 0 there is MBR (for compatibility), sector 1 is GPT
 table and then sectors 2-33 have GPT partition table entries, so the first
 possible data sector is 34 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Fri, 13 Jul 2018 18:44:23 +0300
Toomas Soome  wrote:

> > On 13 Jul 2018, at 17:44, O. Hartmann  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Fri, 13 Jul 2018 14:26:51 +0300
> > Toomas Soome mailto:tso...@me.com>> schrieb:
> >   
> >>> On 13 Jul 2018, at 14:00, O. Hartmann  wrote:
> >>> 
> >>> The problem is some kind of weird. I face UEFI boot problems on GPT drives
> >>> where the first partition begins at block 40 of the hdd/ssd.
> >>> 
> >>> I have two host in private use based on an
> >>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket
> >>> LGA1155). Both boards are equipted with the lates official available AMI
> >>> firmware revision, dating to 2013. This is for the Z77-Pro4-M revision
> >>> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both
> >>> boards a BETA revision for the Spectre/Meltdown mitigation is available,
> >>> but I didn't test that. But please read.
> >>> 
> >>> The third box I realised this problem is a brand new Fujitsu Esprimo
> >>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date
> >>> 05/25/2018 (or 20180525).
> >>> 
> >>> Installing on any kind of HDD or SSD manually or via bsdinstall the OS
> >>> using UEFI-only boot method on a GPT partitioned device fails. The ASRock
> >>> boards jump immediately into the firmware, the Fujitsu offers some kind
> >>> of CPU/Memory/HDD test facility.
> >>> 
> >>> If on both type of vendor/boards CSM is disabled and UEFI boot only is
> >>> implied, the MBR partitioned FreeBSD installation USB flash device does
> >>> boot in UEFI! I guess I can assume this when the well known clumsy 80x25
> >>> char console suddenly gets bright and shiny with a much higher resoltion
> >>> as long the GPU supports EFI GOP. Looking with gpart at the USB flash
> >>> drives reveals that the EFI partition starts at block 1 of the device and
> >>> the device has a MBR layout. I haven't found a way to force the GPT
> >>> scheme, when initialised via gpart, to let the partitions start at block
> >>> 1. This might be a naiv thinking, so please be patient with me.
> >>> 
> >>> I do not know whether this is a well-known issue. On the ASRock boards, I
> >>> tried years ago some LinuxRed Hat and Suse with UEFI and that worked -
> >>> FreeBSD not. I gave up on that that time. Now, having the very same
> >>> issues with a new Fujitsu system, leaves me with the impression that
> >>> FreeBSD's UEFI implementation might have problems I'm not aware of.
> >>> 
> >>> Can someone shed some light onto this? 
> >>>   
> >> 
> >> The first thing to check is if the secure boot is disabled. We do not
> >> support secure boot at all at this time.  
> > 
> > Secure boot is in every scenario disabled!
> >   
> >> 
> >> If you have efi or bios version running - you can check from either
> >> console variable value (it can have efi or vidconsole or comconsole) or
> >> better yet, see if efi-version is set (show efi-version) - if efi-version
> >> is not set, it is BIOS loader running. Another indirect way is to see
> >> lsdev -v, with device paths present, it is uefi:)  
> > 
> > What are you talking about?
> > What is the point of entry - running system, loader?
> > 
> > sysct machdep.bootmethod: BIOS
> > 
> > This makes me quite sure that the system has booted via BIOS - as I'm sure
> > since I've checked that many times. UEFI doesn't work on those systems with
> > FreeBSD. I'm not sure antmore, but I tried also Windows 7 on those
> > mainboards booting via UEFI - and I might recall that they failed also. I
> > also recall that there were issues with earlier UEFI versions regarding
> > booting only Windows 8/8.1 - and nothing else, but the fact that Linux
> > worked confuses me a bit.
> > 
> > If this ASRock crap (never ever again this brand!) doesn't work at all -
> > who cares, I intend to purchase new server grade hardware. But the more
> > puzzling issue is with the Fujitsu, which I consider serious and from the
> > behaviour the Fujitsu failure looks exactly like the ASRock - Windows 7
> > works, RedHat 7.5 works (I assume I can trust the Firmware settings when I
> > disable CSM support, that the Firmware will only EFI/UEFI capable loader?
> > Or is there a ghosty override somwhere to be expected?). Also on ASRock
> > disabling CSM should ensure not booting a dual-bootstrap-capable system.
> > This said, on the recent Fujitsu, it seems to boil down to a FreeBSD
> > UEFI-firmware interaction problem, while the ASRock is still under
> > suspicion to be broken by design. 
> >> 
> >> GPT partitions can never start from disk absolute sector 1; this is
> >> because at sector 0 there is MBR (for compatibility), sector 1 is GPT
> >> table and then sectors 2-33 have GPT partition table entries, so the first
> >> possible data sector is 34 (absolute 34). Thats assuming 512B sectors.
> >> For details see UEFI 2.7 Chapter 5.3.1 page 131.  
> > 
> > Thanks for the explanation. That implies the installer