OS vendor and version autodetection fails on Fedora #3149
Comments
|
As far as I know this variables are set by the function I think this function is rather fragile |
|
FYI: What variables are set by SetOSVendorAndVersion: Where those variables are used in ReaR scripts: so only those ReaR scripts should be left So it seems (according to that quick and dirty test) |
|
What directories we have where the value of such variables I exluded some generic directories or the BACKUP value and where So it seems only those values are actually used By the way: |
|
I have also found a related bug. If I create a custom rear/usr/share/rear/lib/framework-functions.sh Lines 120 to 125 in 096bfde For example, the initrd regeneration is then executed twice ( |
It is a supported |
|
Regarding scripts get called twice |
|
Regarding missing "OUTPUT=IPL" documentation in default.conf: @lzaoral |
|
@jsmeix I've found out, that the initial PR with s390x support in ReaR was a bit messy. The rear/usr/share/rear/output/IPL/Linux-s390/800_create_ipl.sh Lines 1 to 4 in d48d071 vs. rear/usr/share/rear/output/RAMDISK/default/900_copy_ramdisk.sh Lines 15 to 23 in d48d071 Therefore, I suggest to just remove the |
|
@lzaoral That IPL is redundant (same as RAMDISK) I fully agree with your proposed clean-up By the way regarding documentation about Could you write some initial documentation about Only something short so that we have a starting point In particular I would be much interested in In particular my main point where I know basically |
The initial PR with s390x support in ReaR introduced in s390/s390x-only OUTPUT option. However, the OUTPUT=IPL option is completely redundant because it does the exact same thing as the already existing and documented OUTPUT=RAMDISK option. This commit removes the whole IPL directory sub-tree and introduces a fallback that replaces OUTPUT=IPL with OUTPUT=RAMDISK during the prep phase with a deprecation warning to still be backwards compatible with existing local.conf files. Related: rear#3149 (comment)
The initial PR with s390 support in ReaR introduced an s390-only OUTPUT=IPL undocumented option. However, the OUTPUT=IPL option is completely redundant because it does the exact same thing as the already existing and documented OUTPUT=RAMDISK option. This commit removes the whole IPL directory sub-tree and introduces a fallback that replaces OUTPUT=IPL with OUTPUT=RAMDISK during the prep phase with a deprecation warning to still be backwards compatible with existing local.conf files. Related: rear#3149 (comment)
The initial PR with s390 support in ReaR introduced an s390-only OUTPUT=IPL undocumented option. However, the OUTPUT=IPL option is completely redundant because it does the exact same thing as the already existing and documented OUTPUT=RAMDISK option. This commit removes the whole IPL directory sub-tree and introduces a fallback that replaces OUTPUT=IPL with OUTPUT=RAMDISK during the prep phase with a deprecation warning to still be backwards compatible with existing local.conf files. Related: rear#3149 (comment)
The initial PR with s390 support in ReaR introduced an s390-only OUTPUT=IPL undocumented option. However, the OUTPUT=IPL option is completely redundant because it does the exact same thing as the already existing and documented OUTPUT=RAMDISK option. This commit removes the whole IPL directory sub-tree and introduces a fallback that replaces OUTPUT=IPL with OUTPUT=RAMDISK during the prep phase with a deprecation warning to still be backwards compatible with existing local.conf files. Related: rear#3149 (comment)
|
Hmm, the code used to parse the
edit: reformatted |
|
While investigating a possible solution for problems above, I've also found two additional problems:
|
The generation of the /etc/rear/os.conf file is permanent. Once it is created, it won't be regenerated unless it is manually removed. Therefore, it will contain incorrect values if ReaR detects them incorrectly (like in [1]) and/or will contain stale information after major version system upgrades. [1] rear#3149 (comment) Related: rear#3149 (comment)
The original code always assumed that the VERSION_ID value will be enclosed in quotation marks which is false on Fedora: ```console $ grep "^VERSION_ID=" /etc/os-release | cut -d\" -f2 VERSION_ID=39 ``` Related: rear#3149 (comment)
The generation of the /etc/rear/os.conf file is permanent. Once it is created, it won't be regenerated unless it is manually removed. Therefore, it will contain incorrect values if ReaR detects them incorrectly (like in [1]) and/or will contain stale information after major version system upgrades. [1] rear#3149 (comment) Related: rear#3149 (comment)
The original code always assumed that the VERSION_ID value will be enclosed in quotation marks which is false on Fedora: ```console $ grep "^VERSION_ID=" /etc/os-release | cut -d\" -f2 VERSION_ID=39 ``` Related: rear#3149 (comment)
|
@lzaoral |
The initial PR with s390 support in ReaR introduced undocumented OUTPUT=IPL which is redundant because it does the same thing as the documented OUTPUT=RAMDISK. This commit removes the IPL directory sub-tree and introduces a fallback that replaces OUTPUT=IPL with OUTPUT=RAMDISK during the prep phase with a deprecation warning, see rear#3153 and the related rear#3149 (comment)
Delete init/default/005_verify_os_conf.sh - reasoning: The generation of the /etc/rear/os.conf file is permanent. Once it is created, it won't be regenerated unless it is manually removed. Therefore, it will contain incorrect values if ReaR detects them incorrectly like in rear#3149 (comment) and/or it will contain stale information after major version system upgrades, see also rear#3149 (comment) Furthermore in lib/config-functions.sh in SetOSVendorAndVersion() fix the collection of VERSION_ID from /etc/os-release because the code had falsely assumed that the VERSION_ID value is enclosed in quotation marks which is false on Fedora, see rear#3165 and the related rear#3149 (comment)
The initial PR with s390 support in ReaR introduced undocumented OUTPUT=IPL which is redundant because it does the same thing as the documented OUTPUT=RAMDISK. This commit removes the IPL directory sub-tree and introduces a fallback that replaces OUTPUT=IPL with OUTPUT=RAMDISK during the prep phase with a deprecation warning, see rear#3153 and the related rear#3149 (comment)
Delete init/default/005_verify_os_conf.sh - reasoning: The generation of the /etc/rear/os.conf file is permanent. Once it is created, it won't be regenerated unless it is manually removed. Therefore, it will contain incorrect values if ReaR detects them incorrectly like in rear#3149 (comment) and/or it will contain stale information after major version system upgrades, see also rear#3149 (comment) Furthermore in lib/config-functions.sh in SetOSVendorAndVersion() fix the collection of VERSION_ID from /etc/os-release because the code had falsely assumed that the VERSION_ID value is enclosed in quotation marks which is false on Fedora, see rear#3165 and the related rear#3149 (comment)
In doc/user-guide/04-scenarios.adoc document booting of ReaR rescue initramfs on s390/s390x, see the related #3149 (comment)
On SUSE, the OS_MASTER_VENDOR variable is set to SUSE and not SUSE_LINUX. Since the code was still executed on this platform and no problems have been reported so far, let's assume that it is safe and remove this redundant condition. Related: rear#3149 (comment)
Before this change, ReaR would just grep /etc/os-release for suitable string. This is wrong because, e.g. Fedora was classified as RHEL because its /etc/os-release contains the 'redhat' string in URL for its issue tracker. os-release(5) [1] specifies ID and ID_LIKE fields for reliable identification of the distribution. First, use the ID_LIKE field to deal with derivative Linux distributions (e.g. CentOS and RHEL, or Ubuntu and Linux Mint). Then use ID to detect distributions that are either not a derivative (e.g. Arch or Fedora) or ReaR already recognized the derivate separately (e.g. Fedora vs. RHEL or Debian vs. Ubuntu). [1] https://www.freedesktop.org/software/systemd/man/latest/os-release.html Resolves: rear#3149
Contrary to its name, the OS_MASTER_VERSION variable was already used for this purpose for some versions, e.g. RHEL 7. This fixes version comparison on RHEL 8 and newer. Related: rear#3149 (comment)
This change ensures that OS_VENDOR and OS_MASTER_VENDOR will not be set to equal values which subsequently caused some ReaR stages to be sourced more than once. Related: rear#3149 (comment)
... because the plain 'Arch' could be confused with 'Architecture'. Related: rear#3149 (comment)
On SUSE, the OS_MASTER_VENDOR variable is set to SUSE and not SUSE_LINUX. Since the code was still executed on this platform and no problems have been reported so far, let's assume that it is safe and remove this redundant condition. Related: rear#3149 (comment)
Before this change, ReaR would just grep /etc/os-release for suitable string. This is wrong because, e.g. Fedora was classified as RHEL because its /etc/os-release contains the 'redhat' string in URL for its issue tracker. os-release(5) [1] specifies ID and ID_LIKE fields for reliable identification of the distribution. First, use the ID_LIKE field to deal with derivative Linux distributions (e.g. CentOS and RHEL, or Ubuntu and Linux Mint). Then use ID to detect distributions that are either not a derivative (e.g. Arch or Fedora) or ReaR already recognized the derivate separately (e.g. Fedora vs. RHEL or Debian vs. Ubuntu). [1] https://www.freedesktop.org/software/systemd/man/latest/os-release.html Resolves: rear#3149
Contrary to its name, the OS_MASTER_VERSION variable was already used for this purpose for some versions, e.g. RHEL 7. This fixes version comparison on RHEL 8 and newer. Related: rear#3149 (comment)
This change ensures that OS_VENDOR and OS_MASTER_VENDOR will not be set to equal values which subsequently caused some ReaR stages to be sourced more than once. Related: rear#3149 (comment)
... because the plain 'Arch' could be confused with 'Architecture'. Related: rear#3149 (comment)
On SUSE, the OS_MASTER_VENDOR variable is set to SUSE and not SUSE_LINUX. Since the code was still executed on this platform and no problems have been reported so far, let's assume that it is safe and remove this redundant condition. Related: rear#3149 (comment)
Before this change, ReaR would just grep /etc/os-release for suitable string. This is wrong because, e.g. Fedora was classified as RHEL because its /etc/os-release contains the 'redhat' string in URL for its issue tracker. os-release(5) [1] specifies ID and ID_LIKE fields for reliable identification of the distribution. First, use the ID_LIKE field to deal with derivative Linux distributions (e.g. CentOS and RHEL, or Ubuntu and Linux Mint). Then use ID to detect distributions that are either not a derivative (e.g. Arch or Fedora) or ReaR already recognized the derivate separately (e.g. Fedora vs. RHEL or Debian vs. Ubuntu). [1] https://www.freedesktop.org/software/systemd/man/latest/os-release.html Resolves: rear#3149
Contrary to its name, the OS_MASTER_VERSION variable was already used for this purpose for some versions, e.g. RHEL 7. This fixes version comparison on RHEL 8 and newer. Related: rear#3149 (comment)
This change ensures that OS_VENDOR and OS_MASTER_VENDOR will not be set to equal values which subsequently caused some ReaR stages to be sourced more than once. Related: rear#3149 (comment)
... because the plain 'Arch' could be confused with 'Architecture'. Related: rear#3149 (comment)
Before this change, ReaR would just grep /etc/os-release for suitable string. This is wrong because, e.g. Fedora was classified as RHEL because its /etc/os-release contains the 'redhat' string in URL for its issue tracker. os-release(5) [1] specifies ID and ID_LIKE fields for reliable identification of the distribution. First, use the ID_LIKE field to deal with derivative Linux distributions (e.g. CentOS and RHEL, or Ubuntu and Linux Mint). Then use ID to detect distributions that are either not a derivative (e.g. Arch or Fedora) or ReaR already recognized the derivate separately (e.g. Fedora vs. RHEL or Debian vs. Ubuntu). [1] https://www.freedesktop.org/software/systemd/man/latest/os-release.html Resolves: rear#3149
Contrary to its name, the OS_MASTER_VERSION variable was already used for this purpose for some versions, e.g. RHEL 7. This fixes version comparison on RHEL 8 and newer. Related: rear#3149 (comment)
This change ensures that OS_VENDOR and OS_MASTER_VENDOR will not be set to equal values which subsequently caused some ReaR stages to be sourced more than once. Related: rear#3149 (comment)
... because the plain 'Arch' could be confused with 'Architecture'. Related: rear#3149 (comment)
|
Stale issue message |
ReaR version ("/usr/sbin/rear -V"): latest
HEADOS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
ReaR does not properly detect OS vendor and version on Fedora:
The version should be only
39and notVERSION_ID=39and the vendor should beFedora. Therefore, both theOS_VENDOR_*andOS_MASTER_VENDOR_*should be equal.cc: @pcahyna
The text was updated successfully, but these errors were encountered: