Three hard drives; cannot get GRUB to function.
- Inicie sesión o regístrese para enviar comentarios
Some time ago, Magic Banana described how to escape from the Grub rescue prompt:
You can chroot in the root partition of the installed system (from a live system, such as the one you used to install Trisquel)...
which I attempted with the following series of commands:
trisquel@trisquel:~$ sudo mkdir /media/george
trisquel@trisquel:~$ sudo mkdir /media/george/EssDeeAyeOne
trisquel@trisquel:~$ sudo mount /dev/sda1 /media/george/EssDeeAyeOne
trisquel@trisquel:~$ sudo chroot /media/george/EssDeeAyeOne/
That gave access to root in the first of three available operating systems.
https://help.ubuntu.com/community/Grub2/Installing#Fixing_a_Broken_System explains it in
far too many details. That page gives other more maybe user-friendly methods.
My next few steps were less successful:
root@trisquel:/# sudo update-grub
sudo: unable to resolve host trisquel: No such file or directory
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
root@trisquel:/# ls
bin boot cdrom dev etc home initrd.gz initrd.img initrd.img.old lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var vmlinuz vmlinuz.old
These complaints suggest that I should have taken a more direct path to the root of /dev/sda1.
The fstab file at /media/george/EssDeeAyeOne/etc/fstab is exactly what I set up just before the previous boot attempt:
# / was on /dev/sda1 during installation
UUID=...-4b95-b283-cce98be10820 / ext4 errors=remount-ro 0 1
# swap was on /as on /dev/sda7 during installation
UUID= ...-a159-b25ff8ce9b0d none swap 0 0
# swap was on /dev/sdb2 during installation
UUID=...-413a-aa3f-1e2afda0bdf6 none swap 0 0
# swap was on /dev/sdc2 during installation
UUID=...-433a-8b90-b124bfcfb0c9 none swap 0 0
# GBData was on /dev/sda5 during installation
UUID=...-42e9-9acb-dfc864916e47 /home/george/GBData xfs defaults 0 2
# Data-II was on /dev/sdb3 during installation
# UUID=...-407a-8d4e-98df997fcbe3 /media/george/Data-II ext4 defaults 0 2
# Data-III was on /dev/sdb1 during installation
# UUID=...-7c3b-4450-9f24-266f8b3e855d /media/george/Data-III ext4 defaults 0 2
# Data-I was on /dev/sdc3 during installation
UUID=...-4fa6-b17a-7dbee1d4c16f /home/george/Data-I ext4 defaults 0 2
This /etc/fstab is essentially the same (but for different partitions and UUID's) as in another T420 running the same
rumber of hard drives, also with three operating systems. What is different today is that the lone external HDD now
has no operating system, as I could not force the three different T420's (all Lenovo's, running Etiona) to assign that
drive to the same place in /dev/s... I moved the /icedove file into the vacated 30GB partition, where it's readily
available to whatever current operating system wants to use it. Its UUID's are commented out in fstab here for another
issue.
Try that from a terminal in the live system:
$ sudo mount /dev/sda1 /mnt
$ for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
$ sudo chroot /mnt
# grub-install /dev/sda
# update-grub
Reference: https://help.ubuntu.com/community/Grub2/Installing#via_ChRoot
Magic Banana's recipe worked perfectly on the first Lenovo T420; no adjustments needed.
On the second T420, the partition numbers had all been scrambled, so it took a while to
get all the UUID's and /dev/.... data in their correct positions, after which the recipe
worked OK again with the appropriate drive letters and a nice-looking GRUB menu appeared.
But none of the instances of Etiona would boot up. Given the opportunity to run:
journalctl -xb
A drive UUID=b8a1ee74-... was accused of failing. However, blkid does not find a partition
labeled Data-II with that UUID. Further investigation brought out another UUID for the Data-II
partition, so I tried changing the UUID to the earlier one in fstab ... here's how they look:
/dev/sdb3: UUID="e7da792a-af1e-4c3b-9384-e105a7249dab" TYPE="ext4" PARTLABEL="Data-II" PARTUUID="a2764b44-22cc-4b1f-b1f6-f692aa0bd287"
/dev/sdc3: UUID="b8a1ee74-96d2-407a-8d4e-98df997fcbe3" TYPE="ext4" PARTLABEL="Data-II" PARTUUID="a2764b44-22cc-4b1f-b1f6-f692aa0bd287"
First I tried changing the UUID of /dev/sdc3 from the upper one to the lower and then running
Magic Banana's recipe ... just a mess. Then I simply rebooted; even though the GRUB menu came
up OK, nothing would boot up. Even without the offending hard drive mounted in the /media/george/...
folder still nothing would boot up.
Bear in mind that the same Data-II partition in the external 1.0 TB HDD works fine in the other
two Lenovo T420 laptops. When I run sudo fsck.ext4 -v /dev/sdc3 on these two T420's, it comes up clean.
And the T420 that's not yet booting up is not the one with the doubtful motherboard that cannot handle
two RAM sticks.
In /etc/fstab's first field, you can specify the device name, e.g., /dev/sdc3 (instead of UUID=b8a1ee74-96d2-407a-8d4e-98df997fcbe3). What do you mean when you write that your drive "was accused of failing". Is SMART reporting such failures? Have you the user data on that drive backed up somewhere else? You should.
Magic Banana suggests: In /etc/fstab's first field, you can specify the device name, e.g., /dev/sdc3 (instead of UUID=b8a1ee74-96d2-407a-8d4e-98df997fcbe3).
Alas, the drive letters aren't stable on successive boot-ups; that's what forced me to face the tedium of
using blkid first, and then editing fstab accordingly. Please note that there are three versions of the
UUID for the larger of the two partitions of the external 1.0TB hard drive in the #2 posting above.
I could make a new UUID according to https://www.tecmint.com/change-uuid-of-partition-in-linux/
I tried that some time ago (too soon) and can now apply it to all three instances (i.e., the three T420's) in
which that drive is the external 1.0TB HDD. That HDD can be attached via USB to at least two of the three
T420's as it now stands.
Regarding the drive that "was accused of failing:" In the usual outcome of a failed bootup, it is rather
easy to bring up the text file listing all that the system as doing up to the point of failure and beyond:
journalctl -bx That's where this drive's UUID is posted.
Trouble is, that's another one of the three UUID's listed in my posting #2, not the one listed in fstab.
Worse yet, even when I change the UUIDin fstab to coincide with the one posted in the post mortem, the text
file still gives the same "failed" UUID as in the earlier failed bootup. Yet, that external HDD works fine
and comes up clean with fsck.ext4 -v /dev/sdc3 in the other two T420's.
Every so often I do back this drive up to an identical one in one of the functional T420's. The /icedove
portion can be retrieved from my ISP's cPanel site; I usually pop down the new mail whenever I run one of
the other T420's. Similarly, most of the 650 GB on the larger partition of the external HDD can be backed up
by copying the new material; the old stuff doesn't change.
After a good night's sleep, I made all the fstab files inaccessible to GRUB by renaming them to fstab.bak.
After running Magic Banana's recipe (changing sda1 to sda3 to reflect the boot drive's first Etiona partition),
the restart left me with a login to the text version of Etiona, but I could run journalctl -xb
again, whereupon I found a "trace" (image attached - couldn't find any complete OCR package in Add/Remove
Applications). The good news is that there's no mention of any failed UUID's now that the fstab's and the
external 1.0TB HDD aren't involved. Is there anything else in the journalctl readout that I should be looking
for ? This "trace" has been in that file in earlier failed bootups.
After another good night's sleep, motivation developed to investigate further: A search on the opening line
of the attached call trace Could not determine valid watermarks for inherited state reveals an Ubuntu bug:
https:name at domain/msg5902814.html
However, running the commandjournalctl -xb on another of the three T420's brings up what appears to be
the same call trace (second attached text file) which didn't affect bootup.
Additional staring at the results of the journalctl command from the third T420 uncovered a frequently repeated
entry: EE / Fatal server error: /Could not create lock file in /temp/.tX0-lock / EE
A search on that verbiage brought up an Ubuntu response (Screenshot attached) suggesting use of the command
sudo mount -o remount,rw /
which causes one of the Etiona installations on the third T420 to open the graphical interface, albeit with no
connectivity to the Internet in spite of the presence of an apparently valid WiFi connection. Ping's are greeted
with the response that there is a temporary failure in name resolution.
Another instance of Etiona brings up the alternative greeter (/etc/lightdm/lightdm-gtk-greeter.conf) repeatedly
without opening the graphical interface after the same remount command.
| Adjunto | Tamaño |
|---|---|
| Trace-09262021.pdf | 662.97 KB |
| Trace-09272021.txt | 5.14 KB |
When you have multiple hard disks, especially when some of them are removable, using labels (-L) instead of UUID (-U) is inadvisable. The labels (i.e., the variable X in device file /dev/sdX) can change if you connect the disks in a different order.
Now I suspect that there is something weird in the partition table of some of your disks. When I receive a "pre-formatted" hard disk (e.g., any disk that come from new computers or portable disks), I'd wipe out the partition table (by zero-filling the beginning of the disk, maybe 8 or 16 MiB) and create a new one.
nadebula.1984 commented: using labels (-L) instead of UUID (-U) is inadvisable. The X's in /dev/sdXX
are unpredictable in an uncontrolled way, even with the single external HDD. A second HDD is installed in the
CD/DVD slot on a SATA HDD adapter which plugs into the internal USB bus just like the other HDD's. It appears
that the order in which they are detected by that internal USB bus is unpredictable. I've had to use the labels
that I can set with GParted to check which HDD is which in that random hierarchy. Leaving the external HDD out
of that mess by removing its operating system has gotten that issue under control. I also cut access to the
fstab on the boot drive by renaming it, and Magic Banana's recipe reconstructed it OK so I now have a working
GRUB menu. All the partitions containing the operating systems come up clean with fsck.ext4 -v /dev/sdXX
Hello, this video maybe be usefull for you.
Hola, este video quiza pueda serte de ayuda a ti.
See the commands and use it
https://www.youtube.com/watch?v=Gd7MABJdUVc&t=1096s
Put the commands from:
mount -o bind /dev /mnt/dev
....
Before chroot'ing, mount your partitions under /mnt. /media is usually not used for such purposes.
When you have chroot'ed, the # prompt indicates that you already have root privilege, therefore sudo should not be used.
Actually, you can do everything you wish in chroot jail.
Solved by reinstalling Etiona to two out of three operating systems, whereupon the
third operating system (Flidas) started booting up normally. Took about three hours,
what with all the App's to install as well. Thanks to all who helped.
Congratulations. Though I believe that things could have been done using chroot and then update-grub and/or update-initramfs
I recently fixed several system installations without reinstalling anything.
Actually, I was premature with Flidas; still broken. Now waiting to install TQ_10 in its place.
- Inicie sesión o regístrese para enviar comentarios