[arch-general] syslinux: out of date - or not?
Hi, I recently wanted to switch from grub to syslinux, but it could not boot my /boot-partition, because it uses XFS. Unfortunately only syslinux 6.04 supports XFS, while we stick on 6.03. 6.04 is somehow a "testing" version, thought it has been out for 2 years, so I marked 6.03 as "out of date". I'm wondering a bit why we stick on 6.03, even Debian stable[1] has 6.04. BR Bjoern [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803938
On Fri, 21 Dec 2018 12:34:42 +0100, Bjoern Franke wrote:
I recently wanted to switch from grub to syslinux, but it could not boot my /boot-partition, because it uses XFS.
A long time ago I migrated from GRUB2 to syslinux. In my case the file system wasn't/isn't an issue, but the migration to syslinux had/has pitfalls for me, too. Dual-monitor usage on demand is one of those issues. Dunno if GRUB2 is able to handle it, but syslinux definitively can't, while the BIOS is able to manage it. Another issue are the multi-boot limitations. Since multi-boot anyway is less comfortable when using syslinux, you either need to chainload or to bypass chainloading as I do [1], why not simply migrating to a more common file system for the /boot partition, too? How about ext4? Regarding SSD usage it shouldn't make a difference [2]. [1] [rocketmouse@archlinux ~]$ grep bind /mnt/moonstudio/etc/fstab /mnt/archlinux/.boot/ubuntu_moonstudio/boot /boot none bind 0 0 [2] https://wiki.archlinux.org/index.php/Solid_state_drive#TRIM
On Fri, Dec 21, 2018 at 3:37 PM Ralf Mardorf via arch-general <arch-general@archlinux.org> wrote:
A long time ago I migrated from GRUB2 to syslinux. In my case the file system wasn't/isn't an issue, but the migration to syslinux had/has pitfalls for me, too. Dual-monitor usage on demand is one of those issues. Dunno if GRUB2 is able to handle it, but syslinux definitively can't, while the BIOS is able to manage it.
I'm sorry to intrude here but how can that be related?
On Fri, 21 Dec 2018 16:13:23 +0100, Andy Pieters wrote:
I'm sorry to intrude here but how can that be related?
It's not related, it's just a hint to workaround issues, if a migration has got advantages.
Am 21.12.18 um 19:25 schrieb Ralf Mardorf via arch-general:
On Fri, 21 Dec 2018 16:13:23 +0100, Andy Pieters wrote:
I'm sorry to intrude here but how can that be related?
It's not related, it's just a hint to workaround issues, if a migration has got advantages.
Hm? You wrote: "In my case the file system wasn't/isn't an issue, but the migration to syslinux had/has pitfalls for me, too. Dual-monitor usage on demand is one of those issues." And sure, using ext4 instead of XFS would be an option, but we don't have 2002 any more, when XFS was such uncommon that you needed to use an extra kernel. Regards Bjoern
Dual-monitor usage on demand is one of those issues.
If I connect a LCD monitor to the computer's HDMI port and a CRT monitor to its VGA port, but only turn on the LCD monitor, the syslinux menu isn't available by the LCD monitor. To see the menu on the LCD monitor, I need to unplug the CRT monitor.
On Sat, Dec 22, 2018 at 5:08 PM Ralf Mardorf via arch-general <arch-general@archlinux.org> wrote:
Dual-monitor usage on demand is one of those issues.
If I connect a LCD monitor to the computer's HDMI port and a CRT monitor to its VGA port, but only turn on the LCD monitor, the syslinux menu isn't available by the LCD monitor. To see the menu on the LCD monitor, I need to unplug the CRT monitor.
Not wanting to belittle your issue but surely that's an extreme edge case? Or not. hmmm. has this ever happened to me? With servers, yes I occasionally have to plug in a monitor on a VGA port to debug a failed boot. But if the syslinux/grub isn't showing a CTRL+ALT+DEL. is what I do since I'm at the boot stage anyway. Granted on some servers it takes 6 minutes to fully POST but since it is such a rare occurrence I hardly think about it. Does it happen to you that often to such an extent as to be a blocker, or was it more a case of "a list of things that don't work"?
On 12/21/18 6:34 AM, Bjoern Franke wrote:
Hi,
I recently wanted to switch from grub to syslinux, but it could not boot my /boot-partition, because it uses XFS.
Unfortunately only syslinux 6.04 supports XFS, while we stick on 6.03. 6.04 is somehow a "testing" version, thought it has been out for 2 years, so I marked 6.03 as "out of date".
I'm wondering a bit why we stick on 6.03, even Debian stable[1] has 6.04.
BR Bjoern
The fact that Debian ships an unreleased version syslinux (because according to your bug report link, a person who wanted to use XFS managed to become the Debian maintainer and upload a prerelease out of personal motivations) is not, in fact, proof positive that Arch should do the same. However, as it happens Arch *does* have syslinux available... in the testing repos. So ultimately we are not sticking on 6.03 (even though there are at least as many convincing arguments to be made that we should, as there are arguments that we should ship a prerelease). Why is it still in testing? That's another matter entirely. The answer is that it doesn't boot. Actually that is one of two different issues with attempting to build syslinux on newer compiler toolchains, and Debian has patches for both -- neither of which the syslinux developer community has responded to, though given that they've only committed 2 patches in the last year, both of which were in response to a syslinux thread entitled "Is syslinux still worked on? No new commits in git for about one year", things are looking... gloomy. Of the two patches needed in order to *build* syslinux, only one, needed to successfully run makepkg, has been responded to on the mailing list, and that only very recently: https://www.syslinux.org/archives/2018-November/026229.html https://bugs.archlinux.org/task/60405 "Thanks. Merged but not yet pushed." No clue what that is supposed to mean, it does come with bizarre rationalizations though. We do include this patch in our brand-new testing/syslinux package. Unfortunately the other build issue manifests as silently succeeding to build, but failing to work when attempting to boot your system: https://bugs.archlinux.org/task/61059 And this patch has not, as far as we can tell, been looked at by the developers. But I guess it does work for Debian. tl;dr While I understand it's disappointing to not have desired features from the package, it does take some time to get those features when they suffer from being both unreleased code, and code on top of a package that doesn't validly build in 2018. Please wait, we are trying to get to a working state, and hopefully our syslinux maintainer will be able to resolve this sometime soon. Once we can trust the package actually works, we can move it to stable. Hope this clears things up for you. :) Good luck. -- Eli Schwartz Bug Wrangler and Trusted User
On 12/21/18 10:38 AM, Eli Schwartz via arch-general wrote: ...
Debian has patches for both -- neither of which the syslinux developer community has responded to, though given that they've only committed 2 patches in the last year, both of which were in response to a syslinux thread entitled "Is syslinux still worked on? No new commits in git for about one year", things are looking... gloomy.
Based on Eli's above comment it sounds like syslinux may not be a good choice. Its such a critical component of the system, that having a well maintained tool is important. I chose to use refind (arch package refind-efi) which I've found to work well for my use cases. For my very old computer without EFI I use grub2. Of the 2, IMHO, refind is the superior tool. Thanks for sharing. gene
Hi Eli,
While I understand it's disappointing to not have desired features from the package, it does take some time to get those features when they suffer from being both unreleased code, and code on top of a package that doesn't validly build in 2018. Please wait, we are trying to get to a working state, and hopefully our syslinux maintainer will be able to resolve this sometime soon. Once we can trust the package actually works, we can move it to stable.
Hope this clears things up for you. :) Good luck.
I'm thankful for pointing out the issues regarding syslinux. I assumed some issues when seeing that 6.04 was not released since 2 years, but I did not assume that it is so bad. Sounds somehow like upstream is more or less dead? :/ But in MBR-land it seems to be the only alternative to grub? BR Bjoern
On Sat, Dec 22, 2018 at 12:27:25PM +0100, Bjoern Franke wrote:
But in MBR-land it seems to be the only alternative to grub?
LILO is similarly dead but still exists and tends to work more or less without issues. Still using it on a number of servers with current kernels and hardware (* the Debian-patched version). It at least does seem to not suffer from the compiler-dependant issues that syslinux has.
On 12/22/18 6:27 AM, Bjoern Franke wrote:
Hi Eli,
While I understand it's disappointing to not have desired features from the package, it does take some time to get those features when they suffer from being both unreleased code, and code on top of a package that doesn't validly build in 2018. Please wait, we are trying to get to a working state, and hopefully our syslinux maintainer will be able to resolve this sometime soon. Once we can trust the package actually works, we can move it to stable.
Hope this clears things up for you. :) Good luck.
I'm thankful for pointing out the issues regarding syslinux. I assumed some issues when seeing that 6.04 was not released since 2 years, but I did not assume that it is so bad. Sounds somehow like upstream is more or less dead? :/ But in MBR-land it seems to be the only alternative to grub?
Bootloaders seem to suffer from a depressing lack of competition. Much as I like grub, I can appreciate the sadness that is this lack. Apparently syslinux git (a.k.a. the future 6.04) will also finally support the ext4 "64bit" feature. Took them long enough. :( -- Eli Schwartz Bug Wrangler and Trusted User
Hello On Fri, Dec 21, 2018 at 3:34 AM Bjoern Franke <bjo@nord-west.org> wrote:
Hi,
I recently wanted to switch from grub to syslinux, but it could not boot my /boot-partition, because it uses XFS.
Unfortunately only syslinux 6.04 supports XFS, while we stick on 6.03. 6.04 is somehow a "testing" version, thought it has been out for 2 years, so I marked 6.03 as "out of date".
I'm wondering a bit why we stick on 6.03, even Debian stable[1] has 6.04.
It is the question you should really ask upstream developers. If the project is stable enough for Debian why they do not rollout a new release? Having project in usable-but-not-released state is confusing. Anyway, an alpha version of 6.04 is pushed to [testing]. The best thing one can do is to test it and make sure all the use-cases you need (e.g. XFS) work correctly. Happy holidays and happy testing.
participants (7)
-
Anatol Pomozov
-
Andy Pieters
-
Bjoern Franke
-
Eli Schwartz
-
Genes Lists
-
Jens John
-
Ralf Mardorf