Re: Weird boot issue
On 13/1/20 1:59 pm, Craig Sanders via luv-main wrote: On Sun, Jan 12, 2020 at 04:20:42PM +1100, pushin.linux wrote: 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 Hi Craig, I would give up on that mess as well. I apologise for replying to you, my tablet did not offer "reply to list". I have no idea how that mess above occurred. You recommended a tutorial on how to get GRUB working again, and I followed it as best I could. My problem is trying to make sense of the GRUB shell. My hard drives all have GUUID references, and not sda3 sdb1 and sdc1 references. Here are the 4 recommended lines: grub> set root=(hd0,1) grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda1 grub> initrd /boot/initrd.img-3.13.0-29-generic grub> boot I have discovered that my / directory is on (hd0,3) and vmlinuz-4.15.0-74-generic is also in there but when I try to run the second line I fail to get the syntax right So this worked: grub> set root=(hd0,3) Next line : grub> linux /boot/vmlinuz-4.15.0-74-generic root=/dev/sda3 did not work Third line : grub> initrd /boot/initrd.img-4.15.0-74-generic - haven't got past line 2 grub> boot when successful I will run grub-update Just a thought, since my brain has recovered from yesterday, does all of this have to be run as root? The document suggested that permissions were not necessary because of the fact that Unix/Linux assumes that if you are in physical control of the machine then you are the owner. Many thanks Andrew ___ 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
Re: Weird boot issue
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
Re: Weird boot issue
On Sat, Jan 11, 2020 at 10:02:24PM +1100, Andrew Greig wrote: > Another thought. Is there a way to command a system upgrade from Ubuntu > 18.04 to 19.10 , or download the DVD and Well, yes. Ubuntu is meant to be upgraded in place. As long as you have a CD, DVD, or internet connection, you can upgrade from one version of ubuntu to the next. i.e. from 18.04 to 18.10, then 19.04 and then 19.10 Canonical put a lot of effort into making sure that upgrading to the next version of Ubuntu works. They put none at all into making sure that skipping a release or two will work - they do not recommend or support that at all. If you're willing and able to deal with and fix a variety of minor issues and possibly some major ones too, it is possible to upgrade directly from 18.04 to 19.10 but that is a) not the recommended procedure (in fact it is very strongly NOT recommended), and b) not guaranteed to work smoothly (or at all). Someone with a LOT of experience with debian or ubuntu should be able to do itanyone else should follow the recommended upgrade procedure. > install instead of repair? I would never recommend that an ubuntu (or debian. or mint. etc) be re-installed rather than upgraded/repaired UNLESS the system had been completely trashed or the system had been compromised (in which case, you can't trust ANY executable or config file on the system). In either of these cases, make a backup of your DATA if you don't already have one, install the system from scratch, and then restore your data. If you also have backups of config files in /etc or wherever, you can use them as guidelines to recreate new config files (if the system had been compromised) or just copy them (if it hadn't been compromised). > 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? as long as the entry in /etc/fstab is good, it should. craig -- craig sanders ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Weird boot issue
On Sat, Jan 11, 2020 at 03:44:21PM +1100, Andrew Greig wrote: > As it turns out the system does reference the drives by UUIDs. > > So, my question is, "by fixing grub 2.8 will my RAID under BTRFS just work? > Or will I have to run something to get it working as well?" if you're not booting off the btrfs drives, grub doesn't need to know or care that they exist. All it needs to know about is where and what the root filesystem and /boot directory/filesystem are - i.e. what drive and partition and what kind of fs (e.g. ext2/3/4, xfs, btrfs, etc). The btrfs filesystem will be mounted AFTER the kernel has booted, mounted the the rootfs, and started the init process (probably systemd for newer systems, maybe sysvinit for older systems). It will use the contents of /etc/fstab to do that - and that's where it's important to use UUID or LABEL rather than hard-coding /dev/sdXn device names. In short as long as the /etc/fstab entry for your btrfs mount is correct, then it will work. craig -- craig sanders ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Weird boot issue
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
Re: Weird boot issue
Hi Craig, Thanks for your comprehensive reply. As it turns out the system does reference the drives by UUIDs. So, my question is, "by fixing grub 2.8 will my RAID under BTRFS just work? Or will I have to run something to get it working as well?" 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
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/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
Weird boot issue
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: GNU GRUB version 2.02Minimal BASH-like line editing is supported. For the first word, TAB listspossible command completions. Anywhere else TAB listspossible device or file completions.grub> _ ( flashing cursor)Don't know what to do here.I am running an ssd as sda, sdb and sdc are in a btrfs RAID array.Puzzled by this behaviour.Any help appreciatedAndrew GreigSent from Samsung tablet.___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
