Closed Melechtna closed 2 years ago
There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.
There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.
The 5.17 kernel has the pixelbook prefix after it, so I assumed it was specifically built. What information would you need? Dmesg is honestly a mess, so I'm not sure which error is relevant and none of them seem specific enough, and I have to boot into an older kernel, as the newer one just hard crashes and reboots the device.
Have you updated the firmware recently. There are a few traces in dmesg that are fixed by updating: https://bugzilla.kernel.org/show_bug.cgi?id=215269
https://github.com/jmontleon/pixelbook-fedora/issues/5 is another example where another trace was fixed by a coreboot update.
This is the reason updating is called out specifically: https://github.com/jmontleon/pixelbook-fedora#update-coreboot
If you have a kernel with .pixelbook in the relase it's old and should be replaced by doing a dnf update. That's definitely the case for Fedora 36 and should be true for Fedora 35 and 34 as well as updates are in stable. https://bodhi.fedoraproject.org/updates/FEDORA-2022-a0f65397a3 https://bodhi.fedoraproject.org/updates/FEDORA-2022-fd85148be2
The last kernel I built was 5.17.4. https://copr.fedorainfracloud.org/coprs/jmontleon/pixelbook/packages/
This is about the point at which coreboot 4.16 became available, which fixes the typec problem. The only difference for the last several versions was that the pixelbook kernels didn't build the typec module so folks didn't have to blacklist it. https://mrchromebox.tech/#home
There is supposedly a kernel fix in place as well, but it is not complete as I called out here: https://bugzilla.kernel.org/show_bug.cgi?id=215269#c8 and others have basically confirmed here: https://github.com/jmontleon/pixelbook-fedora/issues/28
To summarize:
Have you updated the firmware recently. There are a few traces in dmesg that are fixed by updating: https://bugzilla.kernel.org/show_bug.cgi?id=215269
I set all this up the day I posted this. Meaning I installed Mr. Chromebox's firmware the day of (meaning yes, its' the 4.16). It pulled the 5.17.4-301.pixelbook kernel using your instructions, and the only other kernel it has is the 5.14 kernel. It's not pulling anything else using dnf, and yes it's a Pixelbook EVE.
Also, weirdly enough, the person that's primarily using this machine SOMEHOW got it to boot that kernel once, but can't tell me how, and everything was working, until I tried updating again (still pulled no new kernel) and rebooting, and it's back to a black screen on boot.
There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.
The 5.17 kernel has the pixelbook prefix after it, so I assumed it was specifically built. What information would you need? Dmesg is honestly a mess, so I'm not sure which error is relevant and none of them seem specific enough, and I have to boot into an older kernel, as the newer one just hard crashes and reboots the device.
Can you share the dmesg output. If you see problems there it's probably the place to start.
There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.
The 5.17 kernel has the pixelbook prefix after it, so I assumed it was specifically built. What information would you need? Dmesg is honestly a mess, so I'm not sure which error is relevant and none of them seem specific enough, and I have to boot into an older kernel, as the newer one just hard crashes and reboots the device.
Can you share the dmesg output. If you see problems there it's probably the place to start.
How do I get a dmesg from the 5.17 kernel that isn't working (except when I'm not looking)? dmesg.txt Here's the one for the 5.14 kernel that is working.
There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.
The 5.17 kernel has the pixelbook prefix after it, so I assumed it was specifically built. What information would you need? Dmesg is honestly a mess, so I'm not sure which error is relevant and none of them seem specific enough, and I have to boot into an older kernel, as the newer one just hard crashes and reboots the device.
Can you share the dmesg output. If you see problems there it's probably the place to start.
journalctl.txt from the 5.17 using journalctl
Sorry, maybe I misunderstood. You said dmesg was 'a mess'. This implied to me you were seeing traces and problems.
And example of what this would look like: https://github.com/jmontleon/pixelbook-fedora/issues/5#issuecomment-985623474
I don't see anything like that in the above. Did you see something in particular?
And a stupid question: The brightness keys don't do anything? The backlight was broken and full on (or off if you set it) until 5.16. https://github.com/jmontleon/pixelbook-fedora#other-distributions / https://gitlab.freedesktop.org/drm/intel/-/issues/3680
If somehow the brightness is turned all the way down that might in part account for why the display is working with 5.14.
If you run sudo dnf clean all && sudo dnf -y update
I'd be curious of the output on that too. To be clear there's no reason 5.17.4-301.pixelbook.fc35.x86_64
shouldn't to my knowledge work. The difference in the kernel config amounts to https://github.com/jmontleon/pixelbook-fedora/blob/main/kernel/kernel-config.patch. It is curious that you aren't getting 5.17.5 or 5.17.6 as an update though.
If you have doubt about the brightness keys functioning you can cat / echo to /sys/class/backlight/intel_backlight/brightness
. For example full brightness appears to be: echo 32767 > /sys/class/backlight/intel_backlight/brightness
.
For yum contents of /etc/yum.repos.d/_copr\:copr.fedorainfracloud.org\:jmontleon\:pixelbook.repo
might be interesting too. Make sure no priority is set that would cause older packages from there to take precedent over new packages. Even sudo dnf clean all && sudo dnf -y update --disablerepo=copr:copr.fedorainfracloud.org:jmontleon:pixelbook
just for curiosities sake.
For yum contents of
/etc/yum.repos.d/_copr\:copr.fedorainfracloud.org\:jmontleon\:pixelbook.repo
might be interesting too. Make sure no priority is set that would cause older packages from there to take precedent over new packages.
I normally use Arch, I have no idea how I'd even check that with Fedora, this is just the only project that actually has this device working and I'm tired of trying to get it to work on Arch. I'll try disabling your repo.
The blacklight buttons don't work, it cleaned 68 files and said there was nothing to do, brightness there is set to 1500, I'll try setting it to 32767 and reboot.
Edit: won't let me echo that value into it, says it's an invalid argument. Edit2: says no repository found, and I know your repo is there, else I wouldn't have the console commands. So I have no idea why it's not finding it.
The blacklight buttons don't work, it cleaned 68 files and said there was nothing to do, brightness there is set to 1500, I'll try setting it to 32767 and reboot.
Memory is fuzzy, but 1500 sounds like the value from the 5.14/5.15 kernels. Boot into the 5.17 kernel and try. Same wtih the brightness keys. They won't do anything on 5.14. Brightness was not functional until 5.16.
Run this and you should get new kernels. Unfortunately the README instructed to lower the priority. I'll probably end up deleting the kernel package from the repo so folks can get updates like they're supposed to.
sudo dnf config-manager --setopt 'copr:copr.fedorainfracloud.org:jmontleon:pixelbook.priority=99' --save
The blacklight buttons don't work, it cleaned 68 files and said there was nothing to do, brightness there is set to 1500, I'll try setting it to 32767 and reboot.
Memory is fuzzy, but 1500 sounds like the value from the 5.14/5.15 kernels. Boot into the 5.17 kernel and try. Same wtih the brightness keys. They won't do anything on 5.14. Brightness was not functional until 5.16.
How do I do that when it doesn't boot? I also said that it doesn't work, I meant in the 5.17 kernel. It STILL claims that repo doesn't exist, even though I've been through and tried re-adding it twice now.
Can you ssh into it? The dmesg output suggests it's booting OK.
You're going to have to explain this one to me, I have no idea how it claims it doesn't exist, when it clearly exists.
You can also just manually edit the file. Change the line priority=98
to priority=99
(or just delete it, default if its not specified is 99).
You can also just manually edit the file. Change the line
priority=98
topriority=99
(or just delete it, default if its not specified is 99).
I don't know fedoras file structure for it's repositories. Where would that one be? In arch it'd just be, /etc/pacman.conf
Same place I suggested looking earlier /etc/yum.repos.d/_copr\:copr.fedorainfracloud.org\:jmontleon\:pixelbook.repo
https://github.com/jmontleon/pixelbook-fedora/issues/29#issuecomment-1123917559
That did it. It's now updating to the 5.17.6 kernel, and it's booting with the same issue. Let me try SSHing in.
Well, good news, I can SSH in, I can echo the value for brightness, but the screen remains black...just brighter black.
dmesg.txt here's the dmesg from the new kernel. The parts that I'm THINKING are relavent, maybe, are
[ 88.283356] snd_soc_skl 0000:00:1f.3: ASoC: error at soc_dai_trigger on HDMI2 Pin: -32 [ 88.283363] Kbl HDMI Port2: ASoC: trigger FE cmd: 1 failed: -32
Those are audio related https://www.kernel.org/doc/html/latest/sound/soc/index.html#
I have those as well and as far as I know mostly harmless.
$ dmesg | grep ASoC
[ 5.472929] snd_soc_skl 0000:00:1f.3: ASoC: no sink widget found for AEC Capture
[ 5.472933] snd_soc_skl 0000:00:1f.3: ASoC: Failed to add route echo_ref_out cpr 7 -> direct -> AEC Capture
[ 5.472941] kbl_r5514_5663_max kbl_r5514_5663_max: ASoC: Parent card not yet available, widget card binding deferred
[ 13.827324] snd_soc_skl 0000:00:1f.3: ASoC: error at soc_dai_trigger on HDMI2 Pin: -32
[ 13.827331] Kbl HDMI Port2: ASoC: trigger FE cmd: 1 failed: -32
[ 14.221872] snd_soc_skl 0000:00:1f.3: ASoC: error at soc_dai_trigger on HDMI1 Pin: -32
[ 14.221878] Kbl HDMI Port1: ASoC: trigger FE cmd: 1 failed: -32
What's the value in /sys/class/backlight/intel_backlight/brightness
/var/log/Xorg.0.log
or whatever Wayland logs to could be potentially informative.
xorg.txt Here's that, and in even weirder news, I figured out how he got it working. So, if it's left alone long enough to go to sleep, and woken back up, the screen starts working again.
Edit: Looks like at 10.950 it's failing to find and ignoring the device initially.
/sys/class/backlight/intel_backlight/brightness
is set to a reasonably high value?
The end of your Xorg.log looks like you attempted to change VT, but otherwise doesn't have any errors.
I have several lines similar to what you're seeing and I think they're just noise:
[ 10.471] (II) No input driver specified, ignoring this device.
[ 10.471] (II) This device may have been added with another device file.
In my Xorg.0.log it finishes up like this. I don't see similar in yours, which is interesting... hard to guage whether it's a difference in Xorg between Fedora 35 and 36 or something more meaningful.
[ 12.295] (II) modeset(0): EDID vendor "SHP", prod id 5258
[ 12.295] (II) modeset(0): Printing DDC gathered Modelines:
[ 12.295] (II) modeset(0): Modeline "2400x1600"x0.0 252.75 2400 2448 2480 2560 1600 1603 1613 1646 -hsync -vsync (98.7 kHz eP)
/sys/class/backlight/intel_backlight/brightness
is set to a reasonably high value?The end of your Xorg.log looks like you attempted to change VT, but otherwise doesn't have any errors.
I have several lines similar to what you're seeing and I think they're just noise:
[ 10.471] (II) No input driver specified, ignoring this device. [ 10.471] (II) This device may have been added with another device file.
I literally didn't do anything other than wake it up. On boot, there's nothing, so that change in VT must be what's making it work again. As for it's current value it returns 6553, it's set pretty low at the moment.
3283 is the lowest it went before I couldnt see anything anymore; 6553 would hopefully be visible.
echo 32767 > /sys/class/backlight/intel_backlight/brightness
would probably work now, but if you can't see anything now I'm not hopefully?
Do you know what display manager you're using? If you're not even getting a login prompt maybe a different one would give different result.
sudo dnf -y install lightdm
sudo systemctl --force enable lightdm
sudo reboot
If the systemctl command produces output I'd be interested in seeing it, especially if that gets you a login prompt if you're not getting one now.
Looks like you're using sddm with the breeze theme from the journal log you attached above. There's some interesting bugs regarding blank screens with sddm after kernel updates, but nothing I could pinpoint as likely to be your exact situation. And nothing I can reproduce on Fedora 36.
Trying lightdm or another as an alternative would be interesting.
3283 is the lowest it went before I couldnt see anything anymore; 6553 would hopefully be visible.
echo 32767 > /sys/class/backlight/intel_backlight/brightness
would probably work now, but if you can't see anything now I'm not hopefully?Do you know what display manager you're using? If you're not even getting a login prompt maybe a different one would give different result.
sudo dnf -y install lightdm sudo systemctl --force enable lightdm sudo reboot
If the systemctl command produces output I'd be interested in seeing it, especially if that gets you a login prompt if you're not getting one now.
Yeah, I can turn it full bright if I want to, I'll try lightDM and report back. I thought that SDDM thing was a long dead issue. Or is it because Fedora too commits the cardinal sin of keeping it's shit WAY too out of date?
Looks like you're using sddm with the breeze theme from the journal log you attached above. There's some interesting bugs regarding blank screens with sddm after kernel updates, but nothing I could pinpoint as likely to be your exact situation. And nothing I can reproduce on Fedora 36.
Trying lightdm or another as an alternative would be interesting.
Swapping to lightdm as you describe has seemed to make the issue worse, I can now no longer recover after putting it to sleep and waking it back up.
After trying several times, the screen came back up, and lightdm failed with an exit code of 'exit-code', which also prevents it from connecting to wifi, so I can't SSH into it anymore either.
Last version of sddm released appears to be 0.19.0. https://github.com/sddm/sddm/
I was able to reproduce your issue. It's definitely sddm. Specifically sddm 0.19.0 with the sddm-breeze theme.
Fedora 36 has a patched version https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb655b9b47 that fixes https://bugzilla.redhat.com/show_bug.cgi?id=2070130 but it seems it wasn't updated on Fedora 35. I downgraded to the prior version of the package on Fedora 36 and same issue.
Choices:
sudo dnf install rpmbuild
rpm -ivh https://kojipkgs.fedoraproject.org//packages/sddm/0.19.0^git20220321.e67307e/2.fc36/src/sddm-0.19.0^git20220321.e67307e-2.fc36.src.rpm
sudo dnf builddep -y ~/rpmbuild/SPECS/sddm.spec
rpmbuild -ba ~/rpmbuild/SPECS/sddm.spec
sudo dnf -y install ~/rpmbuild/RPMS/x86_64/sddm-0.19.0^git20220321.e67307e-2.fc35.x86_64.rpm ~/rpmbuild/RPMS/noarch/sddm-x11-0.19.0^git20220321.e67307e-2.fc35.noarch.rpm
sudo dnf -y update --releasever=36
sudo reboot
sudo dnf -y distro-sync
sudo dnf -y update
You can switch back to sddm sudo systemctl --force enable sddm
If you can't get logged in via lightdm reboot:
e
to edit one of the kernel entries (changes aren't persistent)rhgb quiet
to rhgb quiet systemd.unit=rescue.target
.Ctrl-x
to boot. systemctl enable sddm --force
Last version of sddm released appears to be 0.19.0. https://github.com/sddm/sddm/
I was able to reproduce your issue. It's definitely sddm. Specifically sddm 0.19.0 with the sddm-breeze theme.
Fedora 36 has a patched version https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb655b9b47 that fixes https://bugzilla.redhat.com/show_bug.cgi?id=2070130 but it seems it wasn't updated on Fedora 35. I downgraded to the prior version of the package on Fedora 36 and same issue.
Choices:
- You could probably rebuild it for yourself for Fedora 35. Be roughly:
sudo dnf install rpmbuild rpm -ivh https://kojipkgs.fedoraproject.org//packages/sddm/0.19.0^git20220321.e67307e/2.fc36/src/sddm-0.19.0^git20220321.e67307e-2.fc36.src.rpm sudo dnf builddep -y ~/rpmbuild/SPECS/sddm.spec rpmbuild -ba ~/rpmbuild/SPECS/sddm.spec sudo dnf -y install ~/rpmbuild/RPMS/x86_64/sddm-0.19.0^git20220321.e67307e-2.fc35.x86_64.rpm ~/rpmbuild/RPMS/noarch/sddm-x11-0.19.0^git20220321.e67307e-2.fc35.noarch.rpm
- File a bug and wait for them to fix it.
- Update to Fedora 36. There's a few ways to do this. My typical approach is something like, this but there are other documented approaches.
sudo dnf -y update --releasever=36 sudo reboot sudo dnf -y distro-sync sudo dnf -y update
You can switch back to sddm
sudo systemctl --force enable sddm
I'll try switching over to 36, because lightdm is not only doing the same thing, it NEVER comes up in the first place, making it not connect to the internet. After doing all that, I'm still getting the same issue after a reboot.
This isn't Pixelbook related. Looking at the BZ and duplicates it looks like this issue with sddm plagues a lot of hardware (Thinkpad T480, T580, etc.).
If there's something you spot that is specific I can do something about let me know, otherwise the best I can recommend is using Fedora 36 and updating to the latest version of sddm, with which I can't reproduce the issue.
This isn't Pixelbook related. Looking at the BZ and duplicates it looks like this issue with sddm plagues a lot of hardware (Thinkpad T480, T580, etc.).
If there's something you spot that is specific I can do something about let me know, otherwise the best I can recommend is using Fedora 36 and updating to the latest version of sddm, with which I can't reproduce the issue.
Then explain why lightdm not only has the SAME issue, but actually crashes irreparably and REFUSES to start period. Because I DID that.
I don't know. I use lightdm. It works fine for me. Perhaps it's a bug in Fedora 35 or something is misconfigured on your system. You will need to do some troubleshooting. If lightdm doesn't work for you use gdm, lxdm, kdm, xdm, or one of the myriad other display managers. If you want to use sddm I can confirm the most recent version works on Fedora 36.
I can reproduce your sddm issue with a specific version and point to bugs that show others with other hardware that have experienced the same. I get you're frustrated, but there are several people who have successfully set up Fedora using the instructions here. There is plenty of evidence of that. https://github.com/jmontleon/pixelbook-fedora/issues?q=is%3Aissue
If you dislike or are finding it difficult to troubleshoot on Fedora you can always use Arch or reinstall Chrome OS.
I don't know. I use lightdm. It works fine for me. Perhaps it's a bug in Fedora 35 or something is misconfigured on your system. You will need to do some troubleshooting. If lightdm doesn't work for you use gdm, lxdm, kdm, xdm, or one of the myriad other display managers. If you want to use sddm I can confirm the most recent version works on Fedora 36.
I can reproduce your sddm issue with a specific version and point to bugs that show others with other hardware that have experienced the same. I get you're frustrated, but there are several people who have successfully set up Fedora using the instructions here. There is plenty of evidence of that. https://github.com/jmontleon/pixelbook-fedora/issues?q=is%3Aissue
If you dislike or are finding it difficult to troubleshoot on Fedora you can always use Arch or reinstall Chrome OS.
But I'm ON 36
If you're using lightdm look in /var/log/lightdm/lightdm.log. Maybe there is something interesting.
If you're on 36 you should have the updated sddm package. It looks like it was in the actual release. I don't have an answer.
rpm -q sddm
would confirm.
As I said this version works fine for me.
$ rpm -q sddm
sddm-0.19.0^git20220321.e67307e-2.fc36.x86_64
You can also change the default target to multi-user.target and login at the prompt to try and troubleshoot. Start a dm, run startx, and see if your desktop displays...
sudo systemctl set-default multi-user.target
When you're ready to revert sudo systemctl set-default graphical.target
If you're using lightdm look in /var/log/lightdm/lightdm.log. Maybe there is something interesting.
If you're on 36 you should have the updated sddm package. It looks like it was in the actual release. I don't have an answer.
rpm -q sddm
would confirm.As I said this version works fine for me.
$ rpm -q sddm sddm-0.19.0^git20220321.e67307e-2.fc36.x86_64
It's apparently not finding a configuration for Lightdm greeter? And the configuration generation fails.
I have the same version of SDDM you just listed
After running it manually, it's apparently an issue with xcb missing, I'm trying to figure out what needs to be installed here, but I'm not sure.
dnf install libX11-xcb xcb-util
. If it says they're installed maybe dnf reinstall libX11-xcb xcb-util
. Removing it wants to remove a lot of packages including sddm so it should be there.
I don't know why you'd have to reinstall. Can be a symptom of corruption, from shutting down/rebooting during an update, bad disk, or anything in between.
dnf install libX11-xcb xcb-util
. If it says they're installed maybednf reinstall libX11-xcb xcb-util
. Removing it wants to remove a lot of packages including sddm so it should be there.I don't know why you'd have to reinstall. Can be a symptom of corruption, from shutting down/rebooting during an update, bad disk, or anything in between.
https://forum.substance3d.com/index.php?topic=29670.0 apparently it's something to do with libpng15, which was actually missing, and, new behaviour, it starts, but it's completely blank, and I still get the black screen issue where I have to close the lid, let it go to sleep, wake it up, where it stays black, but if I then ctrl + alt + "f#", it will take me to a terminal. So, this hasn't solved the issue at all, and lightdm continues to display the exact same behavior. Let me see if skipping the login screen does anything.
You can also change the default target to multi-user.target and login at the prompt to try and troubleshoot. Start a dm, run startx, and see if your desktop displays...
sudo systemctl set-default multi-user.target
When you're ready to revert
sudo systemctl set-default graphical.target
Exact same behaviour.
After following the instructions for everything, once it reached the login screen, the screen goes black and nothing can be seen.
Edit: seems to be specific to the latest 5.17 kernel Edit2: it seems to be the custom pixelbook kernel