CentOSThis forum is for the discussion of CentOS Linux. Note: This forum does not have any official participation.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi folks. Moved on from other threads where I migrated my CentOS7 to another SSD. I'm having some boot issues which is booting into emergency mode for some reason.
I've taken out all extra drives (backups, etc.) and just have my boot volume in there, which is /dev/sda. Even with /etc/fstab volumes in there, this boot process is taking some time, up over a minute, and into emergency mode.
Code:
$ journalctl -xb
tmpfs: Bad mount option huge
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled
...
Timed out waiting for device <../../dm-2>
...
Timed out waiting for device dev-sdc.device
...
Failed to start Security Auditing Service
...
Usually it boots almost instantly, and now it is quite slow, with a problematic boot into emergency mode.
How can I fix this? Where should I start looking? Drives plugged in or not, same issue.
Oh indeed it is. Booting was fixed on the old volume (why the BIOS would screw with volumes, is very strange), but I am trying to migrate a system to a new volume. Apparently that is not heard of, or was spoken about 8 years ago, according to the things I'm finding.
It boots to the new drive, but it boots into emergency mode. I've read that the logs are where the problems are noted, so that's where I went. I copied a volume that works, then booting up on the new volume, everything is moved around. I've changed the /etc/fstab file and it's all a mess. I've watched countless videos on all this, read up on many sites, pdfs, and I have no clue what's wrong, nor how /etc/fstab doesn't mention a volume I have, yet it's not posing any problems.
As to business_kid's question, what is it you want to know about grub? It seems like a dynamic script from what I see. If you expect hard entries, I've never seen anything like that in the old (current boot) volume, nor the new one. I thought grub would know about the OS versions that got copied over. I guess that was an oversight on my part. Should I just install grub that was installed on the original? Did the rsync not copy that over?
I'm new to this OS. I didn't know such simple processes would have little reference online. That's why I'm in here asking questions.
If booting is the issue, that's before any logging. Why not talk to us about grub, or whatever RH is booting with these days?
I have absolutely no clue what RH is booting with these days. That's why I'm on LinuxQuestions.org. I copied a full boot volume from a resurrected volume that boots fine. I changed the UEFI (BIOS, whatever you want to call it), and it boots into emergency mode. I don't know why. There is no grubquestions.org. Heh.
Perhaps we can say more when we see your /etc/fstab. This is a guess: Your computer seems to go to emergency mode because /dev/sdc is in fstab but can't be found. If that is correct, consider using the filesystem's UUID instead of the device file name.
As an initial workaround, you can also add nofail to the mount options in fstab to ignore such errors.
You may find additional information in the kernel message buffer (dmesg command). Look for storage-related messages.
The lsblk command and the /sys/block directory tell you the list of storage devices as the kernel sees them. A look at this list might clue you in as well.
Last edited by berndbausch; 10-02-2019 at 07:19 PM.
Reason: added fstab option
Was that a joke? :-o.
No grubquestions.org, but you are presenting a booting problem without giving us your boot configuration. I was asking to see your /etc/lilo.conf, or /boot/grub/grub.cfg.
If your distro uses UUIDS, we will also need the output of
As to business_kid's question, what is it you want to know about grub? It seems like a dynamic script from what I see. If you expect hard entries, I've never seen anything like that in the old (current boot) volume, nor the new one. I thought grub would know about the OS versions that got copied over. I guess that was an oversight on my part. Should I just install grub that was installed on the original? Did the rsync not copy that over?
GRUB doesn't know anything about your OS versions until you run the update-grub script (which you must do as root). Then the ancillary scripts should sniff out your systems and create a proper grub.cfg file in the /boot directory. This is used by the actual GRUB program to create a menu dynamically at boot time.
I think it is grub.cfg that Business_kid would like to see.
GRUB doesn't know anything about your OS versions until you run the update-grub script (which you must do as root). Then the ancillary scripts should sniff out your systems and create a proper grub.cfg file in the /boot directory. This is used by the actual GRUB program to create a menu dynamically at boot time.
I think it is grub.cfg that Business_kid would like to see.
OK, I'm going to try that and post all the info about volumes later on. I've not tripped over update-grub yet.
Was that a joke? :-o.
No grubquestions.org, but you are presenting a booting problem without giving us your boot configuration. I was asking to see your /etc/lilo.conf, or /boot/grub/grub.cfg.
If your distro uses UUIDS, we will also need the output of
Code:
ls -l /dev/disk/by-uuid
OK, here are the reports. First, with sdb plugged in and everything running as it should without sdb wanted/needed.
Code:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111.8G 0 disk
├─sda1 8:1 0 200M 0 part /boot/efi
├─sda2 8:2 0 1G 0 part /boot
└─sda3 8:3 0 110.6G 0 part
├─centos-root 253:0 0 50G 0 lvm /
├─centos-swap 253:1 0 7.7G 0 lvm [SWAP]
└─centos-home 253:3 0 52.9G 0 lvm /home
sdb 8:16 0 111.8G 0 disk
└─shadowneb-shadow_n 253:2 0 110G 0 lvm /home/backups
sdc 8:32 0 232.9G 0 disk
$ cat /etc/fstab # WITH sdb installed
# /etc/fstab
# Created by anaconda on Mon Sep 10 16:27:03 2018
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
/dev/mapper/centos-root / xfs defaults 0 0
/dev/sda2 /boot xfs defaults 0 0
/dev/sda1 /boot/efi vfat umask=0077,shortname=winnt 0 0
/dev/mapper/centos-home /home xfs defaults 0 0
/dev/mapper/centos-swap swap swap defaults 0 0
# RF mods for /dev/sdb backup disk:
UUID=4fba19c4-01e1-4afd-b541-2682b80983cd /home/backups ext4 defaults 0 0
$ ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Oct 2 11:55 04fde641-f537-49b4-a617-451e4325c92c -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 2 11:55 0a7ca014-5aff-419d-b393-5e5cac26f182 -> ../../dm-3
lrwxrwxrwx 1 root root 10 Oct 2 11:55 33669fd2-6177-4f9e-a06c-e9c9d9270f2d -> ../../dm-1
lrwxrwxrwx 1 root root 10 Oct 2 11:55 3979-7E7E -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 2 11:55 4fba19c4-01e1-4afd-b541-2682b80983cd -> ../../dm-2
lrwxrwxrwx 1 root root 10 Oct 2 11:55 bde0e85d-4653-451c-a6a5-8222fc3825ee -> ../../dm-0
lrwxrwxrwx 1 root root 9 Oct 2 11:55 f2450034-7cd0-459a-aa6b-49ce4d45bcde -> ../../sdc
Booted up without sdb installed, into emergency mode with no network. That last feedback is what changes when I take the sdb out:
Code:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111.8G 0 disk
├─sda1 8:1 0 200M 0 part /boot/efi
├─sda2 8:2 0 1G 0 part /boot
└─sda3 8:3 0 110.6G 0 part
├─centos-root 253:0 0 50G 0 lvm /
├─centos-swap 253:1 0 7.7G 0 lvm [SWAP]
└─centos-home 253:2 0 52.9G 0 lvm /home
sdb 8:16 0 232.9G 0 disk
# /etc/fstab
# Created by anaconda on Mon Sep 10 16:27:03 2018
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
/dev/mapper/centos-root / xfs defaults 0 0
/dev/sda2 /boot xfs defaults 0 0
/dev/sda1 /boot/efi vfat umask=0077,shortname=winnt 0 0
/dev/mapper/centos-home /home xfs defaults 0 0
/dev/mapper/centos-swap swap swap defaults 0 0
# RF mods for /dev/sdb backup disk:
UUID=4fba19c4-01e1-4afd-b541-2682b80983cd /home/backups ext4 defaults 0 0
total 0
lrwxrwxrwx 1 root root 10 Oct 4 15:30 04fde641-f537-49b4-a617-451e4325c92c -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 4 15:30 0a7ca014-5aff-419d-b393-5e5cac26f182 -> ../../dm-2
lrwxrwxrwx 1 root root 10 Oct 4 15:30 33669fd2-6177-4f9e-a06c-e9c9d9270f2d -> ../../dm-1
lrwxrwxrwx 1 root root 10 Oct 4 15:30 3979-7E7E -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 4 15:30 bde0e85d-4653-451c-a6a5-8222fc3825ee -> ../../dm-0
lrwxrwxrwx 1 root root 9 Oct 4 15:30 f2450034-7cd0-459a-aa6b-49ce4d45bcde -> ../../sdb
I'm thinking the /home/backups is not in the second version at all, but I don't know how the system got that entry. Anyway, I think a redo of the grub.cfg. Should I post both grub files?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
