[arch-releng] [PATCH] Define grubmenu as a global variable instead of multiple local variables
--- src/core/libs/lib-ui-interactive.sh | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/core/libs/lib-ui-interactive.sh b/src/core/libs/lib-ui-interactive.sh index 2297078..11cde02 100644 --- a/src/core/libs/lib-ui-interactive.sh +++ b/src/core/libs/lib-ui-interactive.sh @@ -1,6 +1,9 @@ #!/bin/bash # A library which allows you to do backend stuff by using user interfaces +# Global Variables +grubmenu="$var_TARGET_DIR/boot/grub/menu.lst" + # check if a worker has completed successfully. if not -> tell user he must do it + return 1 # if ok -> don't warn anything and return 0 check_depend () @@ -855,7 +858,6 @@ interactive_install_bootloader () { interactive_grub() { get_grub_map - local grubmenu="$var_TARGET_DIR/boot/grub/menu.lst" [ ! -f $grubmenu ] && show_warning "No grub?" "Error: Couldn't find $grubmenu. Is GRUB installed?" && return 1 debug FS "starting interactive_grub" @@ -995,7 +997,6 @@ interactive_grub() { } generate_grub_menulst() { - local grubmenu="$var_TARGET_DIR/boot/grub/menu.lst" get_device_with_mount '/' || return 1 local _rootpart=$ANSWER_DEVICE @@ -1128,7 +1129,6 @@ EOF } interactive_grub_menulst () { - local grubmenu="$var_TARGET_DIR/boot/grub/menu.lst" generate_grub_menulst helptext= grep -q '^/dev/mapper' $TMP_FSTAB && helptext=" /dev/mapper/ users: Pay attention to the kernel line!" -- 1.7.3.4
merged from your github. thanks, Dieter
On 01/03/2011 01:30 PM, Dieter Plaetinck wrote:
merged from your github. thanks, Dieter This needs to be reverted or the sourcing order needs to be changed....
What happens is that when lib-ui-interactive.sh is sourced $var_TARGET_DIR is not yet set, resulting in grubmenu="$var_TARGET_DIR/boot/grub/menu.lst" equaling /boot/grub/menu.lst instead of /mnt/boot/grub/menu.lst I attempted to figure out the sourcing order, however I failed. var_TARGET_DIR is set in core/procedures/base. Maybe this can be sourced before lib-ui-interactive? In my brief (non-rebooted) install test /boot/grub/menu.lst (on the live cd) was being edited instead of the one on the target system Since I didn't reboot I didn't realize this until I was working on my Syslinux code. pyther
On 01/03/2011 01:30 PM, Dieter Plaetinck wrote:
merged from your github. thanks, Dieter This needs to be reverted or the sourcing order needs to be changed....
What happens is that when lib-ui-interactive.sh is sourced $var_TARGET_DIR is not yet set, resulting in grubmenu="$var_TARGET_DIR/boot/grub/menu.lst" equaling /boot/grub/menu.lst instead of /mnt/boot/grub/menu.lst
I attempted to figure out the sourcing order, however I failed. var_TARGET_DIR is set in core/procedures/base. Maybe this can be sourced before lib-ui-interactive?
In my brief (non-rebooted) install test /boot/grub/menu.lst (on the live cd) was being edited instead of the one on the target system Since I didn't reboot I didn't realize this until I was working on my Syslinux code.
pyther @dieter if you don't have the time to investigate this can you revert
On 01/03/2011 10:30 PM, Matthew Gyurgyik wrote: this change?
On Tue, 04 Jan 2011 18:28:35 -0500 Matthew Gyurgyik <pyther@pyther.net> wrote:
On 01/03/2011 01:30 PM, Dieter Plaetinck wrote:
merged from your github. thanks, Dieter This needs to be reverted or the sourcing order needs to be changed....
What happens is that when lib-ui-interactive.sh is sourced $var_TARGET_DIR is not yet set, resulting in grubmenu="$var_TARGET_DIR/boot/grub/menu.lst" equaling /boot/grub/menu.lst instead of /mnt/boot/grub/menu.lst
I attempted to figure out the sourcing order, however I failed. var_TARGET_DIR is set in core/procedures/base. Maybe this can be sourced before lib-ui-interactive?
In my brief (non-rebooted) install test /boot/grub/menu.lst (on the live cd) was being edited instead of the one on the target system Since I didn't reboot I didn't realize this until I was working on my Syslinux code.
pyther @dieter if you don't have the time to investigate this can you revert
On 01/03/2011 10:30 PM, Matthew Gyurgyik wrote: this change?
sorry my pc has been broken all week. i understand the issue. the key is src/aif.sh, the `load_module core` call (which loads all core (i.e. default) libraries), which is followed by the `load_procedure "$module" "$procedure"` call, which usually means `load_procedure core interactive` note that the interactive procedure has a statement `depend_procedure core base` which causes base to be sourced very early when interactive is sourced, however this is after loading the libraries. We might be able to load procedures first, libraries after, but that might cause similar sourcing order problems. I need to think about this a bit more and get an idea of the dependencies between procedures and libraries. do you have any suggestions? Dieter
here we go. https://github.com/Dieterbe/aif/commit/d363fd6c0f45290a30629e571436ec280e529... that should fix the bug *and* make the library more flexible. Dieter
participants (3)
-
Dieter Plaetinck
-
Matthew Gyurgyik
-
pyther＠pyther.net