"Green screen of death" upon new install

Fred Barclay · 2016-05-13 18:46:02

No, that seems simple enough. Let me see what happens.

Fred Barclay · 2016-05-13 21:00:24

Wow, that's amazing! I had no idea you could simply copy a kernel from one distro to another!
I booted Arch 10 times on the Debian Jessie backports kernel and it worked perfectly each time.

Here's the diff between the Arch 4.5 kernel and the Jessie backports kernel. It's 3500 lines long so I'm just going to make a cup of tea before I dig in...
https://gist.github.com/Fred-Barclay/dc … ca7bfec690

bstaletic · 2016-05-14 10:02:10

If it is gpu related there are a bunch of fb modules in debian's kernel, but not in arch'. Though I remember reading on the gentoo wiki that those normally should not be used. Still this may be a special case.

If it's not gpu related it myght be easier to just recompile arch' kernel with debian's config. This will be easier to do, but the kernel you get will be slightly larger than the arch' default.

There's one more problem. Are you willing to recompile the kernel every time arch make kernel upgrade available? Considering you're an Arch user (as opposed to being a Gentoo user) I'll assume no. If I'm right you should rename your custom arch kernel and boot that, you can automate this with a custom PKGBUILD which will be needed. When an upgrade comes it will install with the default name and won't make your pc unusable. Basically if you want Arch you'll be recompiling your kernel, how often depends on you. There's one more option - working around pacman. I'd never do this with anything but the kernel. This means doing it Gentoo style and keeping track of the kernel files all by yourself.

Before I go any further pick a solution and ask questions.

Fred Barclay · 2016-05-14 17:11:37

Alright, let's see.

If it is gpu-related, then what?
Do I copy over the fb modules (which won't work in the future unless I keep a Debian install on the same machine)?

If it's not gpu-related:
I'm certainly willing to recompile with debian's config. I don't mind the kernel being slightly larger than the stock Arch kernel--I've got plenty of space on my hard drive if needed. (I'm all for saving disk space but in this case it isn't a worry).

Could you explain more about using a PKGBUILD? What I think you're saying is that I'll need to recompile a kernel, but then I can make a custom PKGBUILD that will do ??? Will it automatically recompile the Arch kernel every time an update comes through pacman? (Sorry for my ignorance!)
Or would I need to ignore the kernel updates through pacman, grab a vanilla kernel from upstream, and compile it myself?

If recompiling will be a frequent task, would I be better off using (and recompiling) the linux-lts kernel? That way, if I understand correctly, I won't be getting kernel updates as frequently. My laptop is prone to overheating so the fewer recompiles needed, the better.
I've also got no reason to prefer the current 4.5 kernel to the lts 4.4 kernel, so using linux-lts isn't any loss to me. As long as I have kernel 3.18 or better (needed for some firejail features) I'm happy.

Thanks! I'd almost given up hope of getting Arch running on this machine.

Last edited by Fred Barclay (2016-05-14 17:12:05)

bstaletic · 2016-05-14 23:35:03

You'll be recompiling no matter what.

If it is gpu related there would be not a lot of things missing from arch kernel so the kernel size would increase by just a few kilobytes. If you don't want to assume anything and just want a kernel that works and don't care about its size the easiest way would be just copying the config. As that config would have different checksums you'll have to update those at the very least but I'd suggest also renaming the package completely. That would make pacman not offer a kernel upgrade - ever. So how do you upgrade your kernel? Just use ABS to fetch a new snapshot of the package and change the PKGBUILD like you would have done the first time. I do think this solution requires the least amount of effort, but requires that you are familiar with "abs", "makepkg" and PKGBUILD editing - which is just a few pages on the wiki.

How often will ou recompile depends only on you. If you want the latest and greatest it will be quite often. Since you do not require the latest kernel just remember to upgrade from time to time - for security reasons (unless you don't care about security )

You can thank me when you make it work without any hackish workarounds.

Fred Barclay · 2016-05-15 04:01:06

No worries, I care about security!

So I did some reading on the wiki about ABS and PKGBUILD editing (I'm already somewhat familiar with "makepkg" but will be reviewing it in a moment), have got abs installed and synced, and a separate build directory set up in /home. So from here it looks like I need to (potentially) edit the PKGBUILD, "makepkg -s", and "pacman -U" it. Right?

I did notice that there are two config files for linux-lts: config and config.x86_64. For which one of these should I substitute the Debian config file? Or, since this is a 64-bit machine, can I just delete "config" and replace "config.x86_64" with the Debian config? (I'm assuming I'll need to rename the Debian config file to "config.x86_64").

I do wonder, since I've (temporarily) chosen to go the linux-lts route (which is kernel 4.4), if using a Debian config for the 4.5 kernel might cause problems? Oh well, only one way to find out!

Cheers, mate!

EDIT: Apparently I don't have to rename the .pkg.tar.xz file after "makepkg -s" if I edit the PKGBUILD correctly.

Last edited by Fred Barclay (2016-05-15 04:02:22)

bstaletic · 2016-05-15 09:08:45

Fred Barclay wrote:

So I did some reading on the wiki about ABS and PKGBUILD editing (I'm already somewhat familiar with "makepkg" but will be reviewing it in a moment), have got abs installed and synced, and a separate build directory set up in /home. So from here it looks like I need to (potentially) edit the PKGBUILD, "makepkg -s", and "pacman -U" it. Right?

Almost. After you replace the config you'll have to run "updatepkgsums" to change what makepkg expects as checksum of the config file.

Fred Barclay wrote:

I did notice that there are two config files for linux-lts: config and config.x86_64. For which one of these should I substitute the Debian config file? Or, since this is a 64-bit machine, can I just delete "config" and replace "config.x86_64" with the Debian config? (I'm assuming I'll need to rename the Debian config file to "config.x86_64").

You can't delete the config file you're not using as it is listed in PKGBUILD and makepkg expects it to be there. Just substitute config.x86_64 with the debian's.

Fred Barclay wrote:

I do wonder, since I've (temporarily) chosen to go the linux-lts route (which is kernel 4.4), if using a Debian config for the 4.5 kernel might cause problems? Oh well, only one way to find out!

Fred Barclay wrote:

EDIT: Apparently I don't have to rename the .pkg.tar.xz file after "makepkg -s" if I edit the PKGBUILD correctly.

There's no need to rename the .pkg.tar.xz file, but you should give it a custom name in the PKGBUILD. There is a line near the top of the PKGBUILD that says something like "_basename=arch", change it's walue to tell makepkg to not name it as the original package.

Fred Barclay · 2016-05-15 18:48:04

bstaletic wrote:

Almost. After you replace the config you'll have to run "updatepkgsums" to change what makepkg expects as checksum of the config file.

My system says that "updatepkgsums" isn't a valid command. I searched the Arch wiki too and couldn't find any info on it.
It looks like I could pretty easily edit the PKGBUILD with the correct sha256sum of config.x86_64 so it isn't a big deal.

On the other hand, I kept getting an error on "makepkg -s" when checking the GPG sigs:

==> Verifying source file signatures with gpg...
    linux-4.4.tar ... FAILED (unknown public key 79BE3E4300411886
    patch-4.4.10 ... FAILED (unknown public key 38DBBDC86092693E
==> ERROR: One or more PGP signatures could not be verified!

I went ahead and ran with the --skippgpcheck flag, after which the computer eventually overheated and shut down. (I can probably work around overheating, though--I found a rather noisy method. ). But obviously when I get beyond the testing stage I'm not going to ignore the PGP sigs. What should I do?
The PKGBUILD automatically checks for Torvald's and Kroah-Hartman's keys:

validpgpkeys=('ABAF11C65A2970B130ABE3C479BE3E4300411886' # Linus Torvalds <torvalds@linux-foundation.org>
'647F28654894E3BD457199BE38DBBDC86092693E' # Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>
)

Do I just need to import the keys from a keyserver?

Last edited by Fred Barclay (2016-05-15 18:48:53)

bstaletic · 2016-05-15 20:05:50

Fred Barclay wrote:

My system says that "updatepkgsums" isn't a valid command. I searched the Arch wiki too and couldn't find any info on it.
looks like I could pretty easily edit the PKGBUILD with the correct sha256sum of config.x86_64 so it isn't a big deal.

I probably do not remember the exact name of the command. It should be installed with pacman. Try

pacman -Ql pacman | grep bin

to list every binary that came with pacman. There's also a makepkg flag that can help you in updating sums in the PKGBUILD, I ust don't remember what is it called.

Fred Barclay wrote:

On the other hand, I kept getting an error on "makepkg -s" when checking the GPG sigs:
==> Verifying source file signatures with gpg...
    linux-4.4.tar ... FAILED (unknown public key 79BE3E4300411886
    patch-4.4.10 ... FAILED (unknown public key 38DBBDC86092693E
==> ERROR: One or more PGP signatures could not be verified!
I went ahead and ran with the --skippgpcheck flag, after which the computer eventually overheated and shut down. (I can probably work around overheating, though--I found a rather noisy method. ). But obviously when I get beyond the testing stage I'm not going to ignore the PGP sigs. What should I do?
The PKGBUILD automatically checks for Torvald's and Kroah-Hartman's keys:
validpgpkeys=('ABAF11C65A2970B130ABE3C479BE3E4300411886' # Linus Torvalds <torvalds@linux-foundation.org>
'647F28654894E3BD457199BE38DBBDC86092693E' # Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>
)
Do I just need to import the keys from a keyserver?

Just run "gpg --recv-keys" with the keys as the argument. If it is not enough you can locally sign the keys using "gpg --lsign-key". You can find a bit more about this on the wiki or a lot more on Alan's blog.

Oh... the solution to the overheating problem, on a scale from old vacuum cleaner to jet engine how noisy is it?

Fred Barclay · 2016-05-15 23:45:36

Okay, I'll be looking for the command and importing the keys.

The overheating "solution" involves taking the back off the laptop (which is usually off anyways), flipping the laptop upside down, and putting a 25-cm fan on medium speed directly on top. How's that for a hackish workaround?
Of course, I can't see the screen or type on the keyboard while doing this, so I really don't like it.

Last edited by Fred Barclay (2016-05-15 23:46:02)

Lone_Wolf · 2016-05-16 12:26:42

My system says that "updatepkgsums" isn't a valid command.

The command is updpkgsums .

Fred Barclay · 2016-05-17 03:17:49

Thanks, Lone_Wolf.

Okay, so I've edited the PKGBUILD and will be compiling my customised kernel in a bit.

I went ahead and had a practice compile with the Liquorix kernel (linux-lqx in the AUR) as I'd had some experience with that kernel while on Debian. 4.5 hours later(!) it finished compiling and I installed--I got a couple good boots out of it but ultimately it reverted to the same green/frozen screen.
I could probably have sped the compile up by editing /etc/makepkg.conf but I was worried about overheating the processor. Would have been a bummer to have the machine overheat 15 minutes from finishing the compile!

Last edited by Fred Barclay (2016-05-17 03:18:11)

Fred Barclay · 2016-05-19 19:49:44

Hey guys--just a quick update. I've had a few unexpected things happen that have kept my busy so I haven't been able to compile and test yet, but I will as soon as I get the time. I just didn't want you to think that I'd abandoned the thread.
Cheers!

Fred Barclay · 2016-06-03 21:34:29

I still haven't had time to compile the kernel but it looks like I might be able to in the next few days.

However, I've also found something interesting. I removed plymouth from my LMDE Betsy install (the one on this same machine that boots kernel 4.5 just fine) and sure enough, I started getting freezing and the green screen at boot. I reinstalled plymouth and the problem disappeared.

I was doing some reading on the Arch wiki and it appears that plymouth interacts with KMS? If so, I may try and install plymouth here before compiling and seeing if that changes anything. That is, unless it's a horrid idea for some reason I don't know yet?

After reading the AUR page and the Fedora wiki it appears that plymouth doesn't even require X, so I should be able to deploy and test pretty quickly.
https://fedoraproject.org/wiki/Features … terStartup

Last edited by Fred Barclay (2016-06-03 21:41:10)

bstaletic · 2016-06-04 07:55:08

Nothing bad about testing out plymouth. Tough, I neverused it, so I have no idea what does it do.

Fred Barclay · 2016-06-15 21:59:37

Not exactly the update I wanted to give...

Plymouth accomplished exactly nothing. I got a couple of good boots before the familiar green screen stared back at me.

I've also been having some troubles in LMDE Betsy and tracked it down to the backported kernel. I'm back on 3.16 and it looks like a kernel from the 4.x series will not be an option on this machine regardless of distro. If I were to get the greenscreen worked out on Arch something else will likely crop up and so on ad infinitum.

I know some Arch-centric distros (like Manjaro) offer kernels from the 3.x series. Does Arch do the same? I looked on the wiki page but it didn't say anything about it.
I could always compile 3.16 from upstream, but as I mentioned earlier this computer will overheat in a matter of minutes if I don't have something rigged up (which is usually not an option). I'd much prefer a "pacman -S" approach.

On the positive side, I tracked down some new hardware (literally dumpster-diving... it's a long story ) so I might be able to get Arch on that machine in the future. I sure hope so... I miss Arch!

Last edited by Fred Barclay (2016-06-15 22:01:14)

Lone_Wolf · 2016-06-16 14:22:58

I know some Arch-centric distros (like Manjaro) offer kernels from the 3.x series. Does Arch do the same?

clfarron4 seems to maintain a repo with older kernels (x86_64 only) , check https://bbs.archlinux.org/viewtopic.php?id=187339 .

Fred Barclay · 2016-07-09 16:16:14

Sorry this is so late--my life's had some unexpected twists (partly medical) so I haven't been able to check back in till now.

That repo looks promising, but I'm afraid I'm going to have to wait until clfarron4 finds a new hosting service and begins updating the builds again. But my machine is x86_64 so that's definitely a good find. Thanks Lone_Wolf!

Arch Linux

#26 2016-05-13 18:46:02

Re: "Green screen of death" upon new install

#27 2016-05-13 21:00:24

Re: "Green screen of death" upon new install

#28 2016-05-14 10:02:10

Re: "Green screen of death" upon new install

#29 2016-05-14 17:11:37

Re: "Green screen of death" upon new install

#30 2016-05-14 23:35:03

Re: "Green screen of death" upon new install

#31 2016-05-15 04:01:06

Re: "Green screen of death" upon new install

#32 2016-05-15 09:08:45

Re: "Green screen of death" upon new install

#33 2016-05-15 18:48:04

Re: "Green screen of death" upon new install

#34 2016-05-15 20:05:50

Re: "Green screen of death" upon new install

#35 2016-05-15 23:45:36

Re: "Green screen of death" upon new install

#36 2016-05-16 12:26:42

Re: "Green screen of death" upon new install

#37 2016-05-17 03:17:49

Re: "Green screen of death" upon new install

#38 2016-05-19 19:49:44

Re: "Green screen of death" upon new install

#39 2016-06-03 21:34:29

Re: "Green screen of death" upon new install

#40 2016-06-04 07:55:08

Re: "Green screen of death" upon new install

#41 2016-06-15 21:59:37

Re: "Green screen of death" upon new install

#42 2016-06-16 14:22:58

Re: "Green screen of death" upon new install

#43 2016-07-09 16:16:14

Re: "Green screen of death" upon new install

Board footer