HOW do you install Syslinux as a bootloader?
The last step of the instillation guide simply state install a boot loader with a link to available boot loaders.
From the list of available boot loaders I chose Syslinux which brought me here.
This guide simply states install from official distributions? Again HOW?
The link for official distributions just takes me to a lengthy page on what official distributions are.
I still have no idea HOW to install Syslinux as my boot loader for my bran new install of Arch-linux. At this point I will have to abandon the whole thing for failed instructions. Neither apt or aptitude are installed with the distro and again, the instructions do not tell me anything about what my options are or how to go about the task given. Not providing instructions is an epic fail for a set of instructions.
I tried registering on the forums to find the answer but the registration system is broken asking a anti-bot question I can't possibly answer. Some code thing, but I'm no programmer and haven't clue. —This unsigned comment is by Krahazik (talk) 20:07, 25 November 2015. Please sign your posts with ~~~~!
- Fixed the installation link with 
- For the rest, see the Beginners' guide. -- Alad (talk) 19:17, 25 November 2015 (UTC)
Location of kernel and initrd files in UEFI systems
The edition  seems to be too-strong in its wording (i.e. "must") with no real indication of what is happening or why such path should be used in syslinux.cfg (which is not completely accurate anyway).
The path in syslinux.cfg for files such as vmlinuz-linux depends on where exactly the files are located, in relation to the working directory of syslinux.efi.
For example, if the kernel and initrd files are located in the root of the $esp, and syslinux.efi is located in
$esp/EFI/syslinux/, then the paths to be used in
$esp/EFI/syslinux/syslinux.cfg would start by
../../ as "mandated" by the aforementioned edition.
But if the kernel and initrd files are located in the
$esp/EFI/ directory (as another example), then the paths to be used in
$esp/EFI/syslinux/syslinux.cfg would start by
../, not by
Considering that the "UEFI systems" section does not mandate any specific directory for the location of the kernel and initrd files – as of syslinux.efi 6.03, they only need to be somewhere in the $esp partition – I would tend to think that the wording of this edition might need some tweaking, and/or more accurate information should be provided regarding the (recommended) location of the kernel and initrd files for UEFI systems.
IMHO, the aforementioned edition lacks context / accuracy when reading the "UEFI systems" section of this article.
Additionally, the reason for this edition points to  but, to a user seeking for instructions / information (i.e. without prior knowledge / understanding), that forum topic does not seem to provide any justification for this "mandatory" change of paths, nor instructions for users to follow, especially considering the lack of context for this edition within the wiki page itself. Ady (talk) 17:20, 20 February 2016 (UTC)
- I see, my editing realy does more harm than good.
- When you install this stuff the first time you just follow the description and apply the examples to your installation without paying much attention. So paths in example don't always match your installation (which shouldn't be surprising). But I wanted to warn the reader.
- I will remove my edit and add a note to examples section. Thompson 19 March 2016
Comparing to other bootloaders
In the Syslinux page, the topics should be about Syslinux. Comparisons with other bootloaders are to be placed in the Category:Boot_loaders page, where they belong.
I had deleted the unneeded and irrelevant comments about other bootloaders within the Syslinux page, but my edition was reverted. I consider this "revert" (aka "undo") action to be a mistake, together with additional editions referencing other bootloaders in the Syslinux page. Ady (talk) 19:53, 10 October 2016 (UTC)
- I'm in agreement that it should be minimized, but I do think we should at least link alternatives if a feature is missing. I've updated the page. Thoughts? -- Rdeckard (talk) 02:04, 11 October 2016 (UTC)
- In , the link to alternative bootloaders is mentioned in a main initial Note of the Syslinux page. The link is also present in the "Related" area. IMO the Note should only refer to things about Syslinux itself.
- While the link to Category:Boot_loaders is already present in the "Related" area, I indeed agree that linking to it (again) in some relevant paragraph(s) might be useful for some users. I happen to disagree about linking to it from the "chainloading" subsection (or from the initial main Note, as I mentioned in my previous paragraph).
- Users looking for chainloading-while-using-Syslinux can read the relevant info in the relevant subsection of the Syslinux page. Users looking for chainloading-while-using-GRUB2 can read the relevant info in its own page. Users looking for bootloaders-capable-of-chainloading (or whichever other feature) can read the Category:Boot_loaders page, which includes some features of different bootloaders (or a kind of comparison between them).
- So, where do I think it would be, both, useful and appropriate to add a link to the "Category:Boot_loaders" page? For example, in some already-existing subsection referring to some relevant limitation or with some relevant less-than-clear warning/error message originated in Syslinux's code, such as https://wiki.archlinux.org/index.php?title=Syslinux&diff=453544&oldid=453543#Btrfs_compression; a simple "See (also) Category:Boot_loaders" at the end of such subsection should be enough and adequate (with no "for alternatives", no "for other bootloaders", no "workarounds", no "better options", no "other possibilities", no...; it's intention is clearly implied already by the context in this case).
Raising visibility of a warning note
At the time I am writing this, the initial Warning note says:
This Warning note is very important, so its location, right at the beginning of the wiki page, is appropriate.
Unfortunately, (some) users seem to be missing it, or misinterpreting it, or skipping it, or something of that sort. Several forum topics have been opened, and although the Syslinux wiki page is mentioned, users (including OPs and multiple repliers) don't seem to relate the problem they are having with the content of the Warning note. There are already multiple forum topics with this same case (even after the Warning note was introduced).
There is a Troubleshooting section in this wiki page. Would it be acceptable to repeat the Warning note in that section, so as to improve its visibility? Any (other) suggestions / alternatives? Ady (talk) 22:41, 29 December 2016 (UTC)
- I would agree with doing something to increase its visibility. This is something which changed recently (due to filesystem creation defaults changing). It's a new problem and something which probably wouldn't be looked out for by most people checking the page for commands but already familiar with the workings of syslinux. It's kind of a pain to fix later as if you don't catch it early you either have to remake the filesystem or change to a different bootloader. --TheChickenMan (talk) 08:14, 30 December 2016 (UTC)
- There are forum posts written by users that seem to be already familiar with Syslinux, and yet they seem to be missing the problem; otherwise the topics would be "solved" faster by their replies. So, apparently, being just a plain user of Syslinux doesn't seem to be enough when it comes to this type of (filesystem features and default parameters) problem.
- WRT having to re-create the filesystem, the linked page included in the Warning contains some workaround(s) (depending on the specific fs) so as to avoid such undesired situation.
- Now, are there any (other, better) suggestions about how to effectively raise the visibility of this Warning? Are there any objections against repeating the Warning under the Troubleshooting (sub)section (perhaps with some additional comment)?
- Additionally, considering that the problem is generated because of changes in the _default_ settings when creating filesystems (or by changes in the fs structure, introduced in their newer versions), I also wonder whether some Note(s) should be added in their respective wiki pages. Ady (talk) 10:26, 30 December 2016 (UTC)
- I think being familiar with syslinux and its operation is part of the problem. People don't expect something like this to change and don't automatically look out for it. I don't think the warning should be added to the filesystem pages too. It's a problem only with and relevant to this specific bootloader. I agree with repeating the warming under troubleshooting and I also think that it should be rewritten to be more clear. Maybe something like the following?
- Some (attempts to) clarification(s):
- Syslinux has _not_ changed; the changes were made in the respective fs structures and/or in their respective tools
- The changes affected several bootloaders (including GRUB). Some bootloaders got some updates so as to deal with some of the fs changes. IOW, the problem is (still) relevant for several bootloaders.
- I wasn't suggesting to replicate the same Warning that is posted here in the Syslinux page onto the respective fs pages. I was wondering whether some kind of Note should be added in those other pages, regarding _their_ own changes, especially when it comes to the changes in their respective _default_ behavior. As you said, people don't expect this kind of things to change, especially regarding the _default_ behavior (of fs tools).
- Some of the problems for Syslinux users could be resolved by updating the Syslinux package, but that's slightly off-topic in this particular discussion about this specific Warning note.
- Re-writing the current Warning note located at the top of the page was already attempted/suggested before (through diverse channels); those attempts were mostly rejected for several different reasons (and I just happen to agree with most of those rejections). But perhaps the Troubleshooting section could be slightly more explicit, enough to help users without repeating too much information located elsewhere, nor limiting the scope of the problem. See . Ady (talk) 06:57, 31 December 2016 (UTC)