Updating grub in a hybrid usb hard drive
- Inicie sesión ou rexístrese para enviar comentarios
While attempting to synchronize grub's between a number of external hard drives and my laptop's internal hard drive, I found that one of those external usb-connected hard drives would not accept changes in the version of grub stored in it.
That external usb-connected hard drive is a hybrid, with a combination of solid state and conventional disk memory. The laptop is much faster to boot up with this external hybrid hard drive than with its own internal conventional hard drive, but when I update grub on the hybrid hard drive, it goes through all the motions of detecting the several older versions of the operating system as well as the operating system on the laptop's internal hard drive, but the update has no effect.
This morning it dawned on me that /etc/grub.d is being cached on the solid state portion of the hybrid hard drive ... which is why it boots up so fast ... but my updates to /etc/grub.d (specifically to the 01_PASSWORD file) aren't getting passed along to the cached copy of /etc/grub.d ...
For me this is just a nuisance issue, as the cached version of the 01_PASSWORD file has all the operative lines commented out (#). But for someone whose grub password is trapped in that ssd cache, this could be a more pressing situation.
How does one go about getting the "attention" of that cached ssd memory ?
Not_success:
I tried forcing the update-grub2 command thusly:
1. For the internal HDD sda5: sudo /usr/sbin/update-grub2
2. For the external USB-connected hybrid sdb1: sudo /media/george/36eb87aa-0eda-403f-9f72-07b0eb0c8b36/usr/sbin/update-grub2
Both commands ran smoothly with no complaints from the OS.
Alas, this had no net effect; my updated /etc/grub.d/01_PASSWORD and /media/george/36eb87aa-0eda-403f-9f72-07b0eb0c8b36/etc/grub.d/01_PASSWORD files are still ignored during bootup.
A_little_progress:
When booting up Trisquel 7 in the USB-connected hybrid sdb1, the following message appears: "Loading initial ramdisk" but that message does not appear when I boot up Trisquel 7 in the internal HDD sda5.
Some additional searching reveals that ramdisk is here: /dev/shm
Lots of times, renaming a file causes the OS to generate a new and presumably healthy replacement, but when I try sudo mount -t xfs /dev/shm /media/shm I get the complaint that /dev/shm "is not a block device" and, further, I hesitate to change any of the half-dozen [binary ?] files stored in shm.
My best guess is that "initial ramdisk" is getting its data from the flash memory inside my 1TB USB-connnected hybrid SSD/HDD drive, but I haven't a clue how to change the version of grub that is hiding in that hybrid drive's flash memory.
- Inicie sesión ou rexístrese para enviar comentarios