Salix Forums

I just can tell you the last time I saw that message it didn't work and I have an idea what's going on. It was fixed by the exact same procedure though: http://www.salixos.org/forum/viewtopic. ... 4&start=30

flebber wrote:...when I boot into the usb it is recognised starts to load but stops at the intro line Syslinux Peter Anvin... This occured for both Mate and Kde.
...
What am I doing wrong?

Shador wrote: you have a more recent version of syslinux 4.05 opposed to 3.84 shipped with Salix.

Of course that's a (and probably "the") problem, independently of anything else.

First, if flebber adds LILO to the MBR of the UFD, then the syslinux loader shouldn't matter much.

But if he is booting the UFD with syslinux, then all the components should be the exact same version (including the loader, com32 modules, memdisk...). In some particular cases, some com32 module could work with a slightly different version, as for example using a com32 module from syslinux 4.04 and booting with the 4.05 loader. But there is no doubt that if you use modules and menu syntax from 3.84 in Salix, the boot loader should be the one in syslinux 3.84 too.

Adys wrote: First, if flebber adds LILO to the MBR of the UFD, then the syslinux loader shouldn't matter much.

I don't think it's clear what lilo is doing here. The install-on-USB.sh script never installs a full lilo bootloader to the MBR. Instead it's just called to write a very simple MBR loader, which just loads the active partition. Actually this is the same the fixmbr command does on windows. Some such code is usually there by default.
Therefor the syslinux loader does matter!
This approach is the idea with the msdos design. BIOS loads first 440 bytes from the mbr of the boot device. That code just checks which partition is active and loads the OS loader from that partitions beginning.
The whole system is not that great as it turned out. At least why would they have changed it significantly with EFI otherwise.

Adys wrote:But if he is booting the UFD with syslinux, then all the components should be the exact same version (including the loader, com32 modules, memdisk...). In some particular cases, some com32 module could work with a slightly different version, as for example using a com32 module from syslinux 4.04 and booting with the 4.05 loader. But there is no doubt that if you use modules and menu syntax from 3.84 in Salix, the boot loader should be the one in syslinux 3.84 too.

I agree. But as far as I know when the syslinux command is called to install syslinux all those files are copied over in a working version. Actually I think we're not using any modules as syslinux is just loading a self-contained grub2 image. Grub2 is not installed directly because it's much harder to install in a predictable, compatible version from different OS.
In the future we could try to install syslinux directly to the MBR as far as possible. Maybe that helps a bit.

It seemed like a good idea to ship a version of grub2 that is known to work and can be loaded like a linux kernel as we don't get problems by different versions or patches applied by different distros. There does not seem to me a more reliable and easier solution to load that grub2 version than providing an image that can be loaded like a linux kernel by any no matter how simple bootloader. Obviously we wanted to give you the choice to use the same menu as provided by an actual Live CD.

This topic is marked as [solved], so this is just FYI.

According to the feedback from flebber, the UFD is booting and working correctly, but... I don't know what (form BIS results.txt)

The integrity check of the ADV area failed

means.

@Shador, the following is NOT correct:

when the syslinux command is called to install syslinux all those files are copied over in a working version

.

What the installer of syslinux essentially performs is:
1_ copy ldlinux.sys to the indicated (by the installer command) location;
2_ modify the MBR/PBR with the exact location of ldlinux.sys.

So the rest of the files (modules, memdisk and so on) need to be updated to the respective version separately, either manually or by means of some script.

AFAIK, in the case of unetbootin the menu.c32 module and the respective syslinux.cfg file are added, so the version of that first menu.c32 should be compatible with what unetbootin does about ldlinux.sys and in the MBR of the UFD. Neither unetbootin nor the syslinux installer would touch any other component of syslinux that any distro would already contain within the original ISO (now expanded in the UFD by unetbootin).

In short: if a user manually updates the MBR/PBR and ldlinux.sys with the syslinux installer, then it is also recommended to manually update (copy over) all the syslinux components in the UFD (in whichever directory they would be located). This is the general recommendation, but there are some cases where components of different versions of syslinux would work together correctly anyway.

Yes you're totally right Adys.

Adys wrote:In short: if a user manually updates the MBR/PBR and ldlinux.sys with the syslinux installer, then it is also recommended to manually update (copy over) all the syslinux components in the UFD (in whichever directory they would be located). This is the general recommendation, but there are some cases where components of different versions of syslinux would work together correctly anyway.

Yes, that's right, I should have further restricted my original statement.
Anyway, I still believe we don't use any other syslinux components than those installed by the syslinux executable i.e. ldlinux.sys. Our menu is almost as simple as the default config: I'll try to verify this by removing everything that should not be necessary when I get to it.

Adys wrote:The integrity check of the ADV area failed

Yes, I'm seeing such messages about integrity checks of the boot-info-script too. But it never caused any problem as far as I can tell.