RPM needs to require syslinux-extlinux

[burghart]

On Fedora 18, REAR freshly installed via yum fails when attempting mkbackup:

# rear -v mkbackup
Relax-and-Recover 1.14 / Git
Using log file: /var/log/rear/rear-foo.log
ERROR: Could not find 'isolinux.bin'. Maybe you have to set ISO_ISOLINUX_BIN [] or install the syslinux package ?
Aborting due to an error, check /var/log/rear/rear-foo.log for details

After installing the syslinux and syslinux-extlinux packages, REAR works normally.

I see that the latest rear.spec in the repository includes syslinux as a dependency, but does not include syslinux-extlinux.

[gdha]

the package syslinux-extlinux is only required in combination of OUTPUT=USB to be able to boot from an USB device. As such it is not a basic requirement for rear itself, and for that reason we think it is not needed to make it a dependency. Perhaps, a markdown in the documentation would be better.

[schlomo]

Maybe we should exit with a better error message like "Please install XXX
package to support YYY"? We could do these checks fairly early in the prep
stage.

On 18 June 2013 09:08, gdha notifications@github.com wrote:

the package syslinux-extlinux is only required in combination of
OUTPUT=USB to be able to boot from an USB device. As such it is not a
basic requirement for rear itself, and for that reason we think it is not
needed to make it a dependency. Perhaps, a markdown in the documentation
would be better.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/250#issuecomment-19594606
.

[burghart]

I think that most users assume that a packaged piece of software, with its dependencies, will provide the complete set of documented function. For that reason, I would argue that everything which may be used by REAR would be considered a package dependency. Disk space is cheap, and (without looking deeply into the code) I expect the list of dependencies would be manageable. In the end, it is probably simpler to go this route than to alter error messages. And I think that broader adoption of REAR is more likely if everything "just works" out of the box.

Of course complete choice of pieces to install would still be available to those working from the git repository rather than using RPM.

[burghart]

As a follow-up, I see that this comment (#247 (comment)) on a similar issue makes it clear that generating a full dependency list as I describe above will be difficult because of different package availability on different distributions.

Still, I would argue that the dependency list should provide as much function as (reasonably) possible.

[schlomo]

I agree, but was overruled previously. Some like a slim system.

So what about the following compromise :

We add a subpackage called rear-everything (or whatever speaks for itself)
which requires rear and also everything that rear could use and that is
available from the default repos

That way slim system lovers would not be bothered and you could install
rear with all potential tools in one go.

What do you think?
Am 18.06.2013 18:15 schrieb "burghart" notifications@github.com:

As a follow-up, I see that this comment (#247#247 (comment))
on a similar issue makes it clear that generating a full dependency list as
I describe above will be difficult because of different package
availability on different distributions.

Still, I would argue that the dependency list should provide as much
function as (reasonably) possible.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/250#issuecomment-19622312
.

[dagwieers]

@burghart How far are you willing to take the "everything which may be used by REAR would be considered a package dependency" ? Should we add every backup software supported as a dependency, knowing that the user will only be using one ? Same for transport options, should we require everything while only one is being used ?

For other types of software I would agree, but Relax-and-Recover is an exception to the rule IMO. At the moment we only have the most common tools that are required by the default configuration set as dependencies. For e.g. Debian-style packages we could (and should) add suggested software though.

[dagwieers]

BTW I am all for improving the communication to the user, but would hate to see one script per tool though.

[burghart]

OK, I can see that the dependency list could could quickly slide down a slippery slope. Can we come up with a short list which would accommodate the majority of uses, though? E.g, would tar + ISO + USB provide 90%+ coverage?

[dagwieers]

I wouldn't mind adding syslinux-extlinux, but then we don't have a clear rule anymore ;-)

I agree with you that tar + ISO by itself is not sufficient for most users, but the type of media/transport they use might be very diverse. USB would be a small minority IMO (and I am probably already biased since I wrote a large part of the USB code ;-)) We do not have any metrics to base a decision on.

We could look at the impact of each dependency and base a decision on that, syslinux-extlinux and lftp are pretty self-contained and small tools.

[burghart]

My statistics come from an unrepresentative sample of 3 users. All of us use USB. :-) More significantly, though, the example in the QUICK START GUIDE uses USB. Perhaps that's enough reason to add one requirement...

In the end, maybe more complete documentation on configuration should be explicit about dependencies, i.e., NETFS -> tar, USB -> syslinux-extlinux, ISO -> mkisofs + genisoimage, etc.

[schlomo]

@burghart How far are you willing to take the "everything which may be used by REAR would be considered a package dependency" ? Should we add every backup software supported as a dependency, knowing that the user will only be using one ? Same for transport options, should we require everything while only one is being used ?

I actually would draw the line at stuff that runs a service. IMHO it is legitimate to pull in all dependencies that are just tools that do not eat up any CPU or RAM after installation.

[burghart]

@schlomo That seems like a reasonable cut-off to me.

[dagwieers]

@schlomo Like redhat-lsb that pulled cups, gtk and gnome libraries and X on RHEL5 ? cfg2html ? Bacula ? Other backup-clients ? I am not convinced that there is any merit in installing all tools on all systems for every user where only a few tools are needed. As a system engineer it would be a no-go if a package pulls in everything it potentially could make use of all at once. I would not even evaluate software that did this to my system by default.

Dependencies (like on RPM-based distributions) were not designed for a tool like Relax-and-Recover where dependencies depend on usage/configuration IMO.

At the moment the RPM (on RHEL) strictly requires:

• binutils
• crontabs
• ethtool
• gzip
• iproute
• iputils
• mingetty
• mkisofs
• parted
• syslinux
• tar
• util-linux

We don't add things like:

• bacula-mysql
• cfg2html
• lsscsi
• nfsclient
• portmap
• redhat-lsb (for RHEL5)
• rpcbind
• rsync
• sg3_utils

although they've been commented in the SPEC file. Again, I wouldn't mind adding lftp, rsync or syslinux-extlinux because they are small (on disk), are likely to be needed (best guess) and have no impact on a running server. Yet, I wouldn't be adding cfg2html, lsscsi or sg3_utils (or the other examples).

We also do not require grub, grub2, lilo and syslinux, just because one of these bootloaders is being used. For the same reason IMO.

[schlomo]

@dagwieers what do you think about providing a rear-everything RPM which contains all dependencies for all optional tools (that don't run as a service)?

And yes, I hate RH for not splitting the lsb package like Debian/Ubuntu does.

[gdha]

I think that missing pre-requisites can be reported by existing (or new) prep/ scripts. I would avoid making the rear.spec file too complex

[bgausden]

I didn't see in the docs anything related to syslinux-extlinux being required.

Actually everything worked up to the point where I tried a test recovery and found that it's impossible to boot from USB. I walked away and didn't come back to REAR for over 6 months, spending some more time today to understand where I'd gone wrong.

If syslinux-extlinux isn't going to be a dependency then could we at least make it clear in the docs that if your OUTPUT is USB you'll need syslinux-extlinux installed for this to work?

[schlomo]

Hi,

you are right of course. However, I would expect that in your case latest
the
https://github.com/rear/rear/blob/master/usr/share/rear/output/USB/Linux-i386/85_make_USB_bootable.shscript
should bail out with an error if extlinux is not found.

Can you please confirm that rear mkrescue runs through without errors with
OUTPUT=USB and extlinux not installed?

Regards,
Schlomo

On 28 May 2014 10:05, Barry Gausden notifications@github.com wrote:

I didn't see in the docs anything related to syslinux-extlinux being
required.

Actually everything worked up to the point where I tried a test recovery
and found that it's impossible to boot from USB. I walked away and didn't
come back to REAR for over 6 months, spending some more time today to
understand where I'd gone wrong.

If syslinux-extlinux isn't going to be a dependency then could we at least
make it clear in the docs that if your OUTPUT is USB you'll need
syslinux-extlinux installed for this to work?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/250#issuecomment-44376506
.

[bgausden]

rear --version

Relax-and-Recover 1.16 / Git

rpm -qi syslinux-extlinux

package syslinux-extlinux is not installed

cat /etc/redhat-release

CentOS release 5.3 (Final)

Happily runs right through but results in an un-bootable volume in that the boot loader can't grok the extlinux.conf file resulting in a mangled boot menu.

2014-05-28 16:26:18 Finished running 'output' stage in 2 seconds
2014-05-28 16:26:18 Finished running mkrescue workflow
2014-05-28 16:26:18 Running exit tasks.
2014-05-28 16:26:18 Finished in 17 seconds
2014-05-28 16:26:18 Removing build area /tmp/rear.MAyHKPdNJQ22583
rmdir: removing directory, /tmp/rear.MAyHKPdNJQ22583
2014-05-28 16:26:18 End of program reached

I've compared my version of 85_make_USB with that in the Master and they're identical.

Only by installing syslinux-extlinux on the system being backed up does the resulting USB volume have a functional boot menu.

[schlomo]

Does "rear -s mkrescue" actually show that 85_make_USB script? If yes then
please add a set -x to this script to see why it does not try to call
extlinux.

On 28 May 2014 10:41, Barry Gausden notifications@github.com wrote:

rear --version

Relax-and-Recover 1.16 / Git

rpm -qi syslinux-extlinux

package syslinux-extlinux is not installed

cat /etc/redhat-release

CentOS release 5.3 (Final)

Happily runs right through but results in an un-bootable volume in that
the boot loader can't grok the extlinux.conf file resulting in a mangled
boot menu.

2014-05-28 16:26:18 Finished running 'output' stage in 2 seconds
2014-05-28 16:26:18 Finished running mkrescue workflow
2014-05-28 16:26:18 Running exit tasks.
2014-05-28 16:26:18 Finished in 17 seconds
2014-05-28 16:26:18 Removing build area /tmp/rear.MAyHKPdNJQ22583
rmdir: removing directory, /tmp/rear.MAyHKPdNJQ22583
2014-05-28 16:26:18 End of program reached

I've compared my version of 85_make_USB with that in the Master and
they're identical.

Only by installing syslinux-extlinux on the system being backed up does
the resulting USB volume have a functional boot menu.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/250#issuecomment-44379411
.

[bgausden]

Re-formatted the disk and tried again. Now it bombs out.

The disk was originally created with an earlier version of rear. It would appear that's somehow interfering with the check for extlinux.

All good on this front then.

Just the matter of the user finding out in a slightly more friendly way that extlinux is required...

[gdha]

by adding the prep script to check for extlinux I think we may close this issue, right?

[burghart]

The new usr/share/rear/prep/USB/Linux-i386/40_check_extlinux.sh prep script gives a more useful error message now when syslinux-extlinux is not installed. I'm willing to consider the issue closed.