This seems to be a not so uncommon issue, had the same thing:
https://forums.opensuse.org/english/get-technical-help-here/install-boot-login/483667-no-boot-kernelpanic-after-update-suse-12-2-lvm-root-partition.html
I just did the kernel update for 3.4.33-2.24- and had no problems.
Before rebooting I checked the grub menu.lst file and /boot directory.
It seems to check the old configs in menu.lst now, and also check /etc/sysconfig/boot as a backup.
My old kernel command line was correctly copied to the new menu.lst item.
I did not check grub2. That was really broken last time. One symlinks in /boot pointed to nowhere.
Even the grub2 developers say that grub2 is beta.
Oh, sorry I must have missed your post. Well I could have made the /boot partition image available to you. I don’t think /boot should contain any password or other personal data. In fact I still could, because I have not touched or overwritten the backup since then, so it should still be there. (Of course it could be difficult to remember any details after so many weeks.)
But I really wonder what could you learn from the boot file system image. As mentioned
grub2-probe -t fs
has always correctly reported ext2, also for the backup of the unbootable system state.
Now I can answer my question myself. It did not cause any trouble later.
When the kernel update from 3.4.33-2.24.1 to 3.4.42-2.28.1 came recently the grub.cfg still contained all the insmod minix_be, but not a single ext2 (file was simply untouched since March). After applying the kernel update the machine booted fine
and all minix_be had been replaced by ext2. I guess these were the last traces of the incident.