On Sun, Jan 12, 2020 at 04:20:42PM +1100, pushin.linux wrote:

-------- Original message --------From: Craig Sanders via luv-main <luv-main@luv.asn.au> Date: 11/1/20 2:12 pm (GMT+10:00) To: luv-main@luv.asn.au Subject: Re: Weird boot issue 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/TroubleshootingAlternatively, you could boot with a rescue CD or USB stick, and examine thedrives and partitions with fdisk or gdisk or similar in order to identify theroot 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 partitionsmounted 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" ; doneRun "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 theline "GRUB_DISABLE_LINUX_UUID=true" is commented out), and run "update-grub".Finally, exit the chroot, unmount the partitions you mounted (in roughlyreverse order to the order you mounted them - e.g. "umount /mnt/dev" beforetrying to "umount /mnt"), and reboot.  something like this should work:    for i in proc dev sys boot / ; do umount "/mnt/$i" ; doneDue to paranoia and ancient & long-obsolete habit, I like to run "sync" tomanually flush all buffers to disk before rebooting. e.g. "sync ; shutdown -rnow".  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 thewrong 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 beingthe case.These device names are NOT guaranteed to survive across reboots. In fact, itis has been documented for many years that these device names are not constantor reliable.Storage devices may get different device names for a variety of reasons,including (but not limited to): drives (including USB drives) being added orremoved, new kernel version, module load order, minor timing differences fordrives spinning up or being detected by the kernel, and more.This is why you should always configure grub and /etc/fstab to use UUIDs orLABELs rather than hard-coding /dev/sdXn device names.craig--craig sanders <cas@taz.net.au>_______________________________________________luv-main mailing listluv-main@luv.asn.auhttps://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-mainHi Craig,I am wading through the first option "how to rescue..."I have found rootgrub> ls (hd0,3)/@/  @/homeand ran this ...ls (hd0,3)/@/dev/  run/  boot/  a whole lot of stuff ... inc vmlinuz  and home/ and root/grub> ls @/boot/# whole lot of stuff including vmlinuz-4.15.0-74-genericI cant seem to get the syntax right in line 2  for the location of the kernelLine one worked OK, but should I be using root=/dev/sda3 ?I am writing this with one finger on a tablet.

I can't read that mess. i'm not even going to try deciphering it. Also, this should be sent to the mailing list, not to me personally. so I'm replying back to the list. craig