Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/18/2019 12:05 AM, DJ Lucas via blfs-dev wrote: On 8/17/2019 8:53 PM, Ken Moffat via blfs-dev wrote: On Sat, Aug 17, 2019 at 08:40:23AM +, DJ Lucas via blfs-dev wrote: On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev wrote: 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. Start the dbus bootscript. startx. Works perfectly (intel video), and the log is in /var/log/Xorg.0.log. Summary: for me, the bootscripts for mountcgroupfs and elogind are not required, that matches what Pierre discovered the other week. Cool! That's second confirmation. I won't comment on whether we should rid ourselves of them this close to release. Sorry I wasn't able to get back to it earlier. Since there seems to be a problem for Bruce: did you build Xorg before ever booting the new system ? (Apoligies if that is mentioned upthread). I'm guessing that building the whole desktop in chroot before the first boot might be a problem. This would hold true for me as well. I build through Xorg in chroot, then reboot and use a text mode browser to continue, and my results are as yours. Alternatively, the problem might be with non-kms video displays such as nvidia. I was thinking that since your last message. I got fixated on the bootscripts and went off on a tangent that I simply couldn't let go of. I do that sometimes, a lot actually. I've managed to put it aside, but I'm still itching to get back to it (I didn't trap a couple of unforeseen errors and it will require some minor refactoring to truly be distro agnostic). That's why I like the long goals of the project. I know I said I'd do this last week, but I'm going to acquire a lower level nVidia card tomorrow and see if I fare the same as Bruce. I know we are functional now, thanks to everyone's attention on this, and that we can proceed now. I feel better about that, but I want to put these lingering questions (Xorg log) to bed before release. --DJ So this was also a non-starter for me. It just worked out of the box with Nouveau driver on an older build. For reference, console output is from an SSH session for simplicity (as dlcuas is not my regular user): dlucas@lfsdt2 [ ~ ]$ groups dlucas dlucas@lfsdt2 [ ~ ]$ ls -l /var/log/Xorg.0.log -rw-r--r-- 1 root dlucas 34375 Aug 24 16:36 /var/log/Xorg.0.log dlucas@lfsdt2 [ ~ ]$ grep EE /var/log/Xorg.0.log [ 115.703] Current Operating System: Linux lfsdt2 5.1.3 #1 SMP PREEMPT Tue May 21 19:34:09 CDT 2019 x86_64 (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 115.712] (EE) Failed to load module "nv" (module does not exist, 0) [ 115.713] (EE) Failed to load module "vesa" (module does not exist, 0) [ 115.716] (EE) [drm] Failed to open DRM device for (null): -22 [ 115.803] (II) Initializing extension MIT-SCREEN-SAVER dlucas@lfsdt2 [ ~ ]$ grep nouveau /var/log/Xorg.0.log [ 115.712] (==) Matched nouveau as autoconfigured driver 0 [ 115.712] (II) LoadModule: "nouveau" [ 115.712] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so [ 115.712] (II) Module nouveau: vendor="X.Org Foundation" [ 115.715] (II) [drm] nouveau interface version: 1.3.1 [ 115.802] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau [ 115.802] (II) NOUVEAU(0): [DRI2] VDPAU driver: nouveau [ 115.830] (II) AIGLX: Loaded and initialized nouveau The full log is at: http://www.linuxfromscratch.org/~dj/Xorg.0.log dlucas@lfsdt2 [ ~ ]$ ls -l /usr/bin/Xorg -rwxr-xr-x 1 root root 273 Jun 1 09:43 /usr/bin/Xorg dlucas@lfsdt2 [ ~ ]$ ls -l /usr/libexec/Xorg.wrap -rwsr-xr-x 1 root root 30696 Jun 1 09:43 /usr/libexec/Xorg.wrap dlucas@lfsdt2 [ ~ ]$ ls -l /usr/libexec/Xorg -rwxr-xr-x 1 root root 18121256 Jun 1 09:43 /usr/libexec/Xorg root [ /home/dj ]# lspci | grep -i nvidia 07:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2) 07:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) So, at at this point, I'm ready to throw my hands up. Failing somebody else digging though everything that's been posted thus far, I'm good with just puting back the suid bit. In the event that
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On August 18, 2019 12:20:37 PM CDT, Ken Moffat via blfs-dev wrote: >On Sun, Aug 18, 2019 at 05:28:01AM +, DJ Lucas via blfs-dev wrote: >> >> >> On 8/17/2019 11:48 PM, Bruce Dubbs via blfs-dev wrote: >> > I don't know how you can write to /var/log without >> > $XORG_PREFIX/libexec/Xorg is suid since /var/log/ is 0755 and owned >by >> > root. Are you logging in as root? >> It's policykit, but I haven't figured out just how/where yet. The log >file >> with my test user is /var/log/Xorg.0.log root:dlucas 0644. >> >> --DJ >> >Mine is root:users i.e. my main group. > >ĸen >-- >Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. >I can do the rite of k'zakra, I know the secrets of h'ragna, I can >ha'lk my g'rakha correctly ... I am a dwarf > Captain Carrot Ironfoundersson (in The Fifth Elephant) >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page Yes, that's consistent then. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On Sun, Aug 18, 2019 at 05:28:01AM +, DJ Lucas via blfs-dev wrote: > > > On 8/17/2019 11:48 PM, Bruce Dubbs via blfs-dev wrote: > > I don't know how you can write to /var/log without > > $XORG_PREFIX/libexec/Xorg is suid since /var/log/ is 0755 and owned by > > root. Are you logging in as root? > It's policykit, but I haven't figured out just how/where yet. The log file > with my test user is /var/log/Xorg.0.log root:dlucas 0644. > > --DJ > Mine is root:users i.e. my main group. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On Sun, Aug 18, 2019 at 05:05:41AM +, DJ Lucas via blfs-dev wrote: > > > > I was thinking that since your last message. I got fixated on the > bootscripts and went off on a tangent that I simply couldn't let go of. I do > that sometimes, a lot actually. I've managed to put it aside, but I'm still > itching to get back to it (I didn't trap a couple of unforeseen errors and > it will require some minor refactoring to truly be distro agnostic). That's > why I like the long goals of the project. I know I said I'd do this last > week, but I'm going to acquire a lower level nVidia card tomorrow and see if > I fare the same as Bruce. I know we are functional now, thanks to everyone's > attention on this, and that we can proceed now. I feel better about that, > but I want to put these lingering questions (Xorg log) to bed before > release. > > --DJ > I sincerely hope it isn't a GT710 (GK208B) https://bugs.freedesktop.org/show_bug.cgi?id=104448 I raised another bug myself, but I can't seem to find the details. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/17/2019 11:48 PM, Bruce Dubbs via blfs-dev wrote: I don't know how you can write to /var/log without $XORG_PREFIX/libexec/Xorg is suid since /var/log/ is 0755 and owned by root. Are you logging in as root? It's policykit, but I haven't figured out just how/where yet. The log file with my test user is /var/log/Xorg.0.log root:dlucas 0644. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/17/2019 8:53 PM, Ken Moffat via blfs-dev wrote: On Sat, Aug 17, 2019 at 08:40:23AM +, DJ Lucas via blfs-dev wrote: On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev wrote: 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. Start the dbus bootscript. startx. Works perfectly (intel video), and the log is in /var/log/Xorg.0.log. Summary: for me, the bootscripts for mountcgroupfs and elogind are not required, that matches what Pierre discovered the other week. Cool! That's second confirmation. I won't comment on whether we should rid ourselves of them this close to release. Sorry I wasn't able to get back to it earlier. Since there seems to be a problem for Bruce: did you build Xorg before ever booting the new system ? (Apoligies if that is mentioned upthread). I'm guessing that building the whole desktop in chroot before the first boot might be a problem. This would hold true for me as well. I build through Xorg in chroot, then reboot and use a text mode browser to continue, and my results are as yours. Alternatively, the problem might be with non-kms video displays such as nvidia. I was thinking that since your last message. I got fixated on the bootscripts and went off on a tangent that I simply couldn't let go of. I do that sometimes, a lot actually. I've managed to put it aside, but I'm still itching to get back to it (I didn't trap a couple of unforeseen errors and it will require some minor refactoring to truly be distro agnostic). That's why I like the long goals of the project. I know I said I'd do this last week, but I'm going to acquire a lower level nVidia card tomorrow and see if I fare the same as Bruce. I know we are functional now, thanks to everyone's attention on this, and that we can proceed now. I feel better about that, but I want to put these lingering questions (Xorg log) to bed before release. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/17/19 8:53 PM, Ken Moffat via blfs-dev wrote: On Sat, Aug 17, 2019 at 08:40:23AM +, DJ Lucas via blfs-dev wrote: On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev 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? I'd like to get some additional opinions about these issues. Hope those are at least somewhat useful. Here's my opinion although, since the last couple of days suggest that maybe my correct place should be on the 'B Ark' from golgafrincham, it might be that I'm missing something. Build order (summarised): Various things I really want to use as soon as I boot (e.g. network stuff, certs, openssh, links with graphics), then reboot. Docbook. Linux-PAM and rebuild shadow. Build Xorg and then install fluxbox. Highlights of my build order: Build dbus, install the dbus bootscript, build elogind, all just before xtrans. Rebuild dbus between libxshmfence and xcb-util, pixman, libdrm. I think those are the expected places. After completing the build (xorg server, TTF/OTF fonts, fluxbox, tcl, tk (so gitk can work), ..., rebuilding links : Start the dbus bootscript. startx. Works perfectly (intel video), and the log is in /var/log/Xorg.0.log. I don't know how you can write to /var/log without $XORG_PREFIX/libexec/Xorg is suid since /var/log/ is 0755 and owned by root. Are you logging in as root? Summary: for me, the bootscripts for mountcgroupfs and elogind are not required, that matches what Pierre discovered the other week. Since there seems to be a problem for Bruce: did you build Xorg before ever booting the new system ? (Apoligies if that is mentioned upthread). I'm guessing that building the whole desktop in chroot before the first boot might be a problem. Alternatively, the problem might be with non-kms video displays such as nvidia. For this iteration, I only built the following in chroot on my development system: lsb-release - used in scripts sudo - used in scripts openssh - server for remote access from workstation gpm - useful utility haveged - for entropy libtirpc - nfs rpcsvc-proto - nfs rpcbind - nfs nfs-utils- nfs At that point I reboot and ssh into my development system from my workstation. Sources and scripts are mounted via nfs (but the build is on the development system) and I can log into the system as a regular user. From there I can build in whatever order I want. In this case I used Pierre's order that he extracted via jhalfs. I actually do very little directly from my development system keyboard/mouse/monitor; mostly testing things like xorg and display environments. Some testing needs to be done locally, but most, including most graphical applications can be tested over ssh. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On Sat, Aug 17, 2019 at 08:40:23AM +, DJ Lucas via blfs-dev wrote: > On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev > 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? > > > > >I'd like to get some additional opinions about these issues. > > > > Hope those are at least somewhat useful. > Here's my opinion although, since the last couple of days suggest that maybe my correct place should be on the 'B Ark' from golgafrincham, it might be that I'm missing something. Build order (summarised): Various things I really want to use as soon as I boot (e.g. network stuff, certs, openssh, links with graphics), then reboot. Docbook. Linux-PAM and rebuild shadow. Build Xorg and then install fluxbox. Highlights of my build order: Build dbus, install the dbus bootscript, build elogind, all just before xtrans. Rebuild dbus between libxshmfence and xcb-util, pixman, libdrm. I think those are the expected places. After completing the build (xorg server, TTF/OTF fonts, fluxbox, tcl, tk (so gitk can work), ..., rebuilding links : Start the dbus bootscript. startx. Works perfectly (intel video), and the log is in /var/log/Xorg.0.log. Summary: for me, the bootscripts for mountcgroupfs and elogind are not required, that matches what Pierre discovered the other week. Since there seems to be a problem for Bruce: did you build Xorg before ever booting the new system ? (Apoligies if that is mentioned upthread). I'm guessing that building the whole desktop in chroot before the first boot might be a problem. Alternatively, the problem might be with non-kms video displays such as nvidia. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/17/19 9:01 AM, Roger Koehler via blfs-dev wrote: On Sat, Aug 17, 2019 at 1:27 AM Pierre Labastie via blfs-dev wrote: On 17/08/2019 00:38, Douglas R. Reno via blfs-dev wrote: On 8/16/19 4:36 PM, Bruce Dubbs via blfs-dev wrote: I've just completed xorg on a new blfs-9.0 SysV build. Here are some observations. Ah, I just see that ConsoleKit is referenced on this page. Actually, now elogind takes care of permissions, and the whole sentence about the user belonging to the video group is not necessary. Will fix that. I miss ConsoleKit. I don't really like elogind. I understand that it is needed for Gnome, but could Console Kit be left in as an option, maybe as part of the xfce section? Sorry. There are too many other nuances in scripts and text. the build is already complicated and adding if CK ... else ... it just becomes more complicated. It would also make testing alternatives a lot more work. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/17/19 2:01 AM, Pierre Labastie via blfs-dev wrote: On 17/08/2019 00:38, Douglas R. Reno via blfs-dev wrote: On 8/16/19 4:36 PM, Bruce Dubbs via blfs-dev 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? I agree, a restart should be recommended before starting Xorg for the first time. In systemd, we have to rebuild systemd with logind support before starting Xorg-Server (I'm kind of parked at the moment while I wait for jhalfs to finish), but we specify that a reboot is recommended after reinstalling systemd. Perhaps on the elogind page, we should suggest it? We probably need to adjust some dependencies. shadow really should have cracklib. pam should probably have a shadow as a recommended runtime dependency. I disagree here because it's possible that jhalfs (or a user) could rebuild shadow without PAM support. In the systemd version, we have specified in a note at the bottom of the page that you should rebuild shadow after installing PAM. I don't know if it's on the sysv version or not The xcb-util-* files are only needed for qt, but it's easy to do them in the book order. libva has a circular dependency with mesa. make-ca probably should have wget as a recommended runtime dependency. I agree with leaving xcb-util alone. Agreed on make-ca, but wget will also refuse to download files from https sites without certificates IIRC, and make-ca is hosted on Github (which has an HSTS policy forcing it to use HTTPS). Would it be better if we self-host it so that wget can fetch it (we don't use HTTPs yet of course). 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. We could do that, or we could have the user specify which drivers they want built in an additional Menu option. Note that it's been close to two years since I've used blfs-tool, so I'm a bit out of touch on this. Another option would be to just build all drivers by default. Beginning to answer with the end: I am not sure where you mean to add "an output line to tell the user to install the appropriate drivers". In the BLFS book or in jhalfs? If in jhalfs, there is a sub menu "Xorg Drivers" in the X + Window and Display Managers --> X Window System Environment menu Do we need more? Don't you think a jhalfs user should know about the need of installing drivers? I was going from your list. My comment was for jhalfs but I didn't actually run it. You've already fixed it. If in the BLFS book, Maybe add a sentence at the end of the Xorg-server page, or at the beginning of the "Xorg-7 Testing and Configuration". Ah, I just see that ConsoleKit is referenced on this page. Actually, now elogind takes care of permissions, and the whole sentence about the user belonging to the video group is not necessary. Will fix that. OK. About make-ca: Dj has taken care of the access to the cert repo by using directly a low level openssl command, so wget is not needed. Of course, you need to access githubto download the make-ca tarball, but that just means you need to download it before chroot- or boot-ing, as any package before wget is installed. SO I think all is well for make-ca. About the following: I disagree here because it's possible that jhalfs (or a user) could rebuild shadow without PAM support. In the systemd version, we have specified in a note at the bottom of the page that you should rebuild shadow after installing PAM. I don't know if it's on the sysv version or not. There is the same note in the Sysv book. Adding shadow in the recommended runtime deps of PAM would be only for the sake of jhalfs automation. I am not against it of course, but if you tick elogind and shadow (for example), the generated order is OK, that is cracklib pam shadow elogind (then X libraries and a bunch
Re: [blfs-dev] Xorg under blfs-9.0/elogind
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 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
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On Sat, Aug 17, 2019 at 1:27 AM Pierre Labastie via blfs-dev wrote: > > On 17/08/2019 00:38, Douglas R. Reno via blfs-dev wrote: > > > > On 8/16/19 4:36 PM, Bruce Dubbs via blfs-dev wrote: > >> I've just completed xorg on a new blfs-9.0 SysV build. Here are some > >> observations. > >> > Ah, I just see that ConsoleKit is referenced on this page. Actually, now > elogind takes care of permissions, and the whole sentence about the user > belonging to the video group is not necessary. Will fix that. I miss ConsoleKit. I don't really like elogind. I understand that it is needed for Gnome, but could Console Kit be left in as an option, maybe as part of the xfce section? -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev 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? > >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 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. > >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. 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. > >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. > >I'd like to get some additional opinions about these issues. > Hope those are at least somewhat useful. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 17/08/2019 00:38, Douglas R. Reno via blfs-dev wrote: > > On 8/16/19 4:36 PM, Bruce Dubbs via blfs-dev 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? >> > I agree, a restart should be recommended before starting Xorg for the first > time. In systemd, we have to rebuild systemd with logind support before > starting Xorg-Server (I'm kind of parked at the moment while I wait for jhalfs > to finish), but we specify that a reboot is recommended after reinstalling > systemd. Perhaps on the elogind page, we should suggest it? >> We probably need to adjust some dependencies. shadow really should have >> cracklib. pam should probably have a shadow as a recommended runtime >> dependency. >> > I disagree here because it's possible that jhalfs (or a user) could rebuild > shadow without PAM support. In the systemd version, we have specified in a > note at the bottom of the page that you should rebuild shadow after installing > PAM. I don't know if it's on the sysv version or not >> The xcb-util-* files are only needed for qt, but it's easy to do them in the >> book order. >> >> libva has a circular dependency with mesa. >> >> make-ca probably should have wget as a recommended runtime dependency. >> > I agree with leaving xcb-util alone. Agreed on make-ca, but wget will also > refuse to download files from https sites without certificates IIRC, and > make-ca is hosted on Github (which has an HSTS policy forcing it to use > HTTPS). Would it be better if we self-host it so that wget can fetch it (we > don't use HTTPs yet of course). >> 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. >> > We could do that, or we could have the user specify which drivers they want > built in an additional Menu option. Note that it's been close to two years > since I've used blfs-tool, so I'm a bit out of touch on this. Another option > would be to just build all drivers by default. Beginning to answer with the end: I am not sure where you mean to add "an output line to tell the user to install the appropriate drivers". In the BLFS book or in jhalfs? If in jhalfs, there is a sub menu "Xorg Drivers" in the X + Window and Display Managers --> X Window System Environment menu Do we need more? Don't you think a jhalfs user should know about the need of installing drivers? If in the BLFS book, Maybe add a sentence at the end of the Xorg-server page, or at the beginning of the "Xorg-7 Testing and Configuration". Ah, I just see that ConsoleKit is referenced on this page. Actually, now elogind takes care of permissions, and the whole sentence about the user belonging to the video group is not necessary. Will fix that. About make-ca: Dj has taken care of the access to the cert repo by using directly a low level openssl command, so wget is not needed. Of course, you need to access githubto download the make-ca tarball, but that just means you need to download it before chroot- or boot-ing, as any package before wget is installed. SO I think all is well for make-ca. About the following: > I disagree here because it's possible that jhalfs (or a user) could rebuild > shadow without PAM support. In the systemd version, we have specified in a > note at the bottom of the page that you should rebuild shadow after > installing PAM. I don't know if it's on the sysv version or not. There is the same note in the Sysv book. Adding shadow in the recommended runtime deps of PAM would be only for the sake of jhalfs automation. I am not against it of course, but if you tick elogind and shadow (for example), the generated order is OK, that is cracklib pam shadow elogind (then X libraries and a bunch of other packages, which are needed
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/16/19 4:36 PM, Bruce Dubbs via blfs-dev 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? I agree, a restart should be recommended before starting Xorg for the first time. In systemd, we have to rebuild systemd with logind support before starting Xorg-Server (I'm kind of parked at the moment while I wait for jhalfs to finish), but we specify that a reboot is recommended after reinstalling systemd. Perhaps on the elogind page, we should suggest it? We probably need to adjust some dependencies. shadow really should have cracklib. pam should probably have a shadow as a recommended runtime dependency. I disagree here because it's possible that jhalfs (or a user) could rebuild shadow without PAM support. In the systemd version, we have specified in a note at the bottom of the page that you should rebuild shadow after installing PAM. I don't know if it's on the sysv version or not The xcb-util-* files are only needed for qt, but it's easy to do them in the book order. libva has a circular dependency with mesa. make-ca probably should have wget as a recommended runtime dependency. I agree with leaving xcb-util alone. Agreed on make-ca, but wget will also refuse to download files from https sites without certificates IIRC, and make-ca is hosted on Github (which has an HSTS policy forcing it to use HTTPS). Would it be better if we self-host it so that wget can fetch it (we don't use HTTPs yet of course). 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. We could do that, or we could have the user specify which drivers they want built in an additional Menu option. Note that it's been close to two years since I've used blfs-tool, so I'm a bit out of touch on this. Another option would be to just build all drivers by default. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
