Re: "make hierarchy" from main tree breaks c++ headers on older branches with unclear errors if "make install world" is interrupted

[Enji Cooper]

> On May 31, 2023, at 2:06 AM, Dimitry Andric  wrote:
> 
> On 31 May 2023, at 01:07, Enji Cooper  > wrote:

…

>> That’s a fair point, however, given that this follows the standard 
>> installation workflow…
>> 1. etcupdate pre-run.
>> 2. install kernel
>> 3. reboot
>> 4. make installworld
>> 5. etcupdate post-run
>> … this could surprise end-users. In particular, the C++ compiler will be 
>> broken between step 1 and step 4.
> 
> How so? The deletion of the old __string file is done as part of 
> installworld, i.e. in step 4, not in any of the earlier steps. The only case 
> where you can have problems is when you start installworld, let it run until 
> it has completed its distrib-cleanup target, and then interrupt it before it 
> can install the new headers.

No wait — you’re right. The directories aren’t created until “make 
installworld” is run so this is a short-lived issue — it impacts folks who run 
“make hierarchy” out of band, but we’re an extreme exception, not the norm.
Thanks for helping me figure this out :).
Cheers,
-Enji


signature.asc
Description: Message signed with OpenPGP

Call for 2023Q2 status reports

[Lorenzo Salvadore]

Dear FreeBSD Community,

The deadline for the next FreeBSD Status Report update is
June, 30th 2023 for work done since the last round of quarterly reports:
April 2023 - June 2023.
I would like to remind you that reports are published on a quarterly
basis and are usually collected during the last month of each quarter,
You are also welcome to submit them even earlier if you want, and the
earlier you submit them, the more time we have for reviewing.

Status report submissions do not need to be very long. They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The following methods are available to submit your reports:

* submit a review on Phabricator and add the group "status" to the
  reviewers list. You should put your reports in the directory
  doc/website/content/en/status/report-2023-04-2023-06/
  (create it if it is missing);

* submit a pull request at .
  You should put your reports in the directory
  doc/website/content/en/status/report-2023-04-2023-06/
  (create it if it is missing);

* send an email to status-submissi...@freebsd.org including your report.

An AsciiDoc template is available at
.

We look forward to seeing your 2023Q2 reports!

Thanks,

Lorenzo Salvadore (on behalf of status@)

Re: WITH_BEARSSL: -8112 bytes available

[Warner Losh]

On Wed, May 31, 2023 at 1:30 PM Gary Jennejohn  wrote:

> On Wed, 31 May 2023 12:15:12 -0600
> Warner Losh  wrote:
>
> [SNIP irrelevant text]
>
> > And no, I really do not want to support 'loadable modules'. BIOS booting
> is
> > on the way out, and people
> > that want to do complex stuff in the boot loader will simply have to do
> > that in UEFI or maybe kboot/LinuxBoot.
>
> So, what exactly does "BIOS booting is on the way out" mean?  I have four
> computers which use BIOS booting.  Three are too old to support UEFI and
> the other one I simply set to BIOS booting out of habit.
>

New computers aren't supporting it. Its days are numbered. It's longevity is
much shorter than UEFI's. These are all indisputable. I'm not planning on
dropping it in 15, but the number of people that are using it is a declining
group over time. Time spent making EFI more effective will affect more
people. That's what I mean. So I don't want to sink a ton of time into it.


> The only computer I have which uses UEFI is a laptop which was already
> set up to use UEFI and I was too lazy to change it.
>
> > There's low RoI on adding this complexity, imho. We'd be better off,
> imho,
> > making things like the graphics
> > console optional since the fonts and code for that free up about 30k in
> > stupid experiments that I've done
> > (it's hard since vidconsole has a lot of calls into the graphics system
> > that aren't optional and easy to disable,
> > so I've had to do hack and slash to produce a super ugly result that is
> > only suggestive of the final savings):
> > -rw-r--r--  1 imp  imp  352256 May 31 12:04 loader_simp
> > I don't know if I slashed too much, or not enough since the code is
> rather
> > hard to separate out, so if you
> > really wanted to go down this path, it would take a lot of work and
> patient
> > understanding to make it so with
> > the low end of savings 20k and the high end on the order of maybe 40k.
> >
> > There's likely other ways to conserve space. We've not had space issues
> > with loader, et al, in the past,
> > so it's not well setup for subsetting. Though the different filesystem
> > support might also net you a fair amount:
> > LOADER_NET_SUPPORT?=yes
> > LOADER_NFS_SUPPORT?=yes
> > LOADER_TFTP_SUPPORT?=   yes
> > LOADER_CD9660_SUPPORT?= yes
> > LOADER_EXT2FS_SUPPORT?= yes
> > LOADER_MSDOS_SUPPORT?=  yes
> > LOADER_UFS_SUPPORT?=yes
> > LOADER_GZIP_SUPPORT?=   yes
> > LOADER_BZIP2_SUPPORT?=  yes
> > as would compiling w/o ZFS, which uses its own method (eg
> > WITHOUT_LOADER_ZFS). Tuning the loader
> > at this level does start to get into the weeds a bit, but can offer ~40k
> > savings turning off all but NET and UFS:
> > -rw-r--r--  1 imp  imp  344064 May 31 12:11 loader_simp
> > you get even about ~100k when you disable ZFS support with
> > -DWITHOUT_LOADER_ZFS:
> > -rw-r--r--  1 imp  imp  241664 May 31 12:12 loader_simp
> > (both of these are with the graphics console enabled without the silly
> > hacks to see how much that takes up).
> > Without the extras and ZFS, you might have bearssl and lua together
> even...
> >
> > Hope this helps.
> >
>
> This is interesting information.
>

Thanks!

Warner

Re: WITH_BEARSSL: -8112 bytes available

[Simon J. Gerraty]

> the loader program. You may also have to disable the lua build, since it uses 
> more stack and is just a smidge
> larger than the forth build. _simp will be the smallest of them
> all. On my system, without bearssl, I see:

Back when I first did the LOADER_VERIEXEC bits, I found lua
pushed things over the edge.
We use 4th anyway, and will likely be stuck with it for another decade
at least.

> -r-xr-xr-x  3 root  wheel  503808 May 22 15:25 /boot/loader_lua
> -r-xr-xr-x  1 root  wheel  446464 May 22 15:25 /boot/loader_4th
> -r-xr-xr-x  1 root  wheel  385024 May 22 15:25 /boot/loader_simp
> which suggests a ~60k bump for adding forth and ~115k bump for lua. So the 
> 560,000 may need to be 625,000
> which is living life on the edge for 4th, and simply too big for lua.
> 
> I'd be open to adding docs on this, since I don't think this option is 
> currently documented since I added it
> to experiment around with a good value.

My own experiments found somewhere around 550k to  be the limit.

> And no, I really do not want to support 'loadable modules'. BIOS
> booting is on the way out, and people 
> that want to do complex stuff in the boot loader will simply have to
> do that in UEFI or maybe kboot/LinuxBoot. 
> There's low RoI on adding this complexity, imho. We'd be better off,
> imho, making things like the graphics 
> console optional since the fonts and code for that free up about 30k
> in stupid experiments that I've done

Yes. For those of us with serial only consoles, the graphics stuff is
pure overhead.

> Without the extras and ZFS, you might have bearssl and lua together even...

FWIW our i386 loader with BEARSSL and LOADER_VERIEXEC and 4th rather
than lua is 312K I can get that down to 308K by dropping
LOADER_EXT2FS_SUPPORT which I am pretty sure we don't need.

If I enable lua and disable 4th, the loader is still only 352K
in our stable/12 branch and 364K in main

I just did a quick test on a VM - that loader_lua was able to load
kernel ok, so looks promising.

Of course we have 8k lines of 4th that would need translating to lua
before I could be sure.

--sjg

Re: WITH_BEARSSL: -8112 bytes available

[Gary Jennejohn]

On Wed, 31 May 2023 12:15:12 -0600
Warner Losh  wrote:

[SNIP irrelevant text]

> And no, I really do not want to support 'loadable modules'. BIOS booting is
> on the way out, and people
> that want to do complex stuff in the boot loader will simply have to do
> that in UEFI or maybe kboot/LinuxBoot.

So, what exactly does "BIOS booting is on the way out" mean?  I have four
computers which use BIOS booting.  Three are too old to support UEFI and
the other one I simply set to BIOS booting out of habit.

The only computer I have which uses UEFI is a laptop which was already
set up to use UEFI and I was too lazy to change it.

> There's low RoI on adding this complexity, imho. We'd be better off, imho,
> making things like the graphics
> console optional since the fonts and code for that free up about 30k in
> stupid experiments that I've done
> (it's hard since vidconsole has a lot of calls into the graphics system
> that aren't optional and easy to disable,
> so I've had to do hack and slash to produce a super ugly result that is
> only suggestive of the final savings):
> -rw-r--r--  1 imp  imp  352256 May 31 12:04 loader_simp
> I don't know if I slashed too much, or not enough since the code is rather
> hard to separate out, so if you
> really wanted to go down this path, it would take a lot of work and patient
> understanding to make it so with
> the low end of savings 20k and the high end on the order of maybe 40k.
>
> There's likely other ways to conserve space. We've not had space issues
> with loader, et al, in the past,
> so it's not well setup for subsetting. Though the different filesystem
> support might also net you a fair amount:
> LOADER_NET_SUPPORT?=yes
> LOADER_NFS_SUPPORT?=yes
> LOADER_TFTP_SUPPORT?=   yes
> LOADER_CD9660_SUPPORT?= yes
> LOADER_EXT2FS_SUPPORT?= yes
> LOADER_MSDOS_SUPPORT?=  yes
> LOADER_UFS_SUPPORT?=yes
> LOADER_GZIP_SUPPORT?=   yes
> LOADER_BZIP2_SUPPORT?=  yes
> as would compiling w/o ZFS, which uses its own method (eg
> WITHOUT_LOADER_ZFS). Tuning the loader
> at this level does start to get into the weeds a bit, but can offer ~40k
> savings turning off all but NET and UFS:
> -rw-r--r--  1 imp  imp  344064 May 31 12:11 loader_simp
> you get even about ~100k when you disable ZFS support with
> -DWITHOUT_LOADER_ZFS:
> -rw-r--r--  1 imp  imp  241664 May 31 12:12 loader_simp
> (both of these are with the graphics console enabled without the silly
> hacks to see how much that takes up).
> Without the extras and ZFS, you might have bearssl and lua together even...
>
> Hope this helps.
>

This is interesting information.

--
Gary Jennejohn

Re: WITH_BEARSSL: -8112 bytes available

[Warner Losh]

On Mon, May 29, 2023 at 2:59 AM FreeBSD User  wrote:

> Hello,
>
> on CURRENT, enabling in /etc/src.conf
>
> WITH_BEARSSL=
>
> seems to result in a slightly enlarged loader binary, which seems to have
> a fixed size
> supposed on the error I get. See below.
>
> The system is amd64 (64 bit), for the record.
>
> Somewhere in the past developers mentioned this upcoming problem and
> provided a knob to adjust
> the used size - I forgot about that knob and I couldn't find it even in
> the loader docs - or
> looked at the wrong places.
>
> Can someone help me out here?
>
> The first error stops compileing world/kernel, but taking a second run,
> the error goes away.
>
> Kind regards and thanks in advance,
>
> oh
>
>
>
> [...]
> --- all_subdir_stand/efi ---
> SOURCE_DATE_EPOCH=1451606400  objcopy -j .peheader -j .text -j .sdata -j
> .data  -j .dynamic -j
> .dynsym -j .rel.dyn  -j .rela.dyn -j .reloc -j .eh_frame -j
> set_Xcommand_set  -j
> set_Xficl_compile_set  --output-target=efi-app-x86_64 loader_4th.sym
> loader_4th.efi ---
> all_subdir_stand/i386 ---
>
> -8112 bytes available 7.71 real12.86 user 3.08 sys


bummer. I hate it when it's that close.

You can try setting LOADERSIZE=56 in your environment. We currently set
the maximum to 550,000
bytes because that's the most conservative number due to variation in the
available BIOS space available.
This likely can be set even higher if you don't have add-in cards that are
consuming space in the lower 640k
of memory. 640k is the absolute limit, but you need 20-30k of stack for the
loader so pushing this much past
625,000 or maybe 630,000 increases the risk of run-time crashes as the
stack smashes through the top of
the loader program. You may also have to disable the lua build, since it
uses more stack and is just a smidge
larger than the forth build. _simp will be the smallest of them all. On my
system, without bearssl, I see:
-r-xr-xr-x  3 root  wheel  503808 May 22 15:25 /boot/loader_lua
-r-xr-xr-x  1 root  wheel  446464 May 22 15:25 /boot/loader_4th
-r-xr-xr-x  1 root  wheel  385024 May 22 15:25 /boot/loader_simp
which suggests a ~60k bump for adding forth and ~115k bump for lua. So the
560,000 may need to be 625,000
which is living life on the edge for 4th, and simply too big for lua.

I'd be open to adding docs on this, since I don't think this option is
currently documented since I added it
to experiment around with a good value.

And no, I really do not want to support 'loadable modules'. BIOS booting is
on the way out, and people
that want to do complex stuff in the boot loader will simply have to do
that in UEFI or maybe kboot/LinuxBoot.
There's low RoI on adding this complexity, imho. We'd be better off, imho,
making things like the graphics
console optional since the fonts and code for that free up about 30k in
stupid experiments that I've done
(it's hard since vidconsole has a lot of calls into the graphics system
that aren't optional and easy to disable,
so I've had to do hack and slash to produce a super ugly result that is
only suggestive of the final savings):
-rw-r--r--  1 imp  imp  352256 May 31 12:04 loader_simp
I don't know if I slashed too much, or not enough since the code is rather
hard to separate out, so if you
really wanted to go down this path, it would take a lot of work and patient
understanding to make it so with
the low end of savings 20k and the high end on the order of maybe 40k.

There's likely other ways to conserve space. We've not had space issues
with loader, et al, in the past,
so it's not well setup for subsetting. Though the different filesystem
support might also net you a fair amount:
LOADER_NET_SUPPORT?=yes
LOADER_NFS_SUPPORT?=yes
LOADER_TFTP_SUPPORT?=   yes
LOADER_CD9660_SUPPORT?= yes
LOADER_EXT2FS_SUPPORT?= yes
LOADER_MSDOS_SUPPORT?=  yes
LOADER_UFS_SUPPORT?=yes
LOADER_GZIP_SUPPORT?=   yes
LOADER_BZIP2_SUPPORT?=  yes
as would compiling w/o ZFS, which uses its own method (eg
WITHOUT_LOADER_ZFS). Tuning the loader
at this level does start to get into the weeds a bit, but can offer ~40k
savings turning off all but NET and UFS:
-rw-r--r--  1 imp  imp  344064 May 31 12:11 loader_simp
you get even about ~100k when you disable ZFS support with
-DWITHOUT_LOADER_ZFS:
-rw-r--r--  1 imp  imp  241664 May 31 12:12 loader_simp
(both of these are with the graphics console enabled without the silly
hacks to see how much that takes up).
Without the extras and ZFS, you might have bearssl and lua together even...

Hope this helps.

Warner

Re: PinePhone Pro Boots On CURRENT

[Gary Jennejohn]

On Wed, 31 May 2023 15:48:44 +0200
Mario Marietto  wrote:

> ---> Android remains the OS for the phone.
>
> I'm not sure but I see that he talks even about Linux as main os that can
> be installed on the phone
>

No, Linux is installed in a chroot.  So it's not replacing Android.

See chroot(2) and chroot(8).

The developer used Linux Deploy, an app from Google, which creates a
chroot on a SD card and copies Linux to it.  Since Android only supports
FAT32 that means that the Linux distribution has to be smaller than 4GiB
(about 4.295 billion bytes).

Would be nice if there were an app like that for FreeBSD.

> ---> FreeBSD does not have the required proprietary driver blobs which are
> used by Android and I greatly doubt
> that FreeBSD running in a KVM will have access to all (or any) of these
> hardware elements.
>
> This is true. But AFAIK qemu can provide the missing software
> components replacing
> them with the virtual ones.
>

I can't imagine how that could work without the proprietary driver blobs.

There are lots of drivers in the source tree, but based on the names
it's difficult to tell just which hardware is supported.  Not clear
whether the modem is in the tree or a driver blob is required.

--
Gary Jennejohn

Re: PinePhone Pro Boots On CURRENT

[Mario Marietto]

---> Android remains the OS for the phone.

I'm not sure but I see that he talks even about Linux as main os that can
be installed on the phone

---> FreeBSD does not have the required proprietary driver blobs which are
used by Android and I greatly doubt
that FreeBSD running in a KVM will have access to all (or any) of these
hardware elements.

This is true. But AFAIK qemu can provide the missing software
components replacing
them with the virtual ones.

On Wed, May 31, 2023 at 3:35 PM Gary Jennejohn  wrote:

> On Wed, 31 May 2023 12:00:43 +0200
> Mario Marietto  wrote:
>
> > ---> No, with this you cannot replace Android with Linux.  This hack
> merely
> > provides a way to run a different OS in a KVM.
> >
> > ok,but what do I see as soon as I have flashed the boot.img to the phone
> > with odin ? can I virtualize freebsd,right ? What tool can I use in
> FreeBSD
> > to place phone calls and to send sms ? because this is what I want to
> do. A
> > freeBSD powered phone.
> >
>
> You'll see the hacked Android version which the developer has provided.
>
> Android remains the OS for the phone.  FreeBSD does not have the requiired
> proprietary driver blobs which are used by Android and I greatly doubt
> that FreeBSD running in a KVM will have access to all (or any) of the
> these hardware elements.
>
> Click on raspiduino/a6lte-kvm in the upper left corner of the github
> link.  This will take you to the source repository which has a long
> document about his hack.  Read it.
>
> [SNIP]
>
> --
> Gary Jennejohn
>


-- 
Mario.

Re: PinePhone Pro Boots On CURRENT

[Gary Jennejohn]

On Wed, 31 May 2023 12:00:43 +0200
Mario Marietto  wrote:

> ---> No, with this you cannot replace Android with Linux.  This hack merely
> provides a way to run a different OS in a KVM.
>
> ok,but what do I see as soon as I have flashed the boot.img to the phone
> with odin ? can I virtualize freebsd,right ? What tool can I use in FreeBSD
> to place phone calls and to send sms ? because this is what I want to do. A
> freeBSD powered phone.
>

You'll see the hacked Android version which the developer has provided.

Android remains the OS for the phone.  FreeBSD does not have the requiired
proprietary driver blobs which are used by Android and I greatly doubt
that FreeBSD running in a KVM will have access to all (or any) of the
these hardware elements.

Click on raspiduino/a6lte-kvm in the upper left corner of the github
link.  This will take you to the source repository which has a long
document about his hack.  Read it.

[SNIP]

--
Gary Jennejohn

Re: Surprise null root password

[David Chisnall]

On 30/05/2023 20:11, Dag-Erling Smørgrav wrote:

David Chisnall  writes:

There was a very nasty POLA violation a release or two ago.  OpenSSH
defaults to disallowing empty passwords and so having a null password
was a convenient way of allowing people to su or locally log into that
user but disallowing ssh.  This option does not work in recent
versions of FreeBSD.  Turning on the option to permit root login while
keeping the root password blank used to be (mostly) safe because it
permitted su to root from people in the wheel group, root login via
SSH key remotely (for ‘everything is broken I can’t log in as a user
whose home directory is not on the root filesystem’ recovery) and
local login as root from consoles marked as secure.  It now permits
root login from the network with a blank password.

That is incorrect.  PermitRootLogin defaults to “no” in FreeBSD and to
“prohibit-password” upstream (and presumably in the port), while
PermitEmptyPasswords defaults to “no” both in FreeBSD and upstream,
cf. crypto/openssh/servconf.c (search for “permit_root” and
“permit_empty”).


I didn't say it defaulted to anything else, but if you enable 
PermitRootLogin then you have a nasty surprise because 
PermitEmptyPasswords=no does not do anything and you can still log in 
via an empty password.


There is presumably something I can put in pam.d that will prevent 
password-based login (without fully disabling keyboard-interactive from 
sshd_config) but I have never successfully understood anything after 
reading the PAM documentation.


David

Re: PinePhone Pro Boots On CURRENT

[Mario Marietto]

---> No, with this you cannot replace Android with Linux.  This hack merely
provides a way to run a different OS in a KVM.

ok,but what do I see as soon as I have flashed the boot.img to the phone
with odin ? can I virtualize freebsd,right ? What tool can I use in FreeBSD
to place phone calls and to send sms ? because this is what I want to do. A
freeBSD powered phone.


On Wed, May 31, 2023 at 11:30 AM Gary Jennejohn  wrote:

> On Tue, 30 May 2023 20:50:52 +0200
> Mario Marietto  wrote:
>
> > Check at this,also : https://github.com/raspiduino/a6lte-kvm/releases
> >
>
> This would definitely be the best approach, since the developer has already
> tested Linux in the KVM.
>
> Odin, which I've used to install custom ROMs from xda, is a Windows
> program.
> If you have Windows then this would be a way to do the installation.
>
> The developer also mentions using Heimdall under Linux.  There's a Heimdall
> port for FreeBSD, so that might also be an option.
>
> > What I would like to know is if I can install Linux as the main
> OS,instead
> > of Android. Thanks.
> >
>
> No, with this you cannot replace Android with Linux.  This hack merely
> provides a way to run a different OS in a KVM.
>
> [SNIP]
>
> --
> Gary Jennejohn
>


-- 
Mario.

Re: PinePhone Pro Boots On CURRENT

[Gary Jennejohn]

On Tue, 30 May 2023 20:50:52 +0200
Mario Marietto  wrote:

> Check at this,also : https://github.com/raspiduino/a6lte-kvm/releases
>

This would definitely be the best approach, since the developer has already
tested Linux in the KVM.

Odin, which I've used to install custom ROMs from xda, is a Windows program.
If you have Windows then this would be a way to do the installation.

The developer also mentions using Heimdall under Linux.  There's a Heimdall
port for FreeBSD, so that might also be an option.

> What I would like to know is if I can install Linux as the main OS,instead
> of Android. Thanks.
>

No, with this you cannot replace Android with Linux.  This hack merely
provides a way to run a different OS in a KVM.

[SNIP]

--
Gary Jennejohn

Re: "make hierarchy" from main tree breaks c++ headers on older branches with unclear errors if "make install world" is interrupted

[Dimitry Andric]

On 31 May 2023, at 01:07, Enji Cooper  wrote:
> 
>> On May 28, 2023, at 3:53 AM, Dimitry Andric  wrote:
>> On 28 May 2023, at 07:18, Enji Cooper  wrote:
>>> 
>>> I just tried to run “make hierarchy” from a main tree on a 13.2-RELEASE 
>>> system, and doing so completely broke my headers.
>>> It took me about 30 minutes to figure out what happened… 
>>> /usr/include/c++/v1/__string was a header, whereas on :main it’s a 
>>> directory?!
>> 
>> Yes, upstream libc++ has split up large headers into multiple components, in 
>> particular __string and __type_traits.
>> 
>> Since we had a file named __string, it had to be somehow replaced by a 
>> directory. This is what the distrib-cleanup target in the top-level Makefile 
>> does:
>> 
>> https://github.com/DimitryAndric/freebsd-src/commit/6b13b4a095e3
>> 
>> Afterwards, the replacement directory named __string is created as part of 
>> the regular mtree commands.
>> 
>> 
>> ...
>>> I reinstalled the headers by going to lib/libc++ in my releng/13.2 tree, 
>>> building, and installing all of the 13.2-RELEASE headers.
>>> This change has been live for almost a year now on :main — is this a known 
>>> caveat when doing a source-based upgrade from 13.2-RELEASE* to 
>>> 14.0-CURRENT, i.e., that the installworld (if interrupted) could break the 
>>> c++ compiler?
>> 
>> I think it should already be quite clear that interrupting installworld is 
>> risky. If you were just in the middle of replacing libc or rtld, and those 
>> were half-written, your system will be completely hosed. (I am speaking from 
>> experience. :) The same goes for any system headers or libraries, not only 
>> the C++ ones. If you have a half-installed tree, it should not be used for 
>> anything except attempting another installworld.
> 
> That’s a fair point, however, given that this follows the standard 
> installation workflow…
> 1. etcupdate pre-run.
> 2. install kernel
> 3. reboot
> 4. make installworld
> 5. etcupdate post-run
> … this could surprise end-users. In particular, the C++ compiler will be 
> broken between step 1 and step 4.

How so? The deletion of the old __string file is done as part of installworld, 
i.e. in step 4, not in any of the earlier steps. The only case where you can 
have problems is when you start installworld, let it run until it has completed 
its distrib-cleanup target, and then interrupt it before it can install the new 
headers.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Surprise null root password

[Alexander Leidinger]

Quoting bob prohaska  (from Tue, 30 May 2023  
08:36:21 -0700):



I suggest to review changes ("df" instead of "tf" in etcupdate) to at least
those files which you know you have modified, including the password/group
stuff. After that you can decide if the diff which is shown with "df" can be
applied ("tf"), or if you want to keep the old version ("mf"), or if you
want to modify the current file ("e", with both versions present in the file
so that you can copy/paste between the different versions and keep what you
need).



The key sequences required to copy and paste between files in the edit screen
were elusive. Probably it was thought self-evident, but not for me.  
I last tried
it long ago, via mergemaster. Is there is a guide to commands for  
merging files

using /etcupdate? Is it in the vi man page? I couldn't find it.


etcupdate respects the EDITOR env-variable. You can use any editor you  
like there.


Typically I use the mouse to copy myself and google every time I  
can't (https://linuxize.com/post/how-to-copy-cut-paste-in-vim/).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgp4RaBvVQJjb.pgp
Description: Digitale PGP-Signatur