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. -- Chris Murphy _______________________________________________ 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
