Discussion goes here
Downloading Trident 1811 PreRelease went well. The graphical installer this time had a working pointing device. To get the option ‘install into a boot environment’ activated I needed to go to a terminal once and issue the command
# start-trident-installer after logging in as root. Thereafter the installation was flawless. I am writing this from my newest boot environment:
root@trident-2417:/usr/home/rudy # beadm list BE Active Mountpoint Space Created initial - - 2.5G 2018-05-01 15:06 12.0-CURRENT-up-20180501_155633 - - 7.5G 2018-05-01 15:54 12.0-CURRENT-up-20180910_062826 - - 6.3G 2018-09-10 06:23 12.0-CURRENT-up-20180929_141112 - - 13.7G 2018-09-29 13:52 12.0-CURRENT-201810091443 - - 7.4G 2018-10-09 16:43 12.0-CURRENT-up-20181009_183731 - - 6.1G 2018-10-09 18:18 13.0-CURRENT-up-20181112_130401 - - 21.2G 2018-11-12 12:45 13.0-CURRENT-201811240540 NR / 4.1G 2018-11-24 06:40
I am wondering why the active boot environment has only 4.1G but it seems to work with a trident-core:
root@trident-2417:/usr/home/rudy # pkg info trident-core trident-core-201811161350 Name : trident-core Version : 201811161350 Installed on : Sat Nov 24 06:53:47 2018 CET Origin : trident/trident-core Architecture : FreeBSD:13:amd64 Prefix : /usr/local Categories : trident Licenses : BSD2CLAUSE Maintainer : email@example.com WWW : https://github.com/project-trident/trident-core Comment : Core distribution files and utilities for Project Trident Annotations : FreeBSD_version: 1300003 repo_type : binary repository : install-repo Flat size : 1.27MiB Description : Core distribution files and utilities for Project Trident WWW: https://github.com/project-trident/trident-core
Unfortunately AppCafe is again reduced to the ‘local’ option now and the remedial actions like in this post or that post don’t seem to work for me. Installation of packages is no problem via the ‘pkg install’ command.
I am having a problem getting any of the Trident betas to boot on my laptop. It is a Lenovo T530 with Intel graphics. It has been running TrueOS for the past 2 years. I tried beta 2, and now am 1811 PreRelease. In both cases, I go through the boot, and the X startup fails with xorg reporting “no screens found”:
Build Date: 16 November 2018 08:46:44PM ... (++) Log file: "/tmp/xorg.log", Time: Sat Nov 24 15:59:19 (++) Using config file: "/tmp/xorg.conf" (==) Using system config directory "/usr/local/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) Fatal server error: (EE) no screens found(EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Pleasae also check the log file at "/tmp/xorg.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file xinit: Giving up xinit: unable to connect to server Can't assign requested address xinit: server error
Can someone give me a hint what I might be missing here? Every time I have tried to boot the Trident beta/RC/PreReleases on this particular hardware, I get this same error and X will not start. I was able to boot it in virtualbox, and it installed fine, but on this laptop, I can’t get it to work.
What video card?
According to lspci:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
Mesa DRI Intel(R) Ivybridge Mobile (0x166)
And pciconf -lv says:
vgapci1@pci0:0:2:0: class=0x030000 card=0x21f517aa chip=0x01668086 rev=0x09 hdr=0x00 subclass = VGA vgapci0@pci0:1:0:0: class=0x030000 card=0x21f517aa chip=0x0def10de rev=0xa1 hdr=0x00 subclass = VGA
This is the first time that the install has worked on my generic desktop PC with an NVidia 1070 Ti. Super!
Like Jim Brown reported in Telegram, powerd is burning a lot of CPU. I uninstalled it.
But, I see that python2.7 is pegged at 100%. I don’t know what it’s doing. I killed it and one of the network config icons in the tray in the lower right disappeared. The real one, for the one (wired) network I have, is still there, for em0. The other one wouldn’t do anything when I clicked on it. The boot was trying to configure a network that I don’t have? This PC doesn’t have wifi or bluetooth.
Okay, solved my problem. In BIOS, the nvidia optimus was selected. I set it to internal graphics and turned off the nvidia optimus detection, and it worked.
lol - i was literally typing in a note to check your bios when this popped on…
The runaway is
1716 - Rs 1:54.70 /usr/local/bin/python2.7 /usr/local/bin/hp-systray -x
and it creates a second sysadmin in the tray. I kill the above and that sysadmin icon disappears, leaving the good sysadmin icon there.
not sure what happened there
The Good, The Bad and The Ugly…
For the first time since I noticed the BTX loader read error on my test system it seems to be gone now!
Well, except if it always was just a matter of reporting/displaying: The error might have always been there (and still might be there now) but only for a certain period of time the loader was programmed to display the error to the user…
In either case: I don’t have to look at the error message anymore…
i386-wine seems to be removed from the repositories. At least pkg can’t find any, neither can AppCafe. So no working wine for me, it seems.
Don’t try this at home:
As I forgot about the quite new update command “trueos-update” I used “pkg upgrade” on my RC3 BE. It works - sort of. You end up with an in-situ upgrade, i.e. as if you did pkg-static, no new BE. Other than that all looks ok. Even “trueos-update check” says so.
BUT: “trueos-update upgrade” will show you otherwise. It will perform an upgrade - again. Only this time with newer OS-* packages - the ones installed by pkg were all from Nov 7th except for one that was from Nov 9th - the “real” upgrade gives you OS-* packages dating as recent as Nov 22nd - AND it installs the upgrade into a new BE, as it should.
So: Don’t forget about “trueos-update” and save yourself time and effort and do NOT use “pkg uprade” to upgrade RC3 to PRE-RELEASE…
Other than that the pre-release doesn’t seem to have any major flaws as far as I can tell. AppCafe is on local, so now installing of packages for me. I haven’t tried the remedies I used in the past, yet. I will try later on. Maybe a reboot might be enough, but I was to lazy to test this theory due to the old slow machine…
i386-wine is broke. been looking at the with every build
pkg upgrade is for FreeBSD. this is NOT freebsd. So yes, trueos-update is the only way to upgrade.
do not use FreeBSD ports, portsnap. they too will screw your system up.
AppCafe is “broke” with that.
My experiences with the pre-release:
- the mouse problems under the system install menu is solved
- the boot speed of the installer media, the speed of the system install and the boot speed of the installed system are unbelievable fasts!!!
- the automount and unmount services are works, but the icons of the attached removable (USB devices) and unremovable (second internal HDD) devices are missing from the desktop. I can use these from Insight .autofs
- I can use the internal hardwares (DVD writer) of my machine only as root (for example Xfburn start from terminal as root) is this bug? Maybe not
- the sysctl.conf is only in /etc/defaults is this a bug or a new setup?
- missing dmesg log (/var/log) is this a bug or a new setup?
- new ntp.conf in /etc
- sysadmin errors solved
- earlier if I start the Task Manager from the system tray, it couldn’t start and make high (100%) CPU usage
- if I rename a file in Insight, the new renamed file will disappear, but if I step again into the map (fresh) than visible
- the AppCafe can show only the local-installed files, but I can install from terminal after a pkg update:
AppCafe not updating
- I can’t choose only one permanent wallpaper, the Choose icon is unusable:
@Zoltan thanks, that is good news.
xfburn as root: that is typical because of the permissions needed to open the whole raw device. There are ways around it, some ugly, some not so ugly. One way it to put your user account into the same group as root (typically called wheel) as the default group. Another way would be to set the “sticky” bit on the executable (chmod u+s).
sysctl.conf: FreeBSD will typically have configuration files in both /etc and /etc/defaults. /etc/defaults can change from release to release, so you put the overrides in /etc. If you need to change default settings and the config file does not already exist in /etc, simply create it and put your changed values in there. You should never change a config file in /etc/defaults. So if you need to set sysctl defaults, create your /etc/sysctl.conf with your changed values.
dmesg log: typically the output in /var/log/messages is the same as in “dmesg”. There may be a config variable somewhere to also get the dmesg log (I’m not in front of a machine at the moment)
/etc/ntp.conf is typically used for the base ntpd configuration. Older TrueOS releases were using openntpd which had config in /usr/local/etc. Did TrueOS/Trident go back to using NTPD from FreeBSD base? If so, that’s why the change.
I have no input on taskmanager, insight or AppCafe (I think the AppCafe behavior is known).
Just a small complaint. I still cannot install Trident into a new boot environment, because that option is disabled. Since there is a hurry to release a RELEASE as soon as possible (and I can understand that), I expect to be able to install and use Trident only after the RELEASE after the next, when hopefully the bug will be fixed. Trying to remain on TrueOS 17.12 as long as possible, but I’m afraid I will have to switch my work to a Linux environment until then.
can you post a pic of that page?
It’s the same as here, though I have more partitions on the primary disk.
the new freebsd loader is now written in LUA, and no longer written in forth.
What is the daily driver on that computer?
looking at the pic, which button are you attempting to click. (dumb question, I know)
The bug report has the information, but I will give it here, again.
It’s a notebook with Windows 10 pre-installed, and I use TrueOS all the time. I installed TrueOS and then Linux Mint. In order to be able to multi-boot all the OSs, I had to install Linux Mint’s UEFI GRUB2 bootloader. It boots fine all OSs.
I was able to update TrueOS to 18.03 STABLE and UNSTABLE, with related boot environments, though I have issues with LibreSSL in my work environment; the main boot environment is 18.03 UNSTABLE, but I always select the 17.12 one, which still works.
Summarizing, I have multi boot with Linux Mint’s GRUB2 UEFI boot loader, and three working ZFS boot environments. Installing Trident into a new ZFS boot environment should not be that hard.
Dumb answer: I try to click on the empty circle beside “Boot Environment”. Since it has no effect, I select the ZFS partition and try to click there again… and again, and then I click everywhere around in despair… until I have to click “Shutdown”.
Oh MAN! I’m very glad for your message!
Now I’m very surprised because THIS SYSTEM IS USABLE! This is very positive! After many problems, this is working! I used some weeks Ghost BSD, because I thought the Trident will be good only after a long time, but now…this is working!