On 8/17/19 3:40 AM, DJ Lucas via blfs-dev wrote:
On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev
<blfs-dev@lists.linuxfromscratch.org> wrote:
I've just completed xorg on a new blfs-9.0 SysV build. Here are some
observations.
I used Pierre's build order that he posted some time ago. I've listed
that below with some modifications. The asterisks indicate that the
package was installed, the dash indicates it was skipped. The indented
entries show packages I installed that were not in the jhalfs list.
Overall I liked the generated list as it made the order much easier to
follow.
I ran into a bit of a problem when starting Xorg. It came up but I had
no mouse or keyboard input. There was also a problem finding
Xorg.0.log
to see what was happening. It is in ~/.local/share/xorg/Xorg.0.log.
That is documented in the Testing and Configuration section for
systemd.
I will change it so it is reflected in both books now that we are
using elogind.
I had not started dbus or elogind. After starting those, the xorg
input
still did not work. I then rebooted and the mouse and keyboard worked
fine. I think a logout and login may have been sufficient, but I'm not
sure. I'm not sure how to address this. It would only be a one-time
issue. Should we recommend a reboot before starting xorg for the first
time? logout/in?
That's usually when I reboot from chroot for the first time. I'm unsure yet
whether we can rid ourselves of mountcgroupfs and elogind bootscripts. I got
busy and then off on my little tangent and forgot about it. Pierre said it is
possible. ISTR, that if PAM was right, and cgroups are already mounted by the
kernel, then a simple logout should have worked. I'll try to get to a build
this weekend and reboot before installing elogind and see if this holds true.
I'm also curious about the location of the log file. Is this true in your build
after elogind is running?
Things are tagged. and currently work. Lets not change any instructions
for this release. Text changes are OK.
The log is in ~/.local/
I have
├/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
│ └─/sys/fs/cgroup cgroup cgroup rw,relatime,cpuset,cpu,cpuacct,freezer
│ ├─/sys/fs/cgroup/unified
│ │ none cgroup2 rw,relatime
│ └─/sys/fs/cgroup/elogind
We probably need to adjust some dependencies. shadow really should
have
cracklib. pam should probably have a shadow as a recommended runtime
dependency.
I agree, but not quite as I understand the above. Shadow shouldn't have a
dependency on cracklib directly, unless PAM is not being used, but runtime
might not be sufficient because of how/when we do the PAM config. I'm not sure
if blfs-tool takes into account runtime dependencies when choosing order for
later deps.
The issue is that the PAM configuration depends on whether cracklib is
installed.
The xcb-util-* files are only needed for qt, but it's easy to do them
in
the book order.
I thought something used them before QT, but I've no idea what. Only libxcb is
required for Xorg itself AFAIK.
True, but when building from the book the user usually steps through all
the Xorg packages in order.
libva has a circular dependency with mesa.
make-ca probably should have wget as a recommended runtime dependency.
make-ca hasn't used wget for a long time. As soon as OpenSSL was in LFS, I used
'openssl sconnect' specifically to avoid any circular dependency there. As
Douglas mentioned, getting the tarball at that point is the issue. The example
configuration for the additional certs is just that, an example. I thought I
had made it clear enough in the book. Suggestions for better presentation would
be much appreciated.
The example makes it slightly confusing, but what you have is fine. The
problem is that experienced users tend to not re-read the text. Guilty.
That said, I'd still like to see both of those moved into LFS. That would make
LFS have zero dependency on the host system (that'd make the 'self hosted'
claim really complete in my mind) -- as in, dump a backup to bare metal, you
could boot immediately and begin working towards a final system (or even a
rebuild) without a 'host system' in sight. Wget would still have to make an
appearance in BLFS, however, for the additional deps. I'd like to revisit that
after release.
The problem with wget in LFS is the optional dependencies. If you can
dump LFS to bare metal, you can also dump some BLFS tarballs.
Personally I use an nfs mounted partition for all my systems to share
tarballs, logs, and build scripts.
I do not know of a way to get jhalfs to add in drivers. Perhaps an
output line to tell the user to install the appropriate drivers for the
system HW would be sufficient.
Personally, I just build them all, but I don't know how blfs-tool could handle
it (as in, I do not understand it's capabilities, and I'm afraid that asking
for another special case is a really big ask). A simple message to the user
might be best. Of note, I'd like to add qxl at some point to handle qemu/kvm
video -- again, after release.
Pierre has already taken care if this.
Hope those are at least somewhat useful.
They are.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
