My grub setup is crossed up between an internal HDD and a USB HDD
- Inicie sesión ou rexístrese para enviar comentarios
After purging an old hard drive, I formatted it and installed Trisquel 7. All went OK until I ran Software Updater. At the conclusion of the update, the system asked me whether I wanted to install the system's version of grub or my own. Not knowing any better and being forced to guess, I chose to use the version of grub that was already in place, i.e., my own. After some more hassles and guesses, I found that the update would proceed only if I chose the internal HDD's version of grub, not the USB HDD, which the updater wouldn't accept.
Now that the system will boot up with either HDD's version of Trisquel, I find that I cannot unify the grub passwords between the two HDD's. Whichever grub I change to force the unified password, the results of sudo update-grub2 are the same:
On the new USB HDD:
>> sudo update-grub2
>> Generating grub configuration file ...
>> /etc/grub.d/01_PASSWORD: 11: /etc/grub.d/01_PASSWORD: 00_header: not found
On the Internal HDD:
>> sudo update-grub2
>> Generating grub configuration file ...
>> /etc/grub.d/01_PASSWORD: 11: /etc/grub.d/01_PASSWORD: 00_header: not found
And grub will only accept the original password from each instance, not the unified password, even when I comment out the password file altogether, which ordinarily would cause grub to work without any password.
A search in the Trisquel forum on "00_header: not found" returns nothing.
The file, "01_header" is still present in both /etc/grub.d folders, of course. It's just that each grub2 update is looking in the wrong place. Where might that place be, and how can I reinstall grub to fix this ?
Progress report:
It only got worse. The boot-repair utilities retrieved from ubuntu didn't fix anything:
>> sudo add-apt-repository ppa:yannubuntu/boot-repair [Enter]
>> sudo apt-get update [Enter]
>> sudo apt-get install -y boot-repair && boot-repair [Enter]
[Running these steps on sdb, the USB-connected 500GB hard drive, produced an output file sent to http://paste2.org/[........] but that link was dead.]
Then I tried downloading Boot-Repair-Disk-64bit from http://www.sourceforge.net/p/boot-repair-cd and that produced a long text file that I saved, and it suggested the following suggested repair:
>> The default repair of the Boot-Repair utility would reinstall the grub2 of sda5 into the MBR of sda.
>> Additional repair would be performed: unhide-bootmenu-10s fix-windows-boot
After several tries with these two boot-repair facilities, the Trisquel 7 OS's on my various USB-connected hard drives will start OK from the grub menu with grub P/W's (not yet unified) but the Windows 7 partition's boot manager has been made useless/damaged.
As I have tried "the default repair" several times, choosing the "usual repair method," that hasn't fixed the Windows bootup routine. Is there another way to obtain "reinstall the grub2 of sda5 into the MBR of sda" ?
The commands, "unhide-bootmenu-10s" and "fix-windows-boot" are not recognized by the console, even with sudo prepended to them. Maybe they're to be run from SourceForge's boot-repair-cd ?
Just get rid of the GRUB passwords by making all lines of /etc/grub.d/01_PASSWORD start with the '#' character (editing the file requires administrative privileges). Even GRUB developers write that this password is no security (unless the system is a kiosk): https://www.gnu.org/software/grub/manual/grub.html#Security
If you wish to reconfigure GRUB (like the update proposed):
$ sudo dpkg-reconfigure grub-pc
As an experiment, I installed Trisquel_7 on a used 40GB HDD, USB-connected, and when it came time to install grub, I selected, "use the developer's version." [I did this before reading Magic Banana's suggestion above.]
Nevertheless, when I tried to modify /etc/grub.d/01_PASSWORD in the usual way, when I immediately ran sudo update-grub2 afterwards, I got the following message:
>> sudo update-grub2
>> Generating grub configuration file ...
>> /etc/grub.d/01_PASSWORD: 12: /etc/grub.d/01_PASSWORD: 00_header: not found
Which will be familiar to those of you who have read my earlier laments.
Then I tried Magic Banana's suggestion:
>>> sudo dpkg-reconfigure grub-pc
>>> [sudo] password for george:
>>> Installing for i386-pc platform.
>>> Installation finished. No error reported.
>>> Generating grub configuration file ...
>>> /etc/grub.d/01_PASSWORD: 12: /etc/grub.d/01_PASSWORD: Desktop: not found
Again, that familiar refrain.
Either way, the grub password that works is the one set during the installation of Trisquel_7, not the one to which I attempted a change ... whether I change that grub password file or not.
I even tried booting into Trisquel_7 on the internal HDD and then changing the password file in the USB-connected, 40GB HDD, followed immediately by running sudo update-grub2 while still in the etc/grub.d folder, but the result was the same refrain:
>>>> sudo update-grub2
>>>> Generating grub configuration file ...
>>>> /etc/grub.d/01_PASSWORD: 11: /etc/grub.d/01_PASSWORD: 00_header: not found
The installation of Trisquel_7 in the USB-connected, 40GB HDD was otherwise uneventful; I eliminated all but english-language support beforehand with Synaptic-Package Manager, so only 4.2GB of the 12GB system partition is used by Trisquel_7 and its updates to today's date.
I may yet follow Magic Banana's early suggestion just to comment out all the operative lines in the 01_PASSWORD file, but right now I fear that the grub password may not yet actually change to null.
Magic Banana suggested:
>> There apparently is something wrong written at line 11 or 12 of /etc/grub.d/01_PASSWORD ...
Here's what I gan gather from the various HDD's when poking around:
>>> 1TB USB-HDD:
sudo cat 01_PASSWORD:
...
10: echo set superusers=grub
11: # echo password grub 31475
12: echo password grub 5807
sudo update-grub2
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.13.0-79-lowlatency
Found initrd image: /boot/initrd.img-3.13.0-79-lowlatency
...
Found linux image: /boot/vmlinuz-3.13.0-68-lowlatency
Found initrd image: /boot/initrd.img-3.13.0-68-lowlatency
No volume groups found
Found Trisquel GNU/Linux 7.0, Belenos (7.0) on /dev/sda5
done
>>> 320GB Int-HDD:
sudo cat 01_PASSWORD:
...
10: echo set superusers=grub
11: * echo password grub 2127
12: echo password grub 5807
sudo update-grub2
Generating grub configuration file ...
/etc/grub.d/01_PASSWORD: 11: /etc/grub.d/01_PASSWORD: 00_header: not found
>>> 500GB USB-HDD:
sudo cat 00_PASSWORD:
...
10: echo set superusers=grub
11: * echo password grub 26753
12: echo password grub 5807
sudo update-grub2
Generating grub configuration file ...
/etc/grub.d/01_PASSWORD: 11: /etc/grub.d/01_PASSWORD: 00_header: not found
>>> 40GB USB-HDD:
sudo cat 00_PASSWORD:
...
10: echo set superusers=grub
11: * echo password grub 9410
12: echo password grub 5807
>>> Immediately after editing 01_PASSWORD I got:
sudo update-grub2
Generating grub configuration file ...
/etc/grub.d/01_PASSWORD: 12: /etc/grub.d/01_PASSWORD: 00_header: not found
>>> Subsequently, without editing 01_PASSWORD I get:
sudo update-grub2
Generating grub configuration file ...
/etc/grub.d/01_PASSWORD: 11: /etc/grub.d/01_PASSWORD: 00_header: not found
>>> Now, re-running Magic Banana's suggestion:
sudo dpkg-reconfigure grub-pc
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
/etc/grub.d/01_PASSWORD: 11: /etc/grub.d/01_PASSWORD: 00_header: not found
Note: there isn't any /boot/grub/menu.lst file, either in the USB-HDD or in the internal HDD (whose /boot folder isn't in the first partition; that's occupied by the original Windows_7 OS). It turns out that I can't find any example of that /boot/grub/menu.lst file in the 500GB-USB-HDD, in the 40GB-USB-HDD or even in the 1TB-USB-HDD (where update-grub2 works OK).
I looked in two of the /etc/grub.d/00_header files (Int-320GB-HDD and 1TB-USB-HDD) ... no mention of PASSWORD found.
My next step will be to do the suggested "comment-out" step on a couple of these HDD's.
Solved ...
See those little asterisks (*) ... not 'sposed to use those. Gotta be pound (#) ... works OK now.
Thanks to Magic Banana for steering me in the right direction.
That is it. A shell interprets those files. For a shell, * means "all the files in the working directory, ordered alphabetically". 00_header is, in that order, the first file in /etc/grub.d/, hence the error message.
> See those little asterisks (*) ... not 'sposed to use those. Gotta be
> pound (#) ... works OK now.
# isn't a pound sign.
Great ! Nice analysis ! Out of context, instead of "delete *.txt" it just didn't jump out at me. Needs a "are you sure ?" warning ... for me, at least.
The end result is that I hosed a hardly used Windows 7 installation that came with the laptop. All I used it for that isn't in Trisquel_7 was [proprietary] speech-to-text software. I'm keeping my hopes up for developments in the GNU/Linux community in that field. If Trisquel_8 comes out first, I know just where that will fit in the internal HDD.
On Wed, 2 Mar 2016 02:19:32 +0100 (CET) name at domain wrote:
> Great ! Nice analysis ! Out of context, instead of "delete *.txt" it
> just didn't jump out at me. Needs a "are you sure ?" warning ... for
> me, at least.
>
> The end result is that I hosed a hardly used Windows 7 installation
> that came with the laptop. All I used it for that isn't in Trisquel_7
> was [proprietary] speech-to-text software.
speech-to-text or text-to-speech? Because if the latter, isn't Orca
good enough?
moxalt asked -
>> speech-to-text or text-to-speech?
Definitely speech-to-text, as in Dragon Naturally Speaking, but that's proprietary and pretty iffy with Wine.
I am going to try Simon, but they don't claim that continuous transcription is its main reason for being.
- Inicie sesión ou rexístrese para enviar comentarios