On 16/2/19 2:44 pm, Craig Sanders via luv-main wrote:

On Sat, Feb 16, 2019 at 01:02:44PM +1100, Andrew Greig wrote:
I have had some disks "ready to go" for a couple of months, meaning all that
was required was to plug the SATA cables into the MB. I plugged them in
today and booted the machine, except that it did not boot up. Ubuntu 18.04,
it stopped at the Ubuntu burgundy screen and then went black and nowhere
from that state.

I  shut it down and removed the 2 SATA cables from the MB and booted up -
successfully.

It is apparent that I lack understanding, hoping for enlightenment
Is your /etc/fstab configured to mount the root fs (and any other filesystems)
by device node (e.g. /dev/sda1), or by the UUID or LABEL?

If you're using device node names, then you've run into the well-known fact
that linux does not guarantee that device names will remain the same across
reboots.  This is why you should always either use the filesystems' UUIDs or
create labels on the filesystems and use those.


The device node may change because the hardware has changed - e.g. you've
added or removed drive(s) from the systems (this is likely to be the case for
your system).  They may also change because the load order of driver modules
has changed, or because of timing issues in exactly when a particular drive
is detected by linux.  They may also change after a kernel upgrade.  Or they
may change for no reason at all.  They are explicitly not guaranteed to be
consistent across reboots.

For over a decade now, the advice from linux kernel devs and pretty much
everyone else has been:

DEVICE NODES CAN AND WILL CHANGE WITHOUT WARNING.  NEVER USE THE DEVICE NODE
IN /etc/fstab.  ALWAYS USE UUID OR LABEL.

BTW, if you want to read up on what a UUID is, start here:

https://en.wikipedia.org/wiki/Universally_unique_identifier


Note: it's not uncommon for device node names to remain the same for months
or years, even with drives being added to or removed from the system.  That's
nice, but it doesn't matter - think of it as a happy coincidence, certainly
not as something that can be relied upon.



To fix, you'll need to boot a "Live" CD or USB stick (the gparted and
clonezilla ISOs make good rescue systems), mount your system's root fs
somewhere (e.g. as "/target"), and edit "/target/etc/fstab" so that it refers
to all filesystems and swap partitions by UUID or LABEL.

If you don't have a live CD (and can't get one because you can't boot your
system), you should be able to do the same from the initrd bash shell, or by
adding "init=/bin/bash" to the kernel command line from the grub menu.  You'd
need to run "mount -o rw,remount /" to remount the root fs as RW before you
can edit /etc/fstab.  Any method which gets you your system's root fs mounted
RW will work.


To find the UUID or LABEL for a filesystem, run "blkid".  It will produce
output like this:


# blkid
/dev/sde1: LABEL="i_boot" UUID="69b22c56-2f10-45e8-ad0e-46a7c7dd1b43" TYPE="ext4" PARTUUID="1dbd3d85-01"
/dev/sde2: LABEL="i_swap" UUID="a765866d-3444-48a1-a598-b8875d508c7d" TYPE="swap" PARTUUID="1dbd3d85-02"
/dev/sde3: LABEL="i_root" UUID="198c2087-85bb-439c-9d97-012a87b95f0c" TYPE="ext4" PARTUUID="1dbd3d85-03"

If blkid isn't available, try 'lsblk -f'.  Both blkid and lsblk will be on a
system rescue disk, but may not be available from an initrd shell.  If udev
has already run, you can find symlinks linking the UUID to the device name in
/dev/disk/by-uuid.

NOTE: UUIDs will *always* exist for a filesystem, they are created
automatically when the fs is created.  Labels will only exist if you've
created them (the exact method varies according to the filesystem - e.g. for
ext4, by using the "-L" option when you create a fs with mkfs.ext4, or by
using "tune2fs" any time after the fs has been created).



Using the above as an example, if your fstab wanted to mount /dev/sde3 as /,
change /dev/sde3 to UUID=198c2087-85bb-439c-9d97-012a87b95f0c - e.g.

          UUID=198c2087-85bb-439c-9d97-012a87b95f0c    /    ext4    defaults,relatime,nodiratime 0 1

alternatively, if you've created labels for the filesystems, you could use something like:

          LABEL=i_root    /    ext4    defaults,relatime,nodiratime 0 1


Do this for **ALL** filesystems and swap devices listed in /etc/fstab.


Save the edited fstab, run "sync", and then unmount the filesystem.  You
should then be able to boot into your system.

craig

--
craig sanders <cas@taz.net.au>
_______________________________________________
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main


Hi Craig,

I have been on this list since around 2004 but mainly as a user of Linux, not a sys admin of Linux.

My understanding is limited because I have found little which needed solving, until now.

I don't understand why /etc/fstab contains so little info - is this a ubuntu feature?

As for editing the fstab to include the UUIDs of the disks, having read the info on UUIDs, the link for which you provided, I believe that these are meant to be created in my machine.  If so, at what stage and with what process?

I was not particularly convinced of the gparted outcome. I have 14Gb of RAW files on my drive, and 380Gb of photo image files in the cloud. So really I need to back up around 500Gb data to an external HDD and then I could to a re-install of everything.

Also this entry in dmesg has me wondering if I might get better performance if I changed the setting in the BIOS:

[   63.344355] EDAC amd64: Node 0: DRAM ECC disabled.
[   63.344357] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.
                Either enable ECC checking or force module loading by setting 'ecc_enable_override'.
                (Note that use of the override may cause unknown side effects.)

At the moment the machine is very slow to get up to speed, currently running 8Gb RAM/

Thanks

Andrew