Hey Craig,
Another thought. Is there a way to command a system upgrade from Ubuntu
18.04 to 19.10 , or download the DVD and install instead of repair?
I had been thinking of moving up a release anyway. Just that S**t
happened before I could. Would it pick up the Raid under BTRFS?
Many thanks
Andrew
On 11/1/20 2:12 pm, Craig Sanders via luv-main wrote:
On Fri, Jan 10, 2020 at 05:01:57PM +1100, pushin.linux wrote:
Hi all,I am in a great dilemma, when rebooting after agreeing to a
software update, did not check the packges involved, but running Ubuntu
18.04, I was confronted with this:
GRUB version 2.02
Minimal BASH-like line editing is supported.
For the first word, TAB lists possible command completions. Anywhere else
TAB lists possible device or file completions.
grub> _ ( flashing cursor)
Don't know what to do here.
There's an old (2014) but still pretty good tutorial here:
https://www.linux.com/tutorials/how-rescue-non-booting-grub-2-linux/
see also:
https://help.ubuntu.com/community/Grub2/Troubleshooting
Alternatively, you could boot with a rescue CD or USB stick, and examine the
drives and partitions with fdisk or gdisk or similar in order to identify the
root filesystem (and the /boot filesystem if it's separate from the root fs).
Then mount the root fs as, say, "/mnt", /boot as "/mnt/boot" (if separate),
and optionally other filesystems (you probably won't need other partitions
mounted for the rescue operation).
Then bind-mount the pseudo-filesystems /dev, /proc, and /sys under /mnt.
These are needed for update-grub to work. Here's a quick way to do that:
for i in proc dev sys ; do mount -o bind "/$i" "/mnt/$i" ; done
Run "chroot /mnt" to get a shell where /mnt is treated as the root fs.
Then you can edit your /etc/default/grub (if needed - e.g. make sure that the
line "GRUB_DISABLE_LINUX_UUID=true" is commented out), and run "update-grub".
Finally, exit the chroot, unmount the partitions you mounted (in roughly
reverse order to the order you mounted them - e.g. "umount /mnt/dev" before
trying to "umount /mnt"), and reboot. something like this should work:
for i in proc dev sys boot / ; do umount "/mnt/$i" ; done
Due to paranoia and ancient & long-obsolete habit, I like to run "sync" to
manually flush all buffers to disk before rebooting. e.g. "sync ; shutdown -r
now". It's harmless and useless when doing a clean reboot with "shutdown",
but may prevent or reduce fs corruption if you have to do a forced reboot
(e.g. with "reboot -f") or power-cycle.
I am running an ssd as sda, sdb and sdc are in a btrfs RAID array. Puzzled
by this behaviour.
I don't know if this is related to your boot problem or not, but this is the
wrong way to think about drives in linux.
Drives MAY (and often do) retain the same device names (/dev/sda, /dev/sdb,
/dev/sdc etc) when you reboot a machine, but you can NOT rely on that being
the case.
These device names are NOT guaranteed to survive across reboots. In fact, it
is has been documented for many years that these device names are not constant
or reliable.
Storage devices may get different device names for a variety of reasons,
including (but not limited to): drives (including USB drives) being added or
removed, new kernel version, module load order, minor timing differences for
drives spinning up or being detected by the kernel, and more.
This is why you should always configure grub and /etc/fstab to use UUIDs or
LABELs rather than hard-coding /dev/sdXn device names.
craig
--
craig sanders
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
