Has anyone ever witnessed a problem with BitCurator seemingly spontaneously wiping its own grub install? Perhaps on system reboot?
Context: a while back I imported and (successfully) used one of the pre-built BitCurator 2.0.16 VMs in Emulation-as-a-Service. I've returned to that environment and I now only get the "grub rescue>" prompt, and it seems like the core "normal" grub module is just...gone?
as far as I can tell, the pre-built VMs are just a single-partition, BIOS install (i386-pc directory is present at (root)/boot/grub/, but no modules inside...)
plus, the whole deal with EaaS environments is that any changes made by the user can be discarded, so I'm quite certain I wouldn't have saved the environment this way after making any intentional change/choice/update
@axfelix @The_BFOOL or... iirc I've seen this in the past on my own Linux installs most often when I update the kernel via apt or whatever and the update-grub hook doesn't fire properly after cleaning up the old entry. I suspect it's some form of that.
@axfelix @The_BFOOL if you can mount it, chroot, and run a clean update grub from a working environment, I expect that will work. this is probably too much trouble for a bitcurator VM.
@axfelix the partition's still there, I can see vmlinuz and initrd images, everything seems fine on that side, the issue's grub complaining about i386-pc/normal.mod being missing, which prevents it from doing, basically anything, and indeed I can't find it in any of the places it could/should be
indeed it's pretty Not Worth It compared to making a new environment with their newer install method anyway. I'm mostly baffled because EaaS is set up in a way specifically to avoid this sort of thing
@The_BFOOL are you sure it's the grub module being gone and not the bootable partition being gone?