On Sun, Jan 12, 2020 at 04:20:42PM +1100, pushin.linux wrote:
>
> Original message From: Craig Sanders via luv-main
> 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
> ___luv-main
> mailing
> listluv-m...@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
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
