From ArchWiki
Latest comment: 18 November 2022 by Andreymal in topic Location of the configuration file

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 [1]
For the rest, see the Beginners' guide. -- Alad (talk) 19:17, 25 November 2015 (UTC)Reply[reply]
Let's see if [2] helps. Ady (talk) 19:57, 26 November 2015 (UTC)Reply[reply]
Perhaps that paragraph is also (better?) suited in Boot loaders. -- Alad (talk) 20:14, 26 November 2015 (UTC)Reply[reply]

Raising visibility of a warning note

At the time I am writing this, the initial Warning note says:

Warning: As of Syslinux 6.03, some of the features of the supported file systems are not supported by the bootloader; for example, the "64bit" feature of ext4 (boot) volumes. See [3] for more information.

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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?
Warning: Syslinux 6.03 no longer works with ext4 formatted partitions by default. To make Syslinux work with newly formatted ext4 partitions 64bit support must be disabled during filesystem creation. Some additional features and other filesystems may also be unsupported. See [4] for more information.
Perhaps some more information and a clarification could be put in a section of troubleshooting as well? --TheChickenMan (talk) 18:37, 30 December 2016 (UTC)Reply[reply]
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 [5]. Ady (talk) 06:57, 31 December 2016 (UTC)Reply[reply]

Should we get rid of the ext4 64-bit warning now that syslinux supports 64-bit

Hi. According to the release notes at the syslinux [wiki][6] version 6.04-pre2 now supports 64-bit ext4. Should we remove the warning?

Davidmcinnis (talk) 09:55, 15 April 2019 (UTC)Reply[reply]

Some features of some supported filesystems (other than the aforementioned 64bit feature in ext4) are not supported by Syslinux. Moreover, official upstream 6.04-pre2 fails (so it has the potential of confusing users even more). So, no, IMNSHO the warning about unsupported features should not be removed. Ady (talk) 17:48, 15 April 2019 (UTC)Reply[reply]
Thanks for the response Ady. I did not intend to suggest removal of the general unsupported note, as syslinux lacks many features present in other bootloaders like grub. I only advocate for removing the specific warning about 64-bit ext4 filesystems. Just a few days ago I set up a VPS server on BuyVM with syslinux launching the kernel from a 64-bit ext4 boot partition. I have no problem installing / running syslinux 6.04.pre2.r11.gbf6db5b4-1 from the core repository. I did not know some users have problems with a failing syslinux, as I have not experienced this personally.

Davidmcinnis (talk) 12:13, 19 April 2019 (UTC)Reply[reply]

Location of the configuration file

After experimenting in a virtual machine, I noticed that UEFI Syslinux can successfully read config from both esp/EFI/syslinux/syslinux.cfg and /boot/syslinux/syslinux.cfg (in case ESP is mounted in /boot).

In fact, both BIOS and UEFI versions use the same config search algorithm.

Therefore, I suggest:

  • Describe the exact algorithm how Syslinux searches for the configuration file, as implemented in loadconfig.c and searchconfig.c;
  • Mention the ability to create esp/EFI/syslinux/syslinux.cfg, but do not force the user to create it;
  • Remove esp/EFI/syslinux/syslinux.cfg from the examples and use /boot/syslinux/syslinux.cfg only — this file is already provided by the syslinux package and works as is in both BIOS and UEFI;
  • But pay more attention to the situation when ESP is mounted in an alternative mount point because /boot/syslinux/syslinux.cfg will not work in this case.

I added Template:Out of date to get attention to this discussion, but if there are no objections, I can try to apply all these changes myself.

-- andreymal (talk) 16:24, 18 November 2022 (UTC)Reply[reply]