search

trynd / wren

Linux boot platform that provides a portable, multi-system, run-in-memory Linux environment.
GNU General Public License v3.0
0 stars 1 forks source link

issue1: copy/update-grub.sh: Recognize solo saved initrd.img if it matches kerne... #3

Closed codewithmichael closed 9 years ago

codewithmichael commented 9 years ago

This fixes issue #1.

I replaced the recursive generate calls for the kernel and initrd lookups with separate internal checks to the preferred and fallback directories for each image. This ensures that the directories used for the kernel image and initrd image are searched individually. The kernel version is still determined first and used in finding a matching initrd.img file.

The one exception to the aforementioned split directory search is if the preferred directory contains two unversioned images (as regularly happens in the boot/images directory via symlinks). In that case — when there's an unversioned kernel and initrd image in the same directory — no further search is performed and the unversioned file paths are used.

A single recursive generate call still exists in case the preferred directory isn't defined or doesn't exist.

codewithmichael commented 9 years ago

I'd like to see if I can refactor the new functionality into two new functions since they're basically just doing the same thing twice on different directories. It might be a little ugly extracting the kernel version number string within the generate function once everything else is abstracted away, so I may add a third function for that as well.

codewithmichael commented 9 years ago

As I was starting the refactor I noticed that, without the recursive generate call, the new code finds unversioned image pairs in the preferred directory but bot the fallback directory. I'll fix that first.

codewithmichael commented 9 years ago

After fixing the fallback directory unversioned image pair issue, the code between preferred and fallback directory checks is significantly different enough that refactoring into external methods would actually make the code longer and more complex, so I don't think further refactoring is required at this time.

I think this is ready to go.