#2666 Issue closed: Further enhancements and cleanup for GRUB2 with OUTPUT=USB

Labels: enhancement, cleanup, won't fix / can't fix / obsolete

jsmeix opened issue at 2021-08-06 07:01:

This is only a reminder issue for myself @jsmeix
what I still need to do for GRUB2 with OUTPUT=USB
(the ordering below is random and does not mean anything):

(a)
Consistent calling of the create_grub2_cfg function in all scripts as

create_grub2_cfg "/path/to/kernel" "/path/to/initrd" "GRUB2 command to set 'root'" >/path/to/grub.cfg

and removal of the matching backward compatibility code in create_grub2_cfg

(b)
Make GRUB2 as bootloader work with multiple ReaR recovery systems
and backups on a USB disk (which is the default behaviour for OUTPUT=USB)
i.e. each ReaR recovery system and backup needs its own GRUB2 menue entry
so that the user can choose which one he wants to boot (i.e. what he wants to restore).
Currently GRUB2 with OUTPUT=USB can only boot the latest one.

github-actions commented at 2021-10-06 02:11:

Stale issue message

jsmeix commented at 2021-10-15 10:36:

This needs to be done before ReaR 2.7 can be released.

github-actions commented at 2021-12-15 02:14:

Stale issue message

github-actions commented at 2022-02-21 02:09:

Stale issue message

github-actions commented at 2022-04-23 02:49:

Stale issue message

jsmeix commented at 2022-06-01 09:31:

I postpone this to ReaR 2.8

github-actions commented at 2022-08-01 03:52:

Stale issue message

github-actions commented at 2022-10-09 03:52:

Stale issue message

github-actions commented at 2022-12-10 02:29:

Stale issue message

github-actions commented at 2023-02-11 02:30:

Stale issue message

jsmeix commented at 2023-02-28 07:28:

Regarding item (b) above see
https://github.com/rear/rear/discussions/2948#discussioncomment-5139092
excerpt:

Currently there is no guarantee at all that
I will find time to implement that item (b).

I prefer to keep things simple and straightforward
so one USB disk to recover only one particular system
with only one backup (lastest most up-to-date one)
is simpler and that results more fail-safe code
(better simple and straightforward code
than sophisticated and fragile constructs)
which in the end results more fail-safe recovery.

Even recovery for one single system with more than
one single backup (more than the lastest up-to-date one)
for that one system calls for trouble unless the user
took extra care to ensure all is fully consistent,
cf. https://github.com/rear/rear/issues/2787

This issue is not about several backups
but it shows that the ReaR recovery system
and the backup need to be fully consistent
i.e. even only one ReaR recovery system
with only one backup is already a problem
so more than one ReaR recovery system
plus more than one backup ensure trouble.

github-actions commented at 2023-04-30 02:20:

Stale issue message

github-actions commented at 2023-07-02 02:52:

Stale issue message

github-actions commented at 2023-09-02 01:59:

Stale issue message

github-actions commented at 2023-11-04 02:03:

Stale issue message

github-actions commented at 2024-01-06 02:07:

Stale issue message

github-actions commented at 2024-03-09 01:58:

Stale issue message

github-actions commented at 2024-05-11 02:05:

Stale issue message

github-actions commented at 2024-07-13 02:19:

Stale issue message

jsmeix commented at 2024-07-18 11:38:

I close it because in practice I won't find time for it.

Of course we at ReaR upstream will continue
to fix and improve things step by step
when users report issues to us.


[Export of Github issue for rear/rear.]