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(a)quadratum-braccas.com> 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.
>