Bug 1195850

Summary: installation hooks are not working
Product: [openSUSE] openSUSE Tumbleweed Reporter: Giacomo Comes <comes>
Component: InstallationAssignee: YaST Team <yast-internal>
Status: CONFIRMED --- QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None CC: ancor, jreidinger, locilka
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://trello.com/c/xLiwIN3f
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Giacomo Comes 2022-02-11 18:41:28 UTC
I'm trying to use hooks as described here:
  https://github.com/yast/yast-yast2/blob/master/library/general/doc/Hooks.md
What I did is to create the file "before_copy_logs_finish_00_test_hook.sh"
and put it in var/lib/YaST2/hooks/installation in the 'root' image that is used at installation time (to be clear like the one that is available in:
  download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/root
At the the end of the installation process, the script before_copy_logs_finish_00_test_hook.sh is supposed to be executed, but that doesn't happen. The log /var/log/YaST2/y2log-1.gz explains why:

[Ruby] modules/Hooks.rb(find_hook_files):193 Found 1 hook files: before_copy_logs_finish_00_comes_hook.sh
[Ruby] modules/Hooks.rb(execute):165 Executing hook 'before_copy_logs_finish'
[Ruby] modules/Hooks.rb(execute):210 Executing hook file '/var/lib/YaST2/hooks/installation/before_copy_logs_finish_00_comes_hook.sh'
[bash] ShellCommand.cc(shellcommand):78 sh: /var/lib/YaST2/hooks/installation/before_copy_logs_finish_00_comes_hook.sh: No such file or directory
[Ruby] modules/Hooks.rb(execute):212 Hook file 'before_copy_logs_finish_00_comes_hook.sh' failed with stderr: sh: /var/lib/YaST/hooks/installation/before_copy_logs_finish_00_comes_hook.sh: No such file or directory

The installer finds the script, but when it is executed it is not there. I suspected a chroot issue and to confirm my suspicion I did the following:
After the installation process started, I moved to tty2 where a shell is available. The command 'ls /var/lib/YaST2/hooks/installation' shows that the hook script is there. then I did: 
  mkdir -p /mnt/var/lib/YaST2/hooks/installation
  cp /var/lib/YaST2/hooks/installation/* /mnt/var/lib/YaST2/hooks/installation
and let the installation process complete.
This time the hook script got executed.
The solution to the problem seemd to be:
1) do not execute the hook scripts in the chroot environment
or
2) make the hook scripts visible in the chroot environment

I guess the correct solution is number 2.

For the record, the issue exists both in Leap 15.3 and tumbleweed.
Using hooks was a possible solution to fix boo#1195118 bur I guess that's not an option right now.
Comment 1 Ancor Gonzalez Sosa 2022-02-14 14:57:35 UTC
(In reply to Giacomo Comes from comment #0)
> The solution to the problem seemd to be:
> 1) do not execute the hook scripts in the chroot environment
> or
> 2) make the hook scripts visible in the chroot environment
> 
> I guess the correct solution is number 2.

I would say the intended behavior is (1). That is, hooks should always run in the int-sys. It's kind of inconsistent and weird that they run in the inst-sys or in the chroot depending on the phase of installation in which they run.

So my opinion this line contains a bug and the path should not include "target"
https://github.com/yast/yast-yast2/blob/6b08011b27346a4364da8d05ed1c2697a2868b90/library/general/src/modules/Hooks.rb#L213

Josef (and main father of the creature according to git history), do you agree?
Comment 2 Josef Reidinger 2022-02-14 23:23:50 UTC
well, I think main creator should be christopher and most importantly hooks requester was Lukas if I remember correctly. I think in general it should really be 1. and run only from insts-sys where customer/user can add own hooks. But lets also ask Lukas as requestor of feature ( if I remember correctly )
Comment 3 Lukas Ocilka 2022-02-15 07:54:24 UTC
The main creator was actually Vladimir in 2013 https://github.com/yast/yast-yast2/pull/148

Honestly, we should rather think about the usage and usefulness rather than going back in time.

- First of all, as Giacomo says, he has tried this to solve bug #1195118, but 
  that did not work anyway, so code change would be needed anyway
- Second, a hook-script does not know by itself whether YaST runs chrooted or 
  outside chroot and cannot simply check it, plus it's not documented
- We've already discussed that YaST should check both paths inst-sys and chroot
- Ideally, script should run from within the environment where it's places unless 
  explicitly defined otherwise (in human speech: if you find me at the balcony, I 
  start at the balcony instead of starting at the Moon which I'm just watching 
  with my telescope)

All in all

- Script found in inst-sys should be called in inst-sys (to be fixed)
- Script found in chroot should be called in chroot (to be implemented)
Comment 4 Giacomo Comes 2023-03-07 12:12:35 UTC
One year has passed and nothing seems to have happened about this bug.
I decided to have a deeper look at the problem and found more information that you may interested in.
1) The manual installation checkpoints list needs an update. It shows 50 points in the documentation, but in the actual list 7 points seems to be gone replaced by other 20. The order is different as well.
2) The hooks start to run in the inst-sys up to: before_switch_scr_finish.
Then after_switch_scr_finish and later hooks run in chroot.
Therefore the hooks executed up to before_switch_scr_finish runs fine out of the box. A small trick allows to run later hooks as well.
I create the file: before_switch_scr_finish_00_fix_chroot.sh
which contains the line:
  cp /var/lib/YaST2/hooks/installation/* /mnt/var/lib/YaST2/hooks/installation
in this way the hooks present in inst-sys are present as well in chroot and can be executed. The last hook to be executed in chroot should contain the line:
  rm -f /var/lib/YaST2/hooks/installation/*
May be this trick can be put in the documentation until the issue is fixed properly.