Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux

New Linux 'Screen of Death' Options: Black - or a Monochrome Tux Logo (phoronix.com) 49

Posted by EditorDavid from the penguin-power dept.
It was analgous to the "Blue Screen of Death" that Windows gives for critical errors, Phoronix wrote. To enable error messages for things like a kernel panic, Linux 6.10 introduced a new panic handler infrastructure for "Direct Rendering Manager" (or DRM) drivers.

Phoronix also published a follow-up from Red Hat engineer Javier Martinez Canillas (who was involved in the new DRM Panic infrastructure). Given complaints about being too like Microsoft Windows following his recent Linux "Blue Screen of Death" showcase... Javier showed that a black screen of death is possible if so desired... After all, it's all open-source and thus can customize to your heart's content.
And now the panic handler is getting even more new features, Phoronix reported Friday: With the code in Linux 6.10 when DRM Panic is triggered, an ASCII art version of Linux's mascot, Tux the penguin, is rendered as part of the display. With Linux 6.11 it will also be able to handle displaying a monochrome image as the logo.

If ASCII art on error messages doesn't satisfy your tastes in 2024+, the DRM Panic code will be able to support a monochrome graphical logo that leverages the Linux kernel's boot-up logo support. The ASCII art penguin will still be used when no graphical logo is found or when the existing "LOGO" Kconfig option is disabled. (Those Tux logo assets being here.)

This monochrome logo support in the DRM Panic handler was sent out as part of this week's drm-misc-next pull request ahead of the Linux 6.11 merge window in July. This week's drm-misc-next material also includes TTM memory management improvements, various fixes to the smaller Direct Rendering Manager drivers, and also the previously talked about monochrome TV support for the Raspberry Pi.
Long-time Slashdot reader unixbhaskar thinks the new option "will certainly satisfy the modern people... But it is not as eye candy as people think... Moreover, it is monochrome, so certainly not resource-hungry. Plus, if all else fails, the ASCII art logo is still there to show!"
This discussion has been archived. No new comments can be posted.

New Linux 'Screen of Death' Options: Black - or a Monochrome Tux Logo More

New Linux 'Screen of Death' Options: Black - or a Monochrome Tux Logo

Comments Filter:

  • What if I want (Score:3)

    by Revek ( 133289 ) on Sunday June 30, 2024 @10:41AM (#64590015)
    I want a slow soothing rainbow color shift Going through 256 colors or even more.

  • ... on something people rarely see.

    • Something I've *never* seen in my life. 99% of linux computers are servers and have no screen.

      Saving logs, dumping core to disk, and rebooting - today's behavior - seems far far more useful than sticking on some static screen, no matter what color it is.

      • I've seen a lot of kernel panics in my day, but my first kernel was 1.1.47 and I've built a lot of them myself. Not so much in recent days of course, it's a bigger PITA than ever and I have less reason to do so than ever, but once upon a time it was basically mandatory. I had to do it just to get support for some of my hardware.

        I haven't had a Linux system hang or reboot unexpectedly in years. The last time I had one fail it was the motherboard dying.

      • "Latest Linux statistics show that 2.68% of desktop PCs and laptops worldwide run on this platform." - https://truelist.co/blog/linux... [truelist.co] (February, 17, 2024)

      • Re: (Score:2)

        by ls671 ( 1122017 )

        Something I've *never* seen in my life. 99% of linux computers are servers and have no screen.

        Saving logs, dumping core to disk, and rebooting - today's behavior - seems far far more useful than sticking on some static screen, no matter what color it is.

        I use netconsole on servers so if a server crashes, the console content is logged to a remote syslogd:
        https://www.kernel.org/doc/htm... [kernel.org]

        works 99% of the time...

    • Re: (Score:2, Interesting)

      by Ol Olsoc ( 1175323 )

      ... on something people rarely see.

      That's what I thought. I get BSODs on Windows pretty often, and in the almost 20 years I've used Linux daily, have not seen a kernel panic once.

      • Re:Spending a lot of time ... (Score:4, Interesting)

        by thegarbz ( 1787294 ) on Sunday June 30, 2024 @12:32PM (#64590225)

        I get BSODs on Windows pretty often

        Did you break your OS, or do you have a hardware problem?

        I have seen 3 BSODs on Windows in the past decade, and all three were the result of a hardware problem. Incidentally I've seen a Linux Kernel Panic as well, also a hardware problem.

        If you see any of this "often" you need to fix your broken shit because that is not normal.

        • I get BSODs on Windows pretty often

          Did you break your OS, or do you have a hardware problem?

          I have seen 3 BSODs on Windows in the past decade, and all three were the result of a hardware problem. Incidentally I've seen a Linux Kernel Panic as well, also a hardware problem.

          If you see any of this "often" you need to fix your broken shit because that is not normal.

          Usually a software based problem. Often after an update. I use a lot of different software. And test new software as well. Is it the hardware? I dunno - could be, but probably not. But it happens on Windows. Not on Linux, and not on MacOS. I only report my experience.

      • You're not seeing it often because you're not doing driver development, and/or don't have intermittently failing hardware.

        BITD we would see kernel panics from kernel bugs, because Linux was in earlier phases of development. They would be more common with "development series" kernels (versions x.odd were such, while x.even were release kernels) and were commonly in drivers, just as drivers have commonly been the cause of BSODs in Windows. We would often run development series kernels despite not being intend

      • Don't use crap hardware with crap drivers. Last time I saw a BSOD was about 7 years ago, and that was caused by my sound card.

        • Don't use crap hardware with crap drivers. Last time I saw a BSOD was about 7 years ago, and that was caused by my sound card.

          Here's the problem with the BSOD means you are using bad hardware and bad drivers notion. Once functioning hardware BSODs after an update.

          As an example, I had a couple machines that after a BOHICA update went into an infinite feedback loop. DDG "Windows infinite BSOD loop" or "Windows infinite BSOD loop after update".

          How does one tell that they have crap hardware and drivers is they installed the software and it works flawlessly, then an update reveals that not only do they have bad hardware, and softw

    • ... on something people rarely see.

      Firstly you're begging the question. There's not "a lot of time" spent on this. Secondly you're missing the point. We need to spend time on things we rarely see because those things are the hardest problems to resolve. Having the ability to display an error code even if errors are rare is insanely critical, which is why Kernel Panics were a function of the earliest OSes back in the 1970s.

      • nope (Score:3, Interesting)

        by Anonymous Coward

        Lord I can't believe the drive to prove someone wrong on the internet drove me to dig up this quote but here we go.

        I [Tom Van Vleck, a Multics engineer] was working for MIT in those days, and one thing I did was to organize an MIT PDP-11 users' group and encourage them to look into Unix. The idea of a free, non-vendor-supported operating system was new to them. I invited Dennis Ritchie to come up and talk to them. We went to lunch afterward, and I remarked to Dennis that easily half the code I was writing

  • Who really cares about this kind of stuff! (Score:4, Insightful)

    by oldgraybeard ( 2939809 ) on Sunday June 30, 2024 @11:01AM (#64590055)
    Just display the technical info and go work on something meaningful!

    • It's Open Source, so you first.

      • This is Red Hat, so it's more like "Open" Source (for sufficiently loose definitions of "Open").

      • It's Open Source, so you first.

        That's completely irrelevant. Any competent software engineer knows that the number of vulnerabilities, and the number of bugs, grows with the size of the codebase. When a piece of software is intended to be used by billions of users, and I mean reliably, you don't fill it with frivolous cruft like this.

        TL;DR. The panic handler infrastructure probably has at least 1 bug, and 1 security vulnerability *right now*. Since it's not doing anything important, it should be taken o

    • If previously the kernel panics with the kernel is in DRM graphics mode (which is necessary for wayland) could not display text, then it was difficult to debug certain panics. So they developed this framework so the kernel panics become useful. It's a very meaningful work. It's not the additional printf("ascii tux\n") or loadimage("tux.png") and that took them time.

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        It's also a friendly notice to the user that something critical happened and the only way to recover is to reboot their PC.

        Our workplace runs a lot of Linux. Far too many people are on Slack asking people to reboot their PCs because they've hung overnight. Why? Who knows, because the monitor is displaying the graphical login window.

        Sometimes it's nice to know if it's hardware failing (which means we need to replace the PC) or if it's a software fault. Instead we wait for the user to get fed up with rebootin

    • Re: (Score:2)

      by DarkOx ( 621550 )

      To some degree that is what they are trying to do. A lot of machines have a display but don't have a 'con0' that works on it. The point here is to make it possible for you to see the errors in this instance. No just logging to disk and stopping or rebooting is the the right model all the time.

      Its a bad fit for consumer oriented embedded devices for example. I am not pulling the logs from my fridge before I call support. Ideally I'd see enough about what is wrong that they can send a tech out with what a

  • Guru Mediation (Score:3)

    by 4wdloop ( 1031398 ) on Sunday June 30, 2024 @11:13AM (#64590073)

    https://en.wikipedia.org/wiki/... [wikipedia.org]

  • an MS dig (Score:5, Funny)

    by Tablizer ( 95088 ) on Sunday June 30, 2024 @11:25AM (#64590105) Journal

    How about Tux doing a face-palm with a blurb saying, "Shit, I feel so like MS-Windows right now. Vodka time."

  • Instead of fixing actual Linux problems which allows Microsoft to get away with MS accounts and telemetry.

    • Re: (Score:2, Insightful)

      by thegarbz ( 1787294 )

      The biggest problem with Linux is people like you who think there are one group of Linux developers who should focus on whatever your pet peeve is. I'm curious what your problem is that needs fixing, and why you think (because it almost certainly won't be) that it should be addressed by the team working on and maintaining the DRM drivers.

  • over a decade ago in my tinkering infatuation i would build my own kernel (and i kept notes) and a few times i would get a fail on boot because of something stupid like once i forgot to copy over the new initrd.gz file too along with vmlinuz or similarly everything gets copied over but i did not run the command correctly to update the configuration and a module didnt load, so it was my own fault, nowadays i just use the kernel that comes with the distribution

  • Hmmm. (Score:4, Insightful)

    by jd ( 1658 ) <imipak AT yahoo DOT com> on Sunday June 30, 2024 @01:21PM (#64590349) Homepage Journal

    Wouldn't better recovery procedures be more useful?

    Since this is likely going to he triggered by a driver bug, and Linux supports not just driver unloading, but also access control to restrict which group of applications can use which functions on which piece of hardware, there's no obvious reason why defective drivers can't be failed safely with access then buggy featured restricted to root or a service account to allow proper diagnostic testing and evaluation.

    Users will always be able to get much more useful information out of a crash situation than a preprogrammed generic response that has to work the same way for everything.

  • "Direct Rendering Manager" (or DRM) drivers

    More acronym confusion -- thanks.

  • I guess that if I ever see this Screen of Death, it will be in a particular shade of blue, in accordance to my distro's colour palette.
  • I predict the call I will get from Grandpa for computer help will be something about how a Penguin keeps telling him to reboot. What?..Grandpa? What are you trying to do?

  • A dead penguin rendered in ASCII, followed by the error code and references to the appropriate log files

  • I always thought a "DRM panic" was when a Slashdot story mentioned the Direct Rendering Module by its initialism and then half the thread consisted of people panicking about Linux having DRM!

  • Why not just print the normal kernel panic message and leave out all the rest?

  • Do what you want for critical error messages, just make sure the cuteness doesn't interfere with error reporting. I don't expect to see a whole lot of them, and if I do, them being silly or excessively flashy is the least of my problems.

    • I expect my error messages to have a full screen grotesque clown face and horrifying carnival music sounding like it's coming from the end of a 1 mile long tunnel.

      • Re: (Score:3)

        by Mal-2 ( 675116 )

        Well yes, I expect it will be accompanied by vaporwaved accordion covers of Tom Waits songs.

  • Just what we need. More features for the kernel panic handler. Perhaps some work avoiding kernel panics would be more helpful.

Slashdot Top Deals

You are in a maze of little twisting passages, all different.

Close