Re: Surprise null root password
On May 30, 2023, at 18:39, bob prohaska wrote:
> On Tue, May 30, 2023 at 11:02:13AM -0700, Mark Millard wrote:
>> bob prohaska wrote on
>> Date: Tue, 30 May 2023 15:36:21 UTC :
>>
>>> On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
Quoting bob prohaska (from Fri, 26 May 2023 16:26:06
-0700):
> On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
>>
>> The question is how you update the configuration files,
>> mergemaster/etcupdate/something else?
>>
>
> Via etcupdate after installworld. In the event the system
> requests manual intervention I accept "theirs all". It seems
> odd if that can null a root password.
>
> Still, it does seem an outside possibility. I could see it adding
> system users, but messing with root's existing password seems a
> bit unexpected.
As you are posting to -current@, I expect you to report this issue about
14-current systems. As such: there was a "recent" change (2021-10-20) to
the
root entry to change the shell.
https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
By blindly accepting all changes, this has reset the PW to the default
setting (empty).
>>>
>>> So it's a line-by-line merge. That's the most sensible explanation
>>> available.
>>>
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.
>>
>> # man etcpudate
>> . . .
>> CONFIG FILE
>> The etcupdate utility can also be configured by setting variables in an
>> optional configuration file named /etc/etcupdate.conf. Note that command
>> line options override settings in the configuration file. The
>> configuration file is executed by sh(1), so it uses that syntax to set
>> configuration variables. The following variables can be set:
>>
>> . . .
>>
>> EDITOR Specify a program to edit merge conflicts.
>> . . .
>> ENVIRONMENT
>> The etcupdate utility uses the program identified in the EDITOR
>> environment variable to edit merge conflicts. If EDITOR is not set,
>> vi(1) is used as the default editor.
>>
>>
>>
>> So, if you do not want to use vi, you can use either the EDITOR
>> environment variable or an EDITOR assignment in
>> /etc/etcupdate.conf to change what editor etcupdate uses for
>> you to edit merge conflicts with.
>
> My difficulty is precisely a lack of skill with vi, which I've
> used and cursed since starting with 386BSD. Evidently I'm a slow
> learner I tried other editors, but vi is the only one always
> available.
Well, there is ed ( and red ). But also built into FreeBSD is:
ee ( and ree ). Beyond that you might have to install something.
But if "always available" means across operating systems and
built-in, instead of needing to be installed, it may be the
most common for unixish contexts. But, as I understand, some
Linux based OS's do not include (any variant of) vi, having
things like, say, nano instead. Some variant of vi would be
an install in such cases.
I went something like 25 years between usage of vi and could do
basic activity right off the bat. (Not that I was sure such would
be true when I first had to edit via whatever editor I could find
pre-installed at the time.) It is the only non-GUI editor for
which such a thing has been true. Why it stuck so well, I do not
know.
An odd thing about this is that before the 25 year interval, my
primary editor expertise was using TECO, including tailoring its
interactive use. At this point, I only remember the name.
> For the moment, etcupgrade isn't asking for manual intervention.
> When it next does I'll pay closer attention and ask better questions.
>
===
Mark Millard
marklmi at yahoo.com
Re: Surprise null root password
On Tue, May 30, 2023 at 11:02:13AM -0700, Mark Millard wrote:
> bob prohaska wrote on
> Date: Tue, 30 May 2023 15:36:21 UTC :
>
> > On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
> > >
> > > Quoting bob prohaska (from Fri, 26 May 2023 16:26:06
> > > -0700):
> > >
> > > > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > > > >
> > > > > The question is how you update the configuration files,
> > > > > mergemaster/etcupdate/something else?
> > > > >
> > > >
> > > > Via etcupdate after installworld. In the event the system
> > > > requests manual intervention I accept "theirs all". It seems
> > > > odd if that can null a root password.
> > > >
> > > > Still, it does seem an outside possibility. I could see it adding
> > > > system users, but messing with root's existing password seems a
> > > > bit unexpected.
> > >
> > > As you are posting to -current@, I expect you to report this issue about
> > > 14-current systems. As such: there was a "recent" change (2021-10-20) to
> > > the
> > > root entry to change the shell.
> > > https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
> > >
> > > By blindly accepting all changes, this has reset the PW to the default
> > > setting (empty).
> >
> > So it's a line-by-line merge. That's the most sensible explanation
> > available.
> >
> > >
> > > 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.
>
> # man etcpudate
> . . .
> CONFIG FILE
> The etcupdate utility can also be configured by setting variables in an
> optional configuration file named /etc/etcupdate.conf. Note that command
> line options override settings in the configuration file. The
> configuration file is executed by sh(1), so it uses that syntax to set
> configuration variables. The following variables can be set:
>
> . . .
>
> EDITOR Specify a program to edit merge conflicts.
> . . .
> ENVIRONMENT
> The etcupdate utility uses the program identified in the EDITOR
> environment variable to edit merge conflicts. If EDITOR is not set,
> vi(1) is used as the default editor.
>
>
>
> So, if you do not want to use vi, you can use either the EDITOR
> environment variable or an EDITOR assignment in
> /etc/etcupdate.conf to change what editor etcupdate uses for
> you to edit merge conflicts with.
My difficulty is precisely a lack of skill with vi, which I've
used and cursed since starting with 386BSD. Evidently I'm a slow
learner I tried other editors, but vi is the only one always
available.
For the moment, etcupgrade isn't asking for manual intervention.
When it next does I'll pay closer attention and ask better questions.
Thanks to you in particular and everybody else who has helped!
bob prohaska
Re: "make hierarchy" from main tree breaks c++ headers on older branches with unclear errors if "make install world" is interrupted
> 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. It would be good to bring this fact up in UPDATING or RELNOTES as a warning because it could result in a broken system that’s difficult to recover from. Cheers, -Enji signature.asc Description: Message signed with OpenPGP
Re: Surprise null root password
W dniu 26.05.2023 o 19:35, bob prohaska pisze:
While going through normal security email from a Pi2
running -current I was disturbed to find:
Checking for passwordless accounts:
root::0:0::0:0:Charlie &:/root:/bin/sh
This thread reminded me of another issue with passwords I encountered a
few years ago.
Setting stronger passwords by users can be enforced by pam_passwdqc(8).
But if the password expiration policy is enabled, it doesn't work since
the password change for expired passwords is called by ssh or login PAM
module, thus to enforce stronger passwords for users with passwords
expired pam_passwdqc should be added also to both:
/etc/pam.d/{login,sshd}, otherwise user with an expired password just
presses return twice during the login prompt and has an empty password
set. I even have risen D27656 some time ago, but it had gained not much
interest except for some rephrasing/grammar advice.
So to use a password expiration policy and enforce high-quality
passwords together, pam_passwdqc(8) has to activated in the three:
/etc/pam.d/{login,passwd,sshd}.
Cheers
--
Marek Zarychta
Re: Surprise null root password
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”). DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: PinePhone Pro Boots On CURRENT
Check at this,also : https://github.com/raspiduino/a6lte-kvm/releases What I would like to know is if I can install Linux as the main OS,instead of Android. Thanks. On Tue, May 30, 2023 at 8:31 PM Mario Marietto wrote: > My idea is to patch the kernel with this patch : > > https://github.com/sleirsgoevy/exynos-kvm-patch > > in the worst case scenario, I will virtualize FreeBSD with qemu + kvm on > top of Android. > > On Tue, May 30, 2023 at 8:20 PM Gary Jennejohn wrote: > >> On Tue, 30 May 2023 15:02:38 +0200 >> Mario Marietto wrote: >> >> > That's interesting. As I have already said,I haven't bought the >> pinephone >> > pro,because it is expensive for me. So I'm working on a parallel >> project. >> > I've bought this phone,instead : >> > >> > https://www.hdblog.it/schede-tecniche/samsung-galaxy-a6_i3655/ >> > >> > That's cheaper. Between the specs I read that it has a mali gpu,too : >> > Mali-T830MP2 >> > >> > so,eventually,I can use the Lima and the PanFrost driver even for my >> > samsung galaxy A6 ? I've started planning to install FreeBSD on top of >> the >> > Android Kernel,using a specific patch,but now I'm thinking that maybe,I >> can >> > install FreeBSD there natively. Can someone tell me if it is >> doable,giving >> > a look at the specs of that phone model ? thanks. >> > >> >> Based on my experience with Samsung it probably won't be a simple task. >> >> Samsung tends to block the bootloader such that it's very difficult to >> install anything but Android. >> >> https://www.xda-developers.com/ has a fair amount of info on the A6. It >> could be worth your while to take a look at what's there. >> >> -- >> Gary Jennejohn >> > > > -- > Mario. > -- Mario.
Re: PinePhone Pro Boots On CURRENT
My idea is to patch the kernel with this patch : https://github.com/sleirsgoevy/exynos-kvm-patch in the worst case scenario, I will virtualize FreeBSD with qemu + kvm on top of Android. On Tue, May 30, 2023 at 8:20 PM Gary Jennejohn wrote: > On Tue, 30 May 2023 15:02:38 +0200 > Mario Marietto wrote: > > > That's interesting. As I have already said,I haven't bought the pinephone > > pro,because it is expensive for me. So I'm working on a parallel project. > > I've bought this phone,instead : > > > > https://www.hdblog.it/schede-tecniche/samsung-galaxy-a6_i3655/ > > > > That's cheaper. Between the specs I read that it has a mali gpu,too : > > Mali-T830MP2 > > > > so,eventually,I can use the Lima and the PanFrost driver even for my > > samsung galaxy A6 ? I've started planning to install FreeBSD on top of > the > > Android Kernel,using a specific patch,but now I'm thinking that maybe,I > can > > install FreeBSD there natively. Can someone tell me if it is > doable,giving > > a look at the specs of that phone model ? thanks. > > > > Based on my experience with Samsung it probably won't be a simple task. > > Samsung tends to block the bootloader such that it's very difficult to > install anything but Android. > > https://www.xda-developers.com/ has a fair amount of info on the A6. It > could be worth your while to take a look at what's there. > > -- > Gary Jennejohn > -- Mario.
Re: PinePhone Pro Boots On CURRENT
On Tue, 30 May 2023 15:02:38 +0200 Mario Marietto wrote: > That's interesting. As I have already said,I haven't bought the pinephone > pro,because it is expensive for me. So I'm working on a parallel project. > I've bought this phone,instead : > > https://www.hdblog.it/schede-tecniche/samsung-galaxy-a6_i3655/ > > That's cheaper. Between the specs I read that it has a mali gpu,too : > Mali-T830MP2 > > so,eventually,I can use the Lima and the PanFrost driver even for my > samsung galaxy A6 ? I've started planning to install FreeBSD on top of the > Android Kernel,using a specific patch,but now I'm thinking that maybe,I can > install FreeBSD there natively. Can someone tell me if it is doable,giving > a look at the specs of that phone model ? thanks. > Based on my experience with Samsung it probably won't be a simple task. Samsung tends to block the bootloader such that it's very difficult to install anything but Android. https://www.xda-developers.com/ has a fair amount of info on the A6. It could be worth your while to take a look at what's there. -- Gary Jennejohn
Re: Surprise null root password
bob prohaska wrote on
Date: Tue, 30 May 2023 15:36:21 UTC :
> On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
> >
> > Quoting bob prohaska (from Fri, 26 May 2023 16:26:06
> > -0700):
> >
> > > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > > >
> > > > The question is how you update the configuration files,
> > > > mergemaster/etcupdate/something else?
> > > >
> > >
> > > Via etcupdate after installworld. In the event the system
> > > requests manual intervention I accept "theirs all". It seems
> > > odd if that can null a root password.
> > >
> > > Still, it does seem an outside possibility. I could see it adding
> > > system users, but messing with root's existing password seems a
> > > bit unexpected.
> >
> > As you are posting to -current@, I expect you to report this issue about
> > 14-current systems. As such: there was a "recent" change (2021-10-20) to the
> > root entry to change the shell.
> > https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
> >
> > By blindly accepting all changes, this has reset the PW to the default
> > setting (empty).
>
> So it's a line-by-line merge. That's the most sensible explanation available.
>
> >
> > 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.
# man etcpudate
. . .
CONFIG FILE
The etcupdate utility can also be configured by setting variables in an
optional configuration file named /etc/etcupdate.conf. Note that command
line options override settings in the configuration file. The
configuration file is executed by sh(1), so it uses that syntax to set
configuration variables. The following variables can be set:
. . .
EDITOR Specify a program to edit merge conflicts.
. . .
ENVIRONMENT
The etcupdate utility uses the program identified in the EDITOR
environment variable to edit merge conflicts. If EDITOR is not set,
vi(1) is used as the default editor.
So, if you do not want to use vi, you can use either the EDITOR
environment variable or an EDITOR assignment in
/etc/etcupdate.conf to change what editor etcupdate uses for
you to edit merge conflicts with.
===
Mark Millard
marklmi at yahoo.com
Re: PinePhone Pro Boots On CURRENT
On 5/30/23 6:02 AM, Mario Marietto wrote: That's interesting. As I have already said,I haven't bought the pinephone pro,because it is expensive for me. So I'm working on a parallel project. I've bought this phone,instead : https://www.hdblog.it/schede-tecniche/samsung-galaxy-a6_i3655/ That's cheaper. Between the specs I read that it has a mali gpu,too : Mali-T830MP2 so,eventually,I can use the Lima and the PanFrost driver even for my samsung galaxy A6 ? I've started planning to install FreeBSD on top of the Android Kernel,using a specific patch,but now I'm thinking that maybe,I can install FreeBSD there natively. Can someone tell me if it is doable,giving a look at the specs of that phone model ? thanks. have you tried putting a snapshot from CURRENT on a memory card and booting it? i'm not familiar with that device, but i suspect you'd need serial console access. -pete
Re: Surprise null root password
On Tue, May 30, 2023 at 8:36 AM bob prohaska wrote:
>
> On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
> >
> > Quoting bob prohaska (from Fri, 26 May 2023 16:26:06
> > -0700):
> >
> > > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > > >
> > > > The question is how you update the configuration files,
> > > > mergemaster/etcupdate/something else?
> > > >
> > >
> > > Via etcupdate after installworld. In the event the system
> > > requests manual intervention I accept "theirs all". It seems
> > > odd if that can null a root password.
> > >
> > > Still, it does seem an outside possibility. I could see it adding
> > > system users, but messing with root's existing password seems a
> > > bit unexpected.
> >
> > As you are posting to -current@, I expect you to report this issue about
> > 14-current systems. As such: there was a "recent" change (2021-10-20) to the
> > root entry to change the shell.
> > https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
> >
> > By blindly accepting all changes, this has reset the PW to the default
> > setting (empty).
>
> So it's a line-by-line merge. That's the most sensible explanation available.
>
> >
> > 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.
>
> Thanks for writing!
>
> bob prohaska
>
>
It's been a while for me so I forget if etcupdate resolve is automatic
or there is a prompt or message about it, but the guide at
https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-completing-merge-etcupdate
says:
If etcupdate(8) is not able to merge a file automatically, the merge
conflicts can be resolved with manual interaction by issuing:
# etcupdate resolve
But this info is far below the steps at
https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-quick-start
with section 25.6.6.1 also not being mentioned in the steps.
Info on merge commands, regardless, is under the Resolve Mode
description in the etcupdate man page
https://man.freebsd.org/cgi/man.cgi?etcupdate.
Re: Surprise null root password
On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
>
> Quoting bob prohaska (from Fri, 26 May 2023 16:26:06
> -0700):
>
> > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > >
> > > The question is how you update the configuration files,
> > > mergemaster/etcupdate/something else?
> > >
> >
> > Via etcupdate after installworld. In the event the system
> > requests manual intervention I accept "theirs all". It seems
> > odd if that can null a root password.
> >
> > Still, it does seem an outside possibility. I could see it adding
> > system users, but messing with root's existing password seems a
> > bit unexpected.
>
> As you are posting to -current@, I expect you to report this issue about
> 14-current systems. As such: there was a "recent" change (2021-10-20) to the
> root entry to change the shell.
> https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
>
> By blindly accepting all changes, this has reset the PW to the default
> setting (empty).
So it's a line-by-line merge. That's the most sensible explanation available.
>
> 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.
Thanks for writing!
bob prohaska
Re: PinePhone Pro Boots On CURRENT
Someone is reading what I'm writing ? I'm not sure because it seems that my messages are totally ignored. On Tue, May 30, 2023 at 4:39 PM Pete Wright wrote: > > > On 5/30/23 05:19, Stephan Lichtenauer wrote: > > > >> > >> But, once i get the linux DTB for this guy into a disk image i'm > >> going to see if i can get the display up next, but would love to hear > >> any input or pointers from folks with more ARM porting experience > >> than me. > > > > I am probably telling you something you already know, but afaik the > > Pinephone Pro uses the Rockchip RK3399 which according to the > > datasheet > > ( > https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf > > page 16, 1.2.9 Graphics Engine) contains a Mali GPU. > > > > That means Ruslan Bukin's Panfrost article in the FreeBSD Journal > > Jul/Aug 2021 at > > > https://freebsdfoundation.org/wp-content/uploads/2021/08/The-Panfrost-Driver.pdf > > might be interesting regarding graphics. > > > > Looking forward to your updates! > > Oh sweet - I wasn't aware of that thanks for the pointer! I'm hoping to > have some cycles to hack on this this week and will post updates or if > I'm feeling ambitious (and not burnt out from day job) will create a > wiki page for this device. > > cheers! > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > > -- Mario.
Re: PinePhone Pro Boots On CURRENT
On 5/30/23 05:19, Stephan Lichtenauer wrote: But, once i get the linux DTB for this guy into a disk image i'm going to see if i can get the display up next, but would love to hear any input or pointers from folks with more ARM porting experience than me. I am probably telling you something you already know, but afaik the Pinephone Pro uses the Rockchip RK3399 which according to the datasheet (https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf page 16, 1.2.9 Graphics Engine) contains a Mali GPU. That means Ruslan Bukin's Panfrost article in the FreeBSD Journal Jul/Aug 2021 at https://freebsdfoundation.org/wp-content/uploads/2021/08/The-Panfrost-Driver.pdf might be interesting regarding graphics. Looking forward to your updates! Oh sweet - I wasn't aware of that thanks for the pointer! I'm hoping to have some cycles to hack on this this week and will post updates or if I'm feeling ambitious (and not burnt out from day job) will create a wiki page for this device. cheers! -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: PinePhone Pro Boots On CURRENT
That's interesting. As I have already said,I haven't bought the pinephone pro,because it is expensive for me. So I'm working on a parallel project. I've bought this phone,instead : https://www.hdblog.it/schede-tecniche/samsung-galaxy-a6_i3655/ That's cheaper. Between the specs I read that it has a mali gpu,too : Mali-T830MP2 so,eventually,I can use the Lima and the PanFrost driver even for my samsung galaxy A6 ? I've started planning to install FreeBSD on top of the Android Kernel,using a specific patch,but now I'm thinking that maybe,I can install FreeBSD there natively. Can someone tell me if it is doable,giving a look at the specs of that phone model ? thanks. On Tue, May 30, 2023 at 2:19 PM Stephan Lichtenauer < sl-pub-li...@honeyguide.de> wrote: > Hi Pete, > > Pete Wright writes: > > > i've had this pinephone pro for a few months now and finally got > > around > > to attempting to boot FreeBSD on it.. Here's the phone: > > https://wiki.pine64.org/wiki/PinePhone_Pro > > > > I needed to get this serial console adapter which works > > flawlessly with "cu" > > (USB TTL Serial Adapter Converter Cable 3.3v/3v3 3.5mm Stereo > > Jack Cable): > > > https://www.amazon.com/dp/B00XSPECIA?psc=1=ppx_yo2ov_dt_b_product_details > > > > then i just downloaded the latest CURRENT snapshot and put it on > > a > > microsd card and it booted into multi-user mode.. here's the > > dmesg: > > https://www.nomadlogic.org/ppro-dmesg.txt > > > > That is excellent news! I am so happy about that, thank you very > much! > > > i am working on building a new image now to include the > > pinephone pro > > DTB file from Linux to see if that improves some of the hardware > > detection.. certainly a long way to go before this could be > > a useful > > mobile device, but i'm very encouraged that i can actually boot > > the thing. > > > > i suspect we'll need to use iwlwifi to get the AzureWave > > AW-CM256SM wifi > > and bluetooth card working... > > > > But, once i get the linux DTB for this guy into a disk image i'm > > going > > to see if i can get the display up next, but would love to hear > > any > > input or pointers from folks with more ARM porting experience > > than me. > > I am probably telling you something you already know, but afaik > the Pinephone Pro uses the Rockchip RK3399 which according to the > datasheet > ( > https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf > page 16, 1.2.9 Graphics Engine) contains a Mali GPU. > > That means Ruslan Bukin's Panfrost article in the FreeBSD Journal > Jul/Aug 2021 at > > https://freebsdfoundation.org/wp-content/uploads/2021/08/The-Panfrost-Driver.pdf > might be interesting regarding graphics. > > Looking forward to your updates! > > Best regards > > Stephan > > > > > thanks! > > -pete > > > > -- Mario.
Re: PinePhone Pro Boots On CURRENT
Hi Pete, Pete Wright writes: i've had this pinephone pro for a few months now and finally got around to attempting to boot FreeBSD on it.. Here's the phone: https://wiki.pine64.org/wiki/PinePhone_Pro I needed to get this serial console adapter which works flawlessly with "cu" (USB TTL Serial Adapter Converter Cable 3.3v/3v3 3.5mm Stereo Jack Cable): https://www.amazon.com/dp/B00XSPECIA?psc=1=ppx_yo2ov_dt_b_product_details then i just downloaded the latest CURRENT snapshot and put it on a microsd card and it booted into multi-user mode.. here's the dmesg: https://www.nomadlogic.org/ppro-dmesg.txt That is excellent news! I am so happy about that, thank you very much! i am working on building a new image now to include the pinephone pro DTB file from Linux to see if that improves some of the hardware detection.. certainly a long way to go before this could be a useful mobile device, but i'm very encouraged that i can actually boot the thing. i suspect we'll need to use iwlwifi to get the AzureWave AW-CM256SM wifi and bluetooth card working... But, once i get the linux DTB for this guy into a disk image i'm going to see if i can get the display up next, but would love to hear any input or pointers from folks with more ARM porting experience than me. I am probably telling you something you already know, but afaik the Pinephone Pro uses the Rockchip RK3399 which according to the datasheet (https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf page 16, 1.2.9 Graphics Engine) contains a Mali GPU. That means Ruslan Bukin's Panfrost article in the FreeBSD Journal Jul/Aug 2021 at https://freebsdfoundation.org/wp-content/uploads/2021/08/The-Panfrost-Driver.pdf might be interesting regarding graphics. Looking forward to your updates! Best regards Stephan thanks! -pete
Re: Surprise null root password
Quoting bob prohaska (from Fri, 26 May 2023
16:26:06 -0700):
On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
The question is how you update the configuration files,
mergemaster/etcupdate/something else?
Via etcupdate after installworld. In the event the system
requests manual intervention I accept "theirs all". It seems
odd if that can null a root password.
Still, it does seem an outside possibility. I could see it adding
system users, but messing with root's existing password seems a
bit unexpected.
As you are posting to -current@, I expect you to report this issue
about 14-current systems. As such: there was a "recent" change
(2021-10-20) to the root entry to change the shell.
https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
By blindly accepting all changes, this has reset the PW to the default
setting (empty).
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).
Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
pgpGEjDP92h3s.pgp
Description: Digitale PGP-Signatur
Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head
On 30/05/23 00:26, Ivan Quitschal wrote:
On Mon, 29 May 2023, Tomoaki AOKI wrote:
On Mon, 29 May 2023 21:05:42 +0200
Guido Falsi wrote:
On 28/05/23 20:45, Guido Falsi wrote:
It may well be something broke... but I'm just wanting to be double
sure it's against a consistent package set. If something broke, then I
can't help.
I see, I did not understand what you meant at first.
What I posted was the result of a simple "pkg upgrade", which is what I
usually do to update the machine, and usually works quite fine.
I have not tested forcing all packages reinstallation ("pkg upgrade -f"
if I get it correctly).
That is something I was already planning to do. Will report back
tomorrow for that.
Well forcing reinstallation of all ports (with rebuilt kmod ports) made
the issue disappear.
SO it looks like it was really nothing. Sorry for the noise and thanks
for the suggestions!
--
Guido Falsi
IIRC, drm*-kmod port didn't seem to be updated in the first place.
OTOH, generic kernel seems to be updated via pkgbase.
This could cause problems with incompatibilities.
And fixed with forcibly updating all pkgs.
poudliere built new pkg, but pkg doesn't thought it's updated , maybe.
--
Tomoaki AOKI
try using this drm-kmod here, instead of the ones within ports
git clone https://github.com/freebsd/drm-kmod
thats the only one that works for me
I'm having good results with:
> pkg info -o '*kmod*'
drm-515-kmod-5.15.25_3 graphics/drm-515-kmod
gpu-firmware-amd-kmod-picasso-20230210 graphics/gpu-firmware-amd-kmod
gpu-firmware-amd-kmod-raven-20230210 graphics/gpu-firmware-amd-kmod
from the official tree.
--
Guido Falsi
Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head
On 30/05/23 00:18, Tomoaki AOKI wrote:
On Mon, 29 May 2023 21:05:42 +0200
Guido Falsi wrote:
On 28/05/23 20:45, Guido Falsi wrote:
It may well be something broke... but I'm just wanting to be double
sure it's against a consistent package set. If something broke, then I
can't help.
I see, I did not understand what you meant at first.
What I posted was the result of a simple "pkg upgrade", which is what I
usually do to update the machine, and usually works quite fine.
I have not tested forcing all packages reinstallation ("pkg upgrade -f"
if I get it correctly).
That is something I was already planning to do. Will report back
tomorrow for that.
Well forcing reinstallation of all ports (with rebuilt kmod ports) made
the issue disappear.
SO it looks like it was really nothing. Sorry for the noise and thanks
for the suggestions!
--
Guido Falsi
IIRC, drm*-kmod port didn't seem to be updated in the first place.
OTOH, generic kernel seems to be updated via pkgbase.
This could cause problems with incompatibilities.
And fixed with forcibly updating all pkgs.
poudliere built new pkg, but pkg doesn't thought it's updated , maybe.
Poudriere did not rebuild the kmod ports since there was no
__FreeBSD_version change. I usually force it being rebuild by hand, but
this time I forgot!
I did force pkg reinstall for it by hand, but this just reinstalled the
same previous package.
In the end I forced rebuilding it and reinstalling everything and the
issue disappeared.
--
Guido Falsi
