#2971 Issue closed: Fedora: GRUB2 can't find command 'echo' 'linux' 'initrd' 'linuxefi' 'initrdefi' 'search' 'chainloader' 'reboot' 'exit'¶
Labels: enhancement, bug, fixed / solved / done,
external tool, not ReaR / invalid
Jerry2840 opened issue at 2023-04-21 03:38:¶
-
ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.6 / 2020-06-17 -
If your ReaR version is not the current version, explain why you can't upgrade:
Using Fedora 38 current package: rear-2.6-9.fc38.x86_64 -
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=VERSION_ID=38
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
/etc/rear/local.conf"):
local.conf is all comments.
site.conf:
OUTPUT=USB
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}" '/tmp/*' '/jerry/*' )
USB_UEFI_PART_SIZE="512"
TIMESYNC=CHRONY
-
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
ASUS C202SA Chrome book
dmidecode shows:
System Information
Manufacturer: GOOGLE
Product Name: Terra -
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
Intel(R) Celeron(R) CPU N3060 @ 1.60GHz
x86_64 -
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
UEFI GRUB -
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
16G eMMC -
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
The storage layout is the default that Fedora Workstation 38 creates.
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/sda /dev/sda usb disk udf RELAXRECOVER 28.6G
|-/dev/sda1 /dev/sda1 /dev/sda part vfat REAR-EFI 512M
`-/dev/sda2 /dev/sda2 /dev/sda part ext3 REAR-000 28.1G /tmp/rear.TUzMKqWPJoXOn8X/outputfs
/dev/mmcblk0 /dev/mmcblk0 disk 14.7G
|-/dev/mmcblk0p1 /dev/mmcblk0p1 /dev/mmcblk0 part vfat 600M /boot/efi
|-/dev/mmcblk0p2 /dev/mmcblk0p2 /dev/mmcblk0 part ext4 1G /boot
`-/dev/mmcblk0p3 /dev/mmcblk0p3 /dev/mmcblk0 part btrfs fedora_localhost-live 13.1G /home
/dev/mmcblk0boot0 /dev/mmcblk0boot0 disk 4M
/dev/mmcblk0boot1 /dev/mmcblk0boot1 disk 4M
/dev/zram0 /dev/zram0 disk 3.8G [SWAP]
- Description of the issue (ideally so that others can reproduce
it):
I just see the error in the log file /var/log/rear/rear-c202s.log about the integer expression expected.
I do have the problem that the USB flash drive boots and I get the menu, but I get all of these messages for each menu item.
I am listing the visible menu item that you see on the screen and then error lines are what I see when I hit enter to select the menu item.
GRUB version 2.06
Relax-and-Recover (no Secure Boot)
error: ../../grub-core/script/function.c:119:can't find command `echo'.
error: ../../grub-core/script/function.c:119:can't find command `linux'.
error: ../../grub-core/script/function.c:119:can't find command `echo'.
error: ../../grub-core/script/function.c:119:can't find command `initrd'.
Press any key to continue...
Relax-and-Recover (no Secure Boot)
error: ../../grub-core/script/function.c:119:can't find command `echo'.
error: ../../grub-core/script/function.c:119:can't find command `linuxefi'.
error: ../../grub-core/script/function.c:119:can't find command `echo'.
error: ../../grub-core/script/function.c:119:can't find command `initrdefi'.
Press any key to continue...
Boot original system
error: ../../grub-core/script/function.c:119:can't find command `search'.
error: ../../grub-core/script/function.c:119:can't find command `chainloader'.
Press any key to continue...
Reboot
error: ../../grub-core/script/function.c:119:can't find command `reboot'.
Press any key to continue...
Exit to EFI Shell
error: ../../grub-core/script/function.c:119:can't find command `exit'.
Press any key to continue...
-
Workaround, if any:
-
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
You can drag-drop log files into this editor to create an attachment
or paste verbatim text like command output or file content
by including it between a leading and a closing line of
three backticks like this:
https://github.com/rear/rear/blob/master/usr/share/rear/layout/save/default/950_verify_disklayout_file.sh#L82
I added the Log line so I could see what it was comparing and saw the p1
highest_used_part_num=0
for partition in "${partitions[@]}" ; do
# We test only partitions of the form /dev/sdX1 /dev/sdX2 /dev/sdX3 (i.e. of the form $disk_dev$part_num).
part_num=${partition#$disk_dev}
Log "part_num = $part_num highest_used_part_num = $highest_used_part_num"
test $part_num -gt $highest_used_part_num && highest_used_part_num=$part_num
done
2023-04-20 20:45:28.338509014 part_num = p1 highest_used_part_num = 0
/usr/share/rear/layout/save/default/950_verify_disklayout_file.sh: line 83: test: p1: integer expression expected
2023-04-20 20:45:28.345388057 part_num = p2 highest_used_part_num = 0
/usr/share/rear/layout/save/default/950_verify_disklayout_file.sh: line 83: test: p2: integer expression expected
2023-04-20 20:45:28.351797496 part_num = p3 highest_used_part_num = 0
jsmeix commented at 2023-04-21 06:51:¶
The messages in
https://github.com/rear/rear/files/11291981/rear-c202s.log
/usr/share/rear/layout/save/default/950_verify_disklayout_file.sh: line 83: test: p1: integer expression expected
/usr/share/rear/layout/save/default/950_verify_disklayout_file.sh: line 83: test: p2: integer expression expected
/usr/share/rear/layout/save/default/950_verify_disklayout_file.sh: line 83: test: p3: integer expression expected
are unrelated to the GRUB2 error messages.
Regarding the 'integer expression expected' messages:
In general what layout/save/default/950_verify_disklayout_file.sh
does
is not required functionality to make ReaR work because it is only
there
as a safeguard that the entries in disklayout.conf are syntactically
OK
which they should normally be.
The part in layout/save/default/950_verify_disklayout_file.sh
that results those 'integer expression expected' messages
only checks for non consecutive partitions and only when
partitions of the form /dev/sdX1 /dev/sdX2 /dev/sdX3
(i.e. of the form $disk_dev$part_num) are used,
see the comments in that code.
When partition device nodes like /dev/mmcblk0p1 /dev/mmcblk0p2
/dev/mmcblk0p3 /dev/mmcblk0boot0 /dev/mmcblk0boot1 are used
(i.e. of the form ${disk_dev}p$part_num)
that test is skipped.
So the 'integer expression expected' messages
are no errors but expected failures of the 'test'
to also find out if the form $disk_dev$part_num is used.
@Jerry2840
in general when you run ReaR (or any other rogram) in debug mode
you may get various kind of messages that indicate this or that
failures
but you would need to understand what is actually meant to happen
in each case to decide if a failure is expected and handled
or if a failure is unexpected and indicates a real error.
For example on my currently used computer:
# dmesg | egrep -i 'fail|error'
[ 0.000000] tsc: Fast TSC calibration failed
[ 0.000000] DMAR: Parse DMAR table failure.
[ 3.400876] RAS: Correctable Errors collector initialized.
[ 46.184357] ACPI BIOS Error (bug): Could not resolve symbol [\_TZ.PSL.CFGD], AE_NOT_FOUND (20210730/psargs-330)
[ 46.185935] ACPI Error: Aborting method \_TZ.PSL due to previous error (AE_NOT_FOUND) (20210730/psparse-531)
...
My computer works perfectly well for me as far as I can tell
and I don't have sufficient low-level knowledge to decide
if those messages mean or indicate some real problem
so I just ignore them and go on bona fide.
jsmeix commented at 2023-04-21 06:57:¶
Regarding the GRUB2 error messages
I am afraid I cannot really help here
because I am not a sufficient GRUB2 expert
to imagine what their reason could be.
Only a blind guess
in particular because you use a Red Hat system
(but I am not a Red Hat user):
As far as I know on Red Hat based systems
the whole GRUB2 software is split into several RPM packages
and by default not all GRUB2 software is installed - in particular
some GRUB2 modules are not installed by default - so you may
need to additionally install certain GRUB2 RPM packages
to get GRUB2 working for ReaR.
See
https://github.com/rear/rear/issues/2783#issuecomment-1085678921
jsmeix commented at 2023-04-21 07:01:¶
@pcahyna
could you have a look here (as time permits)
regarding the GRUB2 error messages?
jsmeix commented at 2023-04-21 07:32:¶
Via
https://github.com/rear/rear/commit/c8f5e3f41c970a89304cd2b1bc5d04a2d2a7fdb4
in layout/save/default/950_verify_disklayout_file.sh
it now suppresses unhelpful stderr messages like
"test: p1: integer expression expected"
that appear for partitions of the form like
/dev/mmcblk0p1 (i.e. of the form ${disk_dev}p$part_num).
Later if needed and as time permits
layout/save/default/950_verify_disklayout_file.sh
may be enhanced to check for non consecutive partitions
also for partitions of the form like
/dev/mmcblk0p1 (i.e. of the form ${disk_dev}p$part_num).
Probably this is not needed in practice because
the parted versions that are nowadays used
should be sufficiently new so that they
support FEATURE_PARTED_RESIZEPART or FEATURE_PARTED_RESIZE
(i.e. the 'resizepart' or 'resize' command),
cf. lib/layout-functions.sh
schlomo commented at 2023-04-23 09:19:¶
First of all, @Jerry2840, big congratulations of probably being the first ReaR user on a Chromebook 😄 (I also use an old Chromebook as a "kitchen dashboard"...)
Your GRUB2 error looks like the Grub modules are missing or not found,
please take a look at your rescue media and check the location of the
echo.mod file on it. In your logfile I found this line
grub2-mkstandalone: info: copying `/usr/lib/grub/x86_64-efi/echo.mod' -> `/tmp/grub.XXpN8c/boot/grub/x86_64-efi/echo.mod'.
which suggests that the module was copied, but maybe it got copied to the wrong place.
github-actions commented at 2023-06-23 02:48:¶
Stale issue message
pcahyna commented at 2023-06-23 14:27:¶
Hello, sorry for the late reply. If you still can reproduce the issue, I wonder what is in the GRUB image if you can get to the GRUB shell. Do you have the (memdisk) device? grub2-mkstandalone creates this. To find out what modules you have, use
ls (memdisk)/boot/grub/x86_64-efi/
If (memdisk) is not there, I suspect you have booted a different GRUB image than the one produced by ReaR.
pcahyna commented at 2023-06-27 14:13:¶
I found more details. I can reproduce the problem starting with Fedora 37 (Fedora 36 was fine). In the GRUB image produced on Fedora 37 we have
prefix=(hd1,gpt1)/EFI/BOOT
root=memdisk
(hd1 is the USB disk where ReaR has been booted from). This does not
work, as /EFI/BOOT on the ReaR image does not contain any GRUB
modules.
If I execute
set prefix=(memdisk)/boot/grub
set root=hd1,gpt
then I can boot the rescue system.
In Fedora 36 I have
prefix=(memdisk)/boot/grub
root=hd1,gpt1
and the image works out of the box. So, something has changed with variables in the image produced by grub2-mkstandalone between Fedora 36 and Fedora 37.
jsmeix commented at 2023-08-08 13:00:¶
Since
https://github.com/rear/rear/pull/3031
is merged
there is Secure Boot support for OUTPUT=USB
in our ReaR upstream master code.
The basic idea for Secure Boot booting of the ReaR recovery system
is to "just copy" the (signed) EFI binaries of the Linux distribution
(shim*.efi and grub*.efi as first and second stage UEFI bootloaders)
instead of let ReaR make its own EFI binary via build_bootx86_efi()
and @pcahyna shows in his
https://github.com/rear/rear/pull/3031#issuecomment-1669336117
that this also works for normal UEFI boot
(i.e. UEFI boot with Secure Boot disabled)
at least on RHEL 9.
So it could be a possible workaround for now
to "misuse" the new Secure Boot support for OUTPUT=USB
via something like (in local.conf or site.conf)
SECURE_BOOT_BOOTLOADER=/boot/efi/EFI/redhat/shimx64.efi
(specify the actual 'shim*.efi' file on your system)
for normal UEFI boot (i.e. with Secure Boot disabled).
@Jerry2840
could you try out if this workaround
actually makes things work for you?
See the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
how you could try out the current ReaR upstream GitHub master code
from within a separated directory as a test to find out
if things work better with current ReaR upstream master code
compared to your installed ReaR version.
github-actions commented at 2023-10-10 02:03:¶
Stale issue message
pcahyna commented at 2023-10-10 13:56:¶
So it could be a possible workaround for now to "misuse" the new Secure Boot support for OUTPUT=USB via something like (in local.conf or site.conf)
SECURE_BOOT_BOOTLOADER=/boot/efi/EFI/redhat/shimx64.efi(specify the actual 'shim*.efi' file on your system) for normal UEFI boot (i.e. with Secure Boot disabled).
That should indeed work and we should actually make this the default,
i.e. always use the OS-provided GRUB image (and the Secure Boot shim if
present), without having to set SECURE_BOOT_BOOTLOADER manually.
github-actions commented at 2023-12-10 02:11:¶
Stale issue message
github-actions commented at 2024-02-11 02:05:¶
Stale issue message
pcahyna commented at 2024-02-15 12:53:¶
@Jerry2840 is it still a problem? If so, have you tried the workaround suggested above?
lzaoral commented at 2024-02-15 14:45:¶
@Jerry2840 Could you please try the following Fedora 38 update? https://bodhi.fedoraproject.org/updates/FEDORA-2024-49ddbf447d
ReaR in Fedora has been unmaintained for a year at least so the update above should fix a lot of problems you may encounter.
lzaoral commented at 2024-02-16 09:39:¶
The issue is actually caused by a regression in the grub2 package
which was fixed by the following commit
https://src.fedoraproject.org/rpms/grub2/c/8dde55b253cc29289794efe91e70f70f23c79a83
in grub2-2.06-110.fc38 on Fedora 38.
pcahyna commented at 2024-03-04 18:49:¶
The GRUB bug in Fedora was fixed about a month ago, https://bugzilla.redhat.com/show_bug.cgi?id=2209435. (The bug description mentions PXE, but the mkstandalone image problem is caused by the same issue.) Closing.
[Export of Github issue for rear/rear.]