Hi All;
I've managed to install Fedora 30 on a new LG Gram 17 laptop.
I had to set acpi=off to get the live cd to boot, then I had to remove the acpi=off and rebuild the EFI grub file so the trackpad would work, subsequent boots without the acpi=off seem to work fine.
I am seeing an odd situation when I shutdown & restart:
1) shutdown often takes a long time, I see that stop jobs are running either for packagekit or sometimes "flush journal to persistent storage"
2) sometimes booting up takes a long time , indicating a start job is running - flush journal to persistent storage
3) If I ever do a hard power off then it boots to what seems to be a windows boot manager, showing several options, like this:
1. ATA HDD1: HFS512G39TNF-N3A0A
2. ATA HDD2: CT1000MX500SSD4
3. Windows Boot Manager
Then I need to power off again and change the following bios settings, they always get changed when I hard power off:
Legacy OS Boot - (Gets set to Disabled, Fedora won't boot unless this is set to Enabled)
RTC Wakeup from S4 - (Gets set to Enabled, Fedora won't boot unless this is set to Disabled)
SW Guard Extensions (SGX) - (Gets set to Enabled, Fedora won't boot unless this is set to Disabled)
Sometimes I need to go into secure boot configuration and choose "Delete All Signatures"
If I do a dnf update and get a new kernel then the above process is triggered as well
Other than struggling with booting a bit the laptop works great with Fedora.
Anyone have any insight on how to fix the above issues?
Thanks in advance
On Sun, May 5, 2019 at 1:41 PM S. Bob sbob@quadratum-braccas.com wrote:
Hi All;
I've managed to install Fedora 30 on a new LG Gram 17 laptop.
I had to set acpi=off to get the live cd to boot, then I had to remove the acpi=off and rebuild the EFI grub file so the trackpad would work, subsequent boots without the acpi=off seem to work fine.
I am seeing an odd situation when I shutdown & restart:
- shutdown often takes a long time, I see that stop jobs are running
either for packagekit or sometimes "flush journal to persistent storage"
- sometimes booting up takes a long time , indicating a start job is
running - flush journal to persistent storage
Boot parameter 'systemd.debug-shell=1' will give you a very early shell on tty9, with root available without a password needed. Useful for troubleshooting but it's a security risk. Once you get the hang, you can switch to tty9 and do
# systemctl list-jobs
And see which ones are hanging. And then
# systemctl status <job/service name>
I can't think of a reason off hand why flushing the journal would take a while if this is a default installation. What do you get for:
# cat /etc/fstab # blkid
The tty9 console will be available for a while during shutdown as well, and you can do the same list-jobs check, and also get status.
There are ways to get more verbose journal logging, but they are super verbose.
- If I ever do a hard power off then it boots to what seems to be a
windows boot manager, showing several options, like this:
ATA HDD1: HFS512G39TNF-N3A0A
ATA HDD2: CT1000MX500SSD4
Windows Boot Manager
Then I need to power off again and change the following bios settings, they always get changed when I hard power off:
Legacy OS Boot - (Gets set to Disabled, Fedora won't boot unless this is set to Enabled)
If this is enabled at the time Fedora is installed, you will get an installation (a bootloader) that depends on it always being. But it's a suboptimal arrangement.
The laptop has UEFI firmware, and this legacy boot option when enabled activates something called a Compatibility Support Module which will present a faux-BIOS firmware to the bootloader and operating system. It's designed for supporting old, and thus legacy, operating systems. Fedora isn't a legacy OS. Short of unfixable or unworkaroundable UEFI bugs, it's better if this option is disabled and you reinstall, even if you have some new problems related to UEFI to work through.
At least on one of my laptops with legacy mode, SSD drives run in IDE compatibility mode rather than as SATA devices, and everything is slower, but not as slow as what it sounds like you're experiencing.
I also think it's a little weird that these firmware settings change when you hard reset. It makes me suspect firmware bugs, and that means there might be a firmware update that'll fix them. Confusingly the manufacturers often still call these BIOS updates, even though what they mean is firmware update. So I suggest checking for firmware updates with the manufacture. If you don't have Windows installed, hopefully they have a DOS based installer. Those come in two flavors, single image that includes DOS and the updater, and updater only. If updater only you can use FreeDOS.
RTC Wakeup from S4 - (Gets set to Enabled, Fedora won't boot unless this is set to Disabled)
SW Guard Extensions (SGX) - (Gets set to Enabled, Fedora won't boot unless this is set to Disabled)
Sometimes I need to go into secure boot configuration and choose "Delete All Signatures"
That's not expected. Secure Boot is disabled when Legacy OS is enabled. The two aren't compatible.
If I do a dnf update and get a new kernel then the above process is triggered as well
Other than struggling with booting a bit the laptop works great with Fedora.
Anyone have any insight on how to fix the above issues?
Can't fix it until the problem is understood. Right now it's a search for why it's happening.
On 5/5/19 10:45 PM, Chris Murphy wrote:
On Sun, May 5, 2019 at 1:41 PM S. Bob sbob@quadratum-braccas.com wrote:
Hi All;
I've managed to install Fedora 30 on a new LG Gram 17 laptop.
I had to set acpi=off to get the live cd to boot, then I had to remove the acpi=off and rebuild the EFI grub file so the trackpad would work, subsequent boots without the acpi=off seem to work fine.
I am seeing an odd situation when I shutdown & restart:
- shutdown often takes a long time, I see that stop jobs are running
either for packagekit or sometimes "flush journal to persistent storage"
- sometimes booting up takes a long time , indicating a start job is
running - flush journal to persistent storage
Boot parameter 'systemd.debug-shell=1' will give you a very early shell on tty9, with root available without a password needed. Useful for troubleshooting but it's a security risk. Once you get the hang, you can switch to tty9 and do
# systemctl list-jobs
And see which ones are hanging. And then
# systemctl status <job/service name>
I can't think of a reason off hand why flushing the journal would take a while if this is a default installation. What do you get for:
# cat /etc/fstab # blkid
The tty9 console will be available for a while during shutdown as well, and you can do the same list-jobs check, and also get status.
There are ways to get more verbose journal logging, but they are super verbose.
- If I ever do a hard power off then it boots to what seems to be a
windows boot manager, showing several options, like this:
ATA HDD1: HFS512G39TNF-N3A0A
ATA HDD2: CT1000MX500SSD4
Windows Boot Manager
Then I need to power off again and change the following bios settings, they always get changed when I hard power off:
Legacy OS Boot - (Gets set to Disabled, Fedora won't boot unless this is set to Enabled)
If this is enabled at the time Fedora is installed, you will get an installation (a bootloader) that depends on it always being. But it's a suboptimal arrangement.
The laptop has UEFI firmware, and this legacy boot option when enabled activates something called a Compatibility Support Module which will present a faux-BIOS firmware to the bootloader and operating system. It's designed for supporting old, and thus legacy, operating systems. Fedora isn't a legacy OS. Short of unfixable or unworkaroundable UEFI bugs, it's better if this option is disabled and you reinstall, even if you have some new problems related to UEFI to work through.
At least on one of my laptops with legacy mode, SSD drives run in IDE compatibility mode rather than as SATA devices, and everything is slower, but not as slow as what it sounds like you're experiencing.
I also think it's a little weird that these firmware settings change when you hard reset. It makes me suspect firmware bugs, and that means there might be a firmware update that'll fix them. Confusingly the manufacturers often still call these BIOS updates, even though what they mean is firmware update. So I suggest checking for firmware updates with the manufacture. If you don't have Windows installed, hopefully they have a DOS based installer. Those come in two flavors, single image that includes DOS and the updater, and updater only. If updater only you can use FreeDOS.
RTC Wakeup from S4 - (Gets set to Enabled, Fedora won't boot unless this is set to Disabled)
SW Guard Extensions (SGX) - (Gets set to Enabled, Fedora won't boot unless this is set to Disabled)
Sometimes I need to go into secure boot configuration and choose "Delete All Signatures"
That's not expected. Secure Boot is disabled when Legacy OS is enabled. The two aren't compatible.
If I do a dnf update and get a new kernel then the above process is triggered as well
Other than struggling with booting a bit the laptop works great with Fedora.
Anyone have any insight on how to fix the above issues?
Can't fix it until the problem is understood. Right now it's a search for why it's happening.
Thanks, I'll give the list-jobs bit a try.
Meanwhile here is mt fstab file:
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"
On Tue, May 7, 2019 at 3:54 PM S. Bob sbob@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.
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@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.
On Tue, May 7, 2019 at 8:44 PM S. Bob sbob@quadratum-braccas.com wrote:
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?
From my first response: If this is enabled at the time Fedora is installed, you will get an installation (a bootloader) that depends on it always being. But it's a suboptimal arrangement.
That's incomplete: "depends on it always being on."
That is, if Legacy is enabled when you do the installation, you can only boot with Legacy enabled. If you want to use UEFI (Legacy disabled) you need to first disable the Legacy setting, and then boot installation media and reinstall. And now you have a UEFI installation which will only boot if Legacy is disabled.
On 5/7/19 7:43 PM, S. Bob wrote:
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
That's not weird. You don't have an EFI boot partition, so you can only boot in legacy mode. You don't mention if it's a GPT partition table or not.
-
Chris Murphy -
Joe Zeff -
S. Bob -
Samuel Sieb