Hi all,I think I now have all needed parts together for making d-i/grub-installer work for NewWorld Power Macs.
I've separated the patches unrelated to this from the main patch.The first patch is just for cosmetic changes, the second one makes an EFI related code in `grub-installer` only execute when `grub-efi*` packages are going to be installed.
The third one contains all new functionality for d-i/grub-installer. @Rick:I've also attached compressed versions of `grub-installer` and `debian/postinst` - the latter already renamed so it can be used as is in a Debian installation with Adrian's image from 2017-10-23 22:40h () after decompression.
I haven't yet tested the modifications with a "non-expert" installation.: https://people.debian.org/~glaubitz/debian-cd/debian-9.0-ppc64-NETINST-1.iso
## How should it behave? ##When testing, please ignore the longer time period between selecting and executing the "Grub installation" step and until the first window appears - these are more than a dozen seconds IIRC, if in doubt check the log on console #4. This is due to package installations (from `debian/postinst` and `grub-installer`) and the detection and selection of the NewWorld boot partition that happen at the beginning of this step.
During my tests with "expert" installations the dialogue "Device for boot loader installation" that ask to confirm or select the device file(s) (if multiple are available, not tested yet though) for the NewWorld boot partition always appeared, although the device information came from d-i/partman-newworld, so should be implicitly correct. It could be the case that during a "non-expert" installation a user is not asked for confirmation, but I don't know yet.
For most parts, if a function call does not exit with 0, I configured `grub-installer` to exit with 1 as exit code (`[...] || exit 1`). This could be superfluous as the script runs with `set -e` but I wanted to make sure `grub-installer` stops if something goes wrong. The log file should give some info about what part failed to work as expected. Should we also add or use a specific debconf template with some info when things fail?
## Changes to last version ##* One new debconf template (originally from d-i/yaboot-installer) got removed, as it wasn't used by any code.
* The detection and selection of NewWorld boot partitions now works without any hard-coded values (see nw_select_offs_part() and lines 603 and following in the third patch)
* I have removed the detection of a HFS file system on the NewWorld boot partition. Originally I wanted to keep any preinstalled yaboot on this partition and hence only formatted it if no HFS file system was detected there. But I stumbled upon a case where the partition was already formatted with HFS and included all GRUB files from a previous installation, so was not formatted but just used as is. Although no files were visible on the partition, the files from the prior installation were still there and took space, so `grub-install` failed as not enough space was left in the file system. So I decided to remove this and always format the NewWorld boot partition just like d-i/yaboot-installer does.
* The CHRP boot script is made bootable from OF (file type tbxi is set for it and the containing directory is "blessed", see nw_make_boot_script_of_bootable() for details). Actually I think this should have been done during the call to `grub-install` (source on ), but I haven't seen this working.
* My modifications originally also copied the CHRP boot script (named `BootX` when installed into the HFS on the NewWorld boot partition) to the root directory of the HFS, to be able to easily access it from OF. After figuring out how to access it in its usual place (`System:Library:CoreServices`) from OF, this is no longer needed.
* The NVRAM can be configured (see nw_configure_nvram()). Currently I use the NVRAM defaults, which work with the way the CHRP boot script is installed and made bootable. I currently do not set `auto-boot?` to "true" to be able to access the OF after each start or reboot without the need for multiple keys pressed (which doesn't work for my wireless keyboards attached to my Power Macs).
* I also added functionality to backup the original NVRAM contents before the call to `grub-install` and nw_configure_nvram() changes it (see nw_backup_nvram_contents() for details). I'm not yet sure if it works as intented as the file with the NVRAM contents wasn't created in the target FS, but the contents are at least visible in the installation log file. Could be that the redirection is ignored or not done in-target but for the `in-target` call itself.
* I exchanged the chroot calls in my modifications with calls to `in-target` (described in ), because this automatically takes care of mounting `/proc` and `/sys` in the target FS.
## Things to discuss ##* The CHRP boot script () should better be shipped and installed as template (`grub.chrp.in` in `/usr/lib/grub/powerpc-ieee1275`) with the respective grub-ieee1275 package. Then we just need to adapt it from `grub-installer` during GRUB installation.
* I have prefixed all NewWorld Power Mac related functions with `nw_`. I personally find this useful to differentiate this code from code for other architectures.
* I also added all new functions to the top part of `grub-installer`, but I recognized that other functions are located in the main execution path, too. It seems like it doesn't hurt to put all new code to the top part, though.
* After `grub-install` ran (line 669 in patch #3), I needed to unmount the NewWorld boot partition, as otherwise `hattrib` wasn't able to see the newly installed files there. I mount it again afterwards. Maybe a `sync` will also work, but I haven't tested this yet.
****As the third patch is more than 30 KiB uncompressed I only added it as attachment in compressed form.
What do you think and what else should we discuss? And do you have questions about why I did things this or that way?