relative paths in cfg

The file:

/ubcd/menus/syslinux/main.cfg

contains an entry for PartedMagic.

The entry for PMagic has:

CONFIG /pmagic/boot/syslinux/syslinux.cfg

so it points to that specific syslinux.cfg file (located in that specific *absolute* path) for the boot menu of PMagic.

Is there any way to use RELATIVE paths in that CONFIG line in the PMagic entry of that main.cfg ?

Maybe using characters as " .. " (parent directory) or alike ?

AFAIK, when using relative paths in syslinux, they are relative to the directory where the cfg file is located.

Since the above syslinux.cfg file is NOT under the same path tree as the above main.cfg, I am looking for some way to relate them in the CONFIG line but still using *relative* paths, instead of the currently used absolute path.

Any suggestions or (links to) examples?

TIA.

Since the rest of the pmagic.cfg file is "hard wired" to use the absolute paths of /pmagic - AND (AFAIK) even the linux kernel it loads and the initramfs are hardwired that way too, what is the value in using relative paths? Or why are you trying to do this? What is the reason behind asking about this, since sometimes knowing WHY can help some of us figure out an alternative...

Thanks for your post.

The pmagic.cfg is easy to change to relative paths (since the locations of PMagic are still going to be relative to the pmagic.cfg location; meaning under the same tree without having to get to any parent directory).

For the kernel of PMagic, there are relevant codes if needed (for the directory, root, and so on).

Those shouldn't be a problem.

By learning how to use relative path to parent directories, I could make it more flexible when combined with other tools.

For example, when you put the original UBCD ISO image in an UFD subfolder, then you can't boot PMagic from the original menu of UBCD, since it uses absolute paths. For example, currently SARDU 2.0.4 beta would work (the ISO for UBCD with PMagic is expanded), but YUMI won't (it uses the ISO itself).

Of course, if I would already have to edit the cfg file, then I could simply edit the path to the new location and keep it as absolute. But I still want to learn about the relative paths in the cfg files, because I think it would give more flexibility, or it would be easier to update.

Eventually, with some experiments, I could suggest some changes to Victor (the developer of UBCD) so to make it more flexible to use it in combination with other tools.

The relative paths issue is clear when it is based in the cfg location (and the CONFIG line has an optional parameter to change the base location too), but what I don't know is how to use the relative paths in the cfg file when the path is not in the same tree.

I hope I was clear.

Yes, this is clear, but I'm not sure without looking into the actual code how syslinux treats paths. Is that something you are able to do (i.e. wade through the code?)?

Maybe someone else knows???

I'm not a programmer, so I have no idea about the code.

Here is a simple example of why this (knowledge) would be useful.

Say you need to move the complete tree from the root of the media to some subfolder one level down. Instead of having to review every cfg file and paths so to manually correct them, using relative paths would be much easier, pointing the the main cfg file first, and the rest should work correctly (maybe with some additional cheatcode in some cases).

But when all the cfg files use absolute paths, then each file needs to be edited.

This example / case is simple to solve (in theory, by removing the first slash from the paths) when you know where to look. My intention is to make it simple also for other cases as I described in my previous post.

Unfortunately, I have no idea about the code, and what I wrote here comes from the syslinux wiki and the help files (and asking and reading and...).

I hope someone has some input about this.

TIA.

Yes, this is good logical thinking...BUT, the issue is also that tools like PMagic can't be moved higher or lower. This is because of the way the LINUX that they boot is constructed.

If you look in the pmagic folder, you will see the following three things...

1. pmodules ( a folder that can take additional modules)
2. bzimage
3. initramfs

Here, the bzImage is the boot image that then loads in the initramfs (the Initial RAM File System), which has the bare bones of the Linux OS on it, with other initialization code that loads in the "squashed" files system from the pmodules folder. And given how access to the media is managed to FIND that file, it MUST be in a folder located at /pmagic/pmodules - It can NOT be anywhere else.

There are a lot of issues with the hand-offs from boot loaders working at the BIOS level to protected drivers...Go read here at the forum on all the issues with booting ISO files in grub4dos and things like FiraDisk and WinVBlock, etc. This is why there are special tools like XBoot and SARDU that have to have specific knowledge of how an ISO was built in order to allow them to be combined onto a boot media, etc.

So, while a good idea in theory, in practice, it is not really practical to use relative paths for things like this...

BUT, it never hurts to ask, since it still might be useful in some other case...

Scott

I want to clarify.

The pmagic + UBCD was an example; one well-known. The relative paths could be helpful for other cases. In fact, the default for syslinux is to use relative paths, unless you start the path with the root.

In the case of PMagic, it is not entirely accurate that the paths are "fixed" and that they can't be anything else. Actually UBCD, which contains some version of PMagic, changes the default origin of the path tree.

The booting code of PMagic accepts "root=", "directory=" and "iso_filename=" (among others) to change the original default tree
( /$DIRECTORY/pmagic/pmodules/ ).

Since you mentioned auxiliary tools (XBOOT and SARDU), this "quest" started actually because YUMI (another auxiliary tool) copies the entire UBCD ISO image "as is" into a subfolder ("\ISO\") different than the ones already provided as optional by PMagic. The result is that UBCD boots, but then PMagic (started from UBCD, which started from YUMI menu) can't be booted from the syslinux menu.

There are (not so basic) manual workarounds to this YUMI problem, but then using YUMI for this is not worthy. The whole point of such auxiliary tools is to make it simple( -r ) and more accessible for the "average" non-technical user.

So, let me put it this way. Even if it is not for the specific example I mentioned, I am still interested in learning how to use relative paths to parent directories from the location of the starting cfg file.

I still hope someone knows about this, or that can point into the correct direction.

TIA.

Yes, you are correct that the Pmagic files allow a user to pass in additional parameters to the initial linux kernel to compensate. And yes, relative paths MAY make it easier for a noobie to compensate here as opposed to just adding in the other init parameters to change where pmagic finds it's files...

So, yes, hopefully someone can tell us *IF* there is a way to specify an "upwards" path, and not just a from here downward path...