Oddly enough the slow boot / shutdowns have dissappeared, the only
remaining issue is the bios setting weirdness, including the fact that
Linux will not boot without legacy OS Boot = on
Thoughts?
On 5/7/19 8:08 PM, Chris Murphy wrote:
On Tue, May 7, 2019 at 3:54 PM S. Bob <sbob@xxxxxxxxxxxxxxxxxxxxx> wrote:
root@F30-host # cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Wed Dec 31 19:25:43 1997
#
# 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.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=e2654eae-f91a-4703-a18e-9ff92e815450 / ext4 defaults 1 1
UUID=de4a0b48-7d2b-49c5-b8cb-feca56178444 /boot ext4 defaults 1 2
UUID=361aeb12-1e4e-494f-9a05-be298b45828a /data ext4 defaults 1 2
UUID=2eb9d524-e7e3-4e8a-823f-cea19f3a3483 none swap defaults 0 0
And here is the output from the blkid command:
root@F30-host # blkid
/dev/sda1: UUID="de4a0b48-7d2b-49c5-b8cb-feca56178444" TYPE="ext4"
PARTUUID="35cdfa7a-01"
/dev/sda2: UUID="e2654eae-f91a-4703-a18e-9ff92e815450" TYPE="ext4"
PARTUUID="35cdfa7a-02"
/dev/sda3: UUID="2eb9d524-e7e3-4e8a-823f-cea19f3a3483" TYPE="swap"
PARTUUID="35cdfa7a-03"
/dev/sdb1: UUID="361aeb12-1e4e-494f-9a05-be298b45828a" TYPE="ext4"
PARTUUID="a474e262-01"
Both of those are reasonable.
I'd do the debug shell bit, and then do:
# systemctl list-jobs
# systemctl status <name of hung job if any>
# journalctl -b -o short-monotonic
# coredumpctl
The monotonic time instead of wall clock time will make it easier to
see delays. You can add '> journal.log' to output to a file and post
it somewhere, maybe someone on the list will have interest in poking
through it.
The three ways to get more verbose logging are the following boot parameters:
systemd.log_level=debug rd.udev.debug rd.debug
I don't often use all three at the time time because each one makes
boot slower and the journal much bigger, and there's that much more
stuff to have to go through. On the other hand, if you have no idea
what's going on, it can be tedious to use them separately. I almost
always start with systemd debug first, and then udev debug (often
omitting systemd debug). Maybe you've got a drive that's just not
mounting very quickly and it's holding up the flush to journal, I'm
not really sure what would cause that. Another possibility is
something is crashing and the coredump being written to /var is
soaking the available write bandwidth of the drive, the coredumpctl
command will list captured crashes.
So yeah you'll have to poke around.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
