<farkuhar>
SiFuh, jaeger, thanks for the helpful feedback on my handbook draft. I fixed most of the formatting issues, and you can see the polished product here: https://crux.nu/Sandbox/Handbook3-7
<SiFuh>
farkuhar: looks good although 3.2.2 you say /boot/efi/EFI/BOOT and the kernel is saved in /boot/vmlinuz-5.15.55 and yet you have the line KERNEL ../vmlinuz-5.15.55
<SiFuh>
Should that not bee ../../vmlinuz-5.15.55 ?
<SiFuh>
syslinux will probably not find it anyway since it will need to be under /boot/efi/ instead.
<farkuhar>
SiFuh, the path discrepancies are mentioned in the sentence before the template: "In the template below, suppose extlinux assigned /boot/syslinux as the preferred location for syslinux.cfg, and a copy of the kernel was saved in the parent directory as /boot/vmlinuz-5.15.55. The relative path therefore begins with ../" I might add a comment that the template applies to syslinux installed in legacy mode, and cannot be used verbatim on UEFI systems.
<SiFuh>
farkuhar: If you are going to use /boot/efi/efi then you will need two examples. I knew this would happen.
<SiFuh>
It would have been so much easier if jaeger just changed /boot/efi to /boot in the fstab
<SiFuh>
Yeah I read it. But your example becomes misleading by the very first line.
<farkuhar>
You mean the line in the template that offers two options for the directory: /boot/syslinux for legacy systems, and /boot/efi/EFI/BOOT for uefi systems? I could write two different templates, but it seemed shorter this way.
<SiFuh>
Yes
<SiFuh>
I would do that. Just two examples for two locations. Don't try to merge them together.
<farkuhar>
Okay
<SiFuh>
For the EFI version you will not be able to use /boot/vmlinuz-5.15.55 because /boot won't be accessible
<farkuhar>
btw, I didn't make any changes to the table that lists the disk controller drivers included on the iso kernel. If I get a chance later today, I'll double-check all those entries and bring them up to date, unless you can identify any outdated information based on your extensive kernel building experience.
<SiFuh>
Hmm, which section?
<SiFuh>
3.1?
<SiFuh>
Because there was only one addition and that was introduced CONFIG_X86_INTEL_LPS but I am not sure if jaeger is using that kernel yet. It was introduced to allow low powered peripheral devices for machines that use board soldered memory cards for their main drives.
<SiFuh>
CONFIG_X86_INTEL_LPSS*
<farkuhar>
Yes, 3.1. I was mainly interested in whether any drivers had been dropped from the kernel config, not whether any drivers had been added. It wouldn't be honest to advertise support for some hardware but not actually provide those drivers.
<SiFuh>
I don't think any has, but the best person to ask would jaeger.
<SiFuh>
farkuhar: for PATA these are not supported anymore PATA_SC1200 [=n], PATA_CS55* [=n], PATA_ISAPNP [=n]
<farkuhar>
SiFuh: thanks for checking. I'm not a big fan of navigating the ReStructured Text documentation in /usr/src/linux (and would much prefer the OpenBSD practice of a man page for each driver), but I'll do so in order to clean up the "Supported Hardware" table in light of the three dropped PATA drivers.
<SiFuh>
SATA is fine.
<SiFuh>
Under SAS and SCSI there are a few that I cannot find at all.
<SiFuh>
And USB is fine
<farkuhar>
SiFuh: I split the syslinux.cfg template into two separate examples as you suggested, adding a bullet point about the inability to cross filesystem boundaries. I hope it's less misleading now.
<SiFuh>
I will peek later. I am doing the SAS SCSI check for you
<SiFuh>
farkuhar: I cannot find these at all. https://dpaste.com/A6V7AHWRU.txt so unless they were dropped or merged then they are probably not supported anymore. Maybe jaeger can verify this for certain
<SiFuh>
farkuhar: Syslinux is good. Let's hope the system is only running CRUX and not dual booting :-P
<SiFuh>
Didn't know EOF was a feature
<farkuhar>
EOF is the conventional abbreviation for End of File, when writing a here-doc in bash. It won't appear in the written syslinux.cfg file. :-P
<farkuhar>
Dual booting is a possibility that deserves some brief remarks, perhaps in the handbook appendix. Links to the upstream documentation are probably the best way to handle it, since any user questions on such a setup will not be CRUX-specific.
<jaeger>
I plan to remove the list of supported hardware entirely with this release, for what that's worth
<jaeger>
Replace it with something more generic like "the boot kernel supports many common controllers", etc.
<jaeger>
One reason for the separation between /boot and /boot/efi is documentation, much of the original UEFI booting docs referenced /boot/efi. Personally, I also like to keep my linux stuff out of the ESP (in other words kernel goes in /boot, UEFI stuff into /boot/efi) but that's just preference, mostly, not strict requirement
<SiFuh>
I think it is just ugly to be frank. :-)
<jaeger>
heh, fair
<jaeger>
In the end, I don't really care which way it looks... but if I've learned anything recently it's that someone will hate it, no matter what I change it to
<SiFuh>
Yeah
darfo has quit [Remote host closed the connection]
darfo has joined #crux-devel
<farkuhar>
jaeger: after removing the list of supported hardware, the Install section looks much cleaner. I ended up filling the void with a short mention of SiFuh's custom ISO, as an illustration of how to solve problems caused by missing drivers.