Install to an external drive and test before wiping your 18.03. John email@example.com
1803 is the FreeBSD forth bootloader., Triden 182, uses the new FreeBSD new3 LUA bootloader.
It’s been discussed here and on telegram, that upgrading from 1803 to anything current is a roll of the dice
Been there, done that. I already tested trident on my test system. That’s not the issue.
And installing onto an external drive doesn’t tell me anything. It has to work on the designated system on the designated drive on the designated partition. That’s the point. And I would like to keep my 18.03 BE because some things just don’t work with trident, yet.
Sorry, but the easy answers are already taken because I already tried them.
I’m still a windows guy, so I’m not dependent on the task being solved immediately. But it’s still a pain.
Next thing to try will be cloning the drive’s structure with the TrueOS partition to an identical drive and this time not try to unsuccessfully install into new BE on the designated system but put the drive into the test system and get the ball rolling there (as in: getting a trident BE in addition to the TrueOS BEs), put the drive back into the main system and correct the respective files of the new Trident BE for the differences of the two systems, make an image of the altered TrueOS partition and clone it back to the main system’s TrueOS partition.
We’ll see how that goes.
Yes, I know.
But on my test system that had been updated and upgraded since pcbsd I had a running Trident BE. I screwed up that tank trying to get a Trident BE to my main system so I deleted the whole tank, created a new one and started from scratch. And now (!) the two trident releases (U1, RC2) don’t work properly. That’s what bugging me. A clean slate and they don’t really work? When I have more time I’ll probably format that partition and let the installer create a new tank instead of creating it myself and then let the installer install into that. I did that because I’m dual booting with windows and the installer insists on ruining my MBR with it’s bootloader instead of sticking just to it’s partition and not taking over the whole disk…
Does Trident support your production hardware? John firstname.lastname@example.org
I’d guess so. It’s 5 years younger than the test system and the install medium boots. So I’d say yes. But I will be able to tell definitively one I tried my next idea or - if that fails - a plain test installation on a blank drive just to make sure that it works at all.
- Tried to update firefox to the latest version. The git pull to /usr/ports works fine and installs and updates the tree, however, make in port from it’s folder fails:
‘sudo make install clean’ reports:
make: “/usr/ports/Mk/bsd.port.mk” line 1184: Unable to determine OS version. Either define OSVERSION, install /usr/include/sys/param.h or define SRC_BASE.
- portsnap alternative isn’t creating ports tree [to /usr/portsnap] - system ignores the command:
sudo portsnap -f /etc/portsnap.conf fetch
Which branch? $ git branch John email@example.com
trueos-master is the branch in /usr/ports
Not sure if this is installed out of the box: # pkg which /usr/include/sys/param.h /usr/include/sys/param.h was installed by package OS-runtime-development-13.0.20190111130505 John firstname.lastname@example.org
Trident: which ports tree to use
pkg which /usr/include/sys/param.h
/usr/include/sys/param.h was not found in the database
So this means I have no application using param.h?
My install of Trident was to a clean disc - so the 18:12 install is lacking something?
did you install the dev packages?
sudo pkg install -g "OS-*-development
you need these packages
No dev packages installed per se - just native Trident 18:12. I’ve pbi’d any packages, so what dependancies came with I don’t know - may be some devs?
App cafe Installed packages show Dev’s as autoconf, yasm, and git. The first 2 I installed in preparation for making firefox (listed as required in make.file). git presumably came with OS.
I’ve created a new BE [just in case] for this mod to the OS and am installing now.
Hello, just installed 1812 release on a vmware virtual machine. Not bad. Just some quick question.
On the TrueOS SysAdm/Service, even if I installed it, there is no Samba Server option. Infact there is no samba related startup script in /etc/init.d and/or /etc/rc.d. How can I start/stop that service?
As I said, I do run Trident under Vmware workstation. So I installed from command line/pkg open-vm-tools. I’m able to load them at boot time, then when I do a kldstat vmware kernel modules are not installed. How can I load them?
Do your rc init system still do process classic FreeBSD /etc/rc.conf file? It seems it still do, cause for now I do load samba via samba_server_enable=“YES” there. To be sure I enabled rc-enabled service under your Service interface in TrueOS SysAdm. Am I correct about it?
Thank for any reply.
1812? that sounds like trueos, not trident.
making sure which you have installed?
open-rc takes the place of placing things in /etc/rc.conf
service -l <-- will show all services available
and samba_server is there.
I’m not familiar enough with the command line and service to get it started
on the start menu, select “control panel” , then services. select samba_server to run and add to startup
Hi and thankx for your reply! No, it is Trident fresh install and it put an Icon right on the desktop calling it TrueOS SysAdm. If you click over there, it will show 10 icons. AppCafe Manage SSK Keys Boot Environments, Devices, Firewall, Mouse Settings, Services, System Controls, Tasks, Users.
Yes, they should change the name of that icon with Trident SysAdm.
And I forgot Control Panel shortcut open this same panel.
And in my install samba_server is not there.
I do have, under S, s6-svscan, savecache, savecore, sdpd, sendmail, sndiod, sshd, statd, staticroute, etc etc etc
please do not rely on SysAdm. project trident may not be using that much down the road or might depreciated.
my service manager shows samba_server
Interesting addendum to my own findings about the Trident installer (on usb) crashing windows (while none of the TrueOS legacy ones ever did).
Just found this quite recent comment on GhostBSD (review section) along those lines. As GhostBSD is based on TrueOS, too, and ultimately on FreeBSD it also relates to Trident.
2019-03-04: GhostBSD (i.e. FreeBSD, et-al) have a very serious FLAW with their installation media format…
For the uninitiated, any attempt to create a USB stick from an ‘.iso’ will result in a flawed image. Moreover, the USB stick in question may cause a BSOD when inserted into a Windows system.
The problem stems from BSD’s refusal to adopt the ‘hybrid’ ISO image format used by Linux, Windows, and MacOS. The BSD image GPT table is misaligned, and the stick gets bricked.
The *BSD devs need to get with the 21st century and adapt to the mainstream instead of clinging to an ISO ‘standard’ which has been rendered non-standard by all other OS, including Solaris.
According to this comment it’s not because of zfs or something that’s the cause but the GPT format. Which goes with my theory because Trident legacy also was zfs but never cause such problems.
Maybe the Trident/TrueOS devs could kick some buds upstream?
Of course it was supposed to read “TrueOS legacy” instead of “Trident legacy”…