Project Trident 1812 release - discusion here


#1

1812 Release as been unleashed.

Discussion goes below


#2

Rod,

What is the command line to fetch the ports tree & src. I recall that TrueOS used git instead of portmaster or equivalents referenced in the FreeBSD Handbook but I cannot find the command in the last several months of messages about P-Trident.

Ian Robinson
Salem, Ohio


#3

git clone https://github.com/trueos/trueos-ports /usr/ports


#4

Now I’d need to find at least 12 extra hours per day for a week or so to start fooling around with this…

I see just about everything KDE Plasma5 on the list, what would the install command be to get a working Plasma5 desktop environment?

I do not see any KDE4 or Qt4 packages, have they all been scrapped? My Linux rig still runs a KDE4 desktop which suits me fine (esp. the KDE PIM4 suit, kmail, kontact etc but with a small selection of self-built KF5 applications). Will the KDE4 packages currently in TrueOS 18.xx remain available once one has upgraded?


#5

KDE4 and QT4 have been depreciated.

I think searching plasma5 in trident repo may help


#6

Thanks Rod. You are a major source of unselfish help for users.

Ian Robinson
Salem, Ohio


#7

kde5 w/ plasma is available in Ports. Excerpt from freshports.org follows:

================= Begin Excerpt ========================

kde5 KDE Plasma Desktop and Applications (current)

5.14.5.18.12.1_1 x11 search for ports that depend on this port Find issues related to this port Report an issue related to this port

Maintainer: kde@FreeBSD.org search for ports maintained by this maintainer
Last Update: 2019-01-16 11:13:45
SVN Revision: 490472
License: LGPL20
SVNWeb : Homepage : PortsMon

Dependency line: kde5>0:x11/kde5

To install the port: cd /usr/ports/x11/kde5/ && make install clean
To add the package: pkg install kde5

PKGNAME: kde5

===================== End Excerpt =====================================

I installed KDE5/Plasma from ports in the Dec. 19 2018 pre-release and it worked great.

Ian Robinson
Salem, Ohio


#8

There’s an issue with time [and consequently date].
A mismatch is detected during startup - why would it do that?
I’ve had to terminal ‘date’ to correct.
The startup routine tries to adjust by locating internet time.
Reverting to previous TrueOS disk shows wrong time too - so I guess there’s resetting of BIOS date occuring.
My installation was as per my locale, Australia.

Steve


#9
# service ntpd stop
# ntpdate au.pool.ntp.org
# service ntpd start

John
groenveld@acm.org

#10

KDE4 and QT4 have been depreciated.

I’m sure I’m not the only one who still appreciates them, no matter how obsolete or deprecated :wink:

I realise there’s a more basic thing that’s been bugging me. If Trident is the successor to the TrueOS Desktop variant, how come there is no direct upgrade path? Not very desktop-user friendly…
The least the install instructions can do is provide a recipe or script how to save and restore user information, and outline how the recommended install deals with (what it does to) customised pool settings/layouts. Like certain system directories have been put in their own dataset in order to tune filesystem properties like copies, compression or sync.


#11

depreciated by FreeBSD, so…

Had you done you fiduciary duty and searched through discourse, it has been discussed ad-naseum about trueos changing things underneath the hood, so much there was NO upgrade path from 1803, except install into a Boot Environment. Again, that has been pointed out here, and on the Project-Trident web page


#12

Thanks John,

I found
sudo tzsetup
did the trick

For some reason
sudo ntpdate au.pool.ntp.org
came back with
“no server suitable for synchronization found”

Steve


#13

If anybody from Project Trident is reading this please provide torrent download for the iso.


#14

discourse does not allow attachments :frowning:

PM me with your email and I’ll forward the .torrent file


#15

Yay I was able to install and get running with a shiny new pitch fork that is Project Trident 18.12 is now my OS of choice for 2019. So here we go everything seems to work without issue so far. I had to do some dancing with the Boot environments since it didn’t boot at first. I think something is happening with OpenRC detecting all the dependencies. I can’t say for sure though you know old boot environments have lots of cruft so when going to a new one it can be a bit touchy. So here is what happened. It kept hanging when webcamd was trying to start it did the same with RC2 but I think that is because well I don’t have a webcam connected but I also noticed that other entries in the boot process of OpenRC didn’t start either however OpenRC kept going trying to boot. After I let it sit for a few minutes while trying to think what to do next I then rebooted back to my older boot environment. Once booted I used the GUI boot environment tool in TrueOS 18.03 to mount the 18.12 boot environment to see if I could see anything obvious which I didn’t but I wanted to look to make sure everything was in place properly and it was. The new lua code was there and everything looked fine to me I guess I could have captured the logs but at 2AM you don’t think like that. So I marked 18.12 as the active boot environment and rebooted again and to my surprise it booted as if nothing had happened. Well nothing actually did happen other than me poking around. I didn’t make any changes. That’s why I’m pointing to OpenRC it may just be a timing issue with dependencies or something like that.
Well so far I’m happy with 18.12… Other than some window decorations and a few images missing on windows it works. Oh and while messing around with the audio mixer it rebooted on me for no apparent reason. It just happened last night so if it happens again I will collect some logs and file a bug.
Anyway I can only imagine that with new builds and more work on Project Trident it will be a first class Operating System for our desktops and compete with the rest of the OS world. Thanks for all your hard work and effort and please keep up this good work. If you take anything from this post you folks should be proud of what you have built here it’s very impressive and I am very happy :grin:


#16

thanks but found torrent on linux-tracker


#18

Unfortunately, this workaround

does not (still) work (with the Release or any other version) on the one (of two) of my systems where the option “install into new BE” is not “selectable” (as in: the option is right there but greyed-out and not accessible via mouse or keyboard).

Checking and testing (e.g. different BIOS settings) I initially thought the system where I can select the “new BE” option might be a GPT formatted drive. But it turns out both drives are MBR drives. So, it must be some chipset difference, though both are Intel and both have onboard graphics - although I doubt that graphics has any effect on this specific problem whatsoever. The “working one” is a desktop pc the one with the problem is a - what are the odds… :slight_smile: - Lenovo laptop.
Both are dual-boot systems with windows bootmanager as main bootmanager and freebsd bootmanager (at time of last TrueOS legacy 18.03 BE) on the BSD slice / partition. So, no differences here, either. Also, no grub on my systems whatsoever.

That just means that for now I can’t have Trident on my daily use machine - because I won’t give up my TrueOS BEs, at least not for now. Not least because some programs don’t work with Trident anymore/yet / aren’t (yet) available. E.g. wine-i386, hplip etc…

Not giving up hope just yet. Still my favourite escape destination once I finally am able to let go of windows for good.


#19

wine-386 is a freebsd issue.

I know trueos, hence Project Trident are GPT systems


#20

I have giving up, and installed fresh into my ZFS partition. Though maybe you could carry on following the advice in the last comment in this post:


#21

Thanks fot the link and info!

Detection of available ZFS pools for installing into a boot environment comes from the pc-sysinstall utility from TrueOS itself.

Well, maybe something is not loading properly on my system that is being loaded properly - if not by default - with the workaround mentioned in my other post on some systems…

I’d also have to check if there are any older BEs on the not working system than on the system that is detected correctly (even without workaround).