Main » Discussion » (Mis)adventures on Debian ((old)stable|testing|aghmyballs) » New reply
    New reply
    Post help

    Presentation

    [b]…[/b] — bold type
    [i]…[/i] — italic
    [u]…[/u] — underlined
    [s]…[/s] — strikethrough
    [code]…[/code] — code block
    [spoiler]…[/spoiler] — spoiler block
    [spoiler=…]…[/spoiler]
    [source]…[/source] — colorcoded block, assuming C#
    [source=…]…[/source] — colorcoded block, specific language[which?]
    [abbr=…]…[/abbr] — abbreviation
    [color=…]…[/color] — set text color
    [jest]…[/jest] — you're kidding
    [sarcasm]…[/sarcasm] — you're not kidding

    Links

    [img]http://…[/img] — insert image
    [url]http://…[/url]
    [url=http://…]…[/url]
    >>… — link to post by ID
    [user=##] — link to user's profile by ID

    Quotations

    [quote]…[/quote] — untitled quote
    [quote=…]…[/quote] — "Posted by …"
    [quote="…" id="…"]…[/quote] — ""Post by …" with link by post ID

    Embeds

    [youtube]…[/youtube] — video ID only please
    Thread review
    tomman TVs have never been good monitors anyway. And I also have no room for anything over 27" on my current setup! (Now I wonder what are the options for those that need a small TV - 15 years ago you could just and buy a 14" CRT or -if your budget was generous- a 15" LCD that would fit even at the tightest of the college dorms)
    But then, given that this display is to be used sporadically only, then 24" is more than enough for me. I'm more worried about the general disregard towards build quality across the board: those Apple-thiiiiin bezel-less designs just scream "I'M GONNA BREAK if you dare touching me!".

    I do not recommend those Aiwas either - the first one I got only lasted 3 hours at home before I was returning it to the store due to a small cluster of 9 dark pixels with obvious manufacturing damage. And the replacement came with a bright spot near the bottom bezel whose brightness varies a lot (between "not there" and "who is shining a LED from behind!?") depending on the scene! On the flip side:
    - It has 3 inputs: HDMI, DP, and VGA
    - It has an audio output jack for HDMI audio
    - It supports Freesync
    - The next cheapest display was a Samsung that costed $25 more, lacks DP/audio output/Freesync, and looked even more fragile! (The idea here was also to futureproof my investment as much as possible)
    - Every other display on local stores were $50-100 more expensive, even for obviously trashy Chinese brands!

    Sadly I had a tight budget, a small timeframe to get the deal done (yay inflation~), and I really needed the display (plus refurbs were about the same price because Venezuela became Bizarroland for any kind of appliance that isn't a cellphone).

    Fun fact: the UVD HW video decoder on this Radeon HD2600 not only needs DPM to be turned off, it also needs some warmup (especially when using the DVI/HDMI outputs) - the first few seconds of playback WILL be janky, and there is a risk of the card hanging up if you try to do anything funny, but after that it will be stable... until the next reboot.
    creaothceann
    Posted by tomman
    TVs are cheaper, but they're also impossible to find in any size under 32", and very difficult to get without the Android pest

    Back in 2018 I got myself a Sharp Aquos LC-48CFE4042E, specifically because it wasn't a 'smart' TV.
    (But even if a TV lacks Google's version of Android it could be a worse OS...)

    EDIT: Speaking of sizes, my PC is on a 31.5" display. And while I want to upgrade in the future to an OLED (or better) screen, going down from that size wouldn't fill me with joy. You get very used to it.
    tomman EDID shenanigans time~!

    Managed to save enough monies to buy a shiny new computer monitor for the vintage Thinkcentre: an 24" Aiwa AW24FHDM4 (actually not made or even designed by Aiwa, but by some Chinesium OEM named "ChangHong Electric" according to the EDID manufacturer code). Not exactly cheap, but computer displays are difficult to find in this city at any reasonable price... or size (as much as I hate widescreens, I must face the facts: 4:3/5:4 displays are ticking timebombs with those aging CCFLs, and LED-backlit models are made of unobtanium. And yes, TVs are cheaper, but they're also impossible to find in any size under 32", and very difficult to get without the Android pest). This display has the neat feature of having triple inputs: VGA, DisplayPort, and HDMI, which means I'm futureproof'd for now, regarding wired connectivity.

    And here comes my pain: this is a 75Hz 1080p panel, and my Radeon HD2600 is HD capable, right? RIGHT!? Not quite: after a initial attemmpt via a DVI-to-HDMI adapter, I could see the early boot messages, but as soon as KMS kicked in, all video would be gone. Blackness. Flying blind. No, the computer wasn't hanging - it was still reachable over SSH, and after checking around, I found what was happening: the default video mode over HDMI is indeed 75Hz, but this ancient Radeon simply can't deliver 75 full HD frames per second, not for money, not for love. It pretends it can, but it silently drops dead. Now, if I use xrandr to select the 1080p60 mode, video springs back to life! And if I boot with "video=1920x1080@60", I also get KMS consoles too.

    Fun fact: over VGA, the monitor reports that its preferred mode is 1080p60, but of course I haven't splurged $MONEY just to waste 2/3rds of the connectivity! Something had to be done:

    - video= boot parameter helps with consoles, not with Xorg (let's pretend Wayland never existed for the purpose of this exercise).
    - xrandr helps with Xorg if you tack it somewhere in your X session scripts... but only after somehow I manage to logon (this machine is setup for autologon from lightdm, except that it sometimes fails). Quite hard to logon on a dead display...
    - Forcing refresh rates on Xorg config files involves modeline fuckery. No. Just. NO.
    - You know where this is going: it's time for EDID shenanigans~!


    In the past, messing with broken EDIDs have been a endless source of pain and sorrow for me. From finding a non-broken editor to understanding the format of its extensions to shoving down Linux kernel's throat my haxx blob, this has never ended well for me. But this time I had no option....

    - Dump your EDID by reading it from /sys/class/drm/card0-$OUTPUTNAME/edid. Don't bother with get-edid and friends, they're largely relics from the past these days and won't really work with modern-ish hardware anymore.

    - For editing the EDID, the only option in town for Linux is wxEDID, except that this HDMI display exposes the 75Hz mode over CTA-861 DTDs, something that wxEDID fails to parse and that won't let me edit anyway. And every single other EDID editor in existence requires Windows 10 these days, or fails to work with Wine. Ended tracking an archived copy of Analog Devices' EEditGold, which refused to install on XP but ran fine on 7, although opening my dumped EDID on it had a gotcha (you must IMPORT, not directly OPEN it). After fixing the DTD block to pretend 75Hz never existed, I exported my fixed EDID and got it back into my IBM box.

    - To get Linux to load your haxx EDID, Arch wiki has the answer (as usual). Except that while this fixes X11, it does nothing for KMS consoles because Debian uses early KMS by default, and during that phase your root filesystem is NOT mounted yet! Solution? Get your EDID blob into your initramfs image. Sounds easy? NOT! I found this guide for Ubuntu, but the suggested hook script makes some stupid assumptions like that your EDIDs live at the root of /lib/firmware/, and not at the suggested place which is /lib/firmware/edid/. Ended getting this script down to its most barebones possible version:
    #!/bin/sh
    # Copy local EDID monitor description data

    PREREQ=""
    prereqs()
    {
    echo "$PREREQ"
    }

    case $1 in
    prereqs)
    prereqs
    exit 0
    ;;
    esac

    . /usr/share/initramfs-tools/hook-functions

    EDID_DATA="edid/AW_EDID_HDMI_R600compat.bin"

    add_firmware "$EDID_DATA"

    exit 0

    ...and it actually copied my haxx EDID~!

    - Oh, remember that the input names you need to use for drm.edid_firmware= are the ones reported by the DRM driver, not by xrandr! In my case, since my DVI-to-HDMI adapter is attached to the secondary DVI port, the port name i need to use is "DVI-I-2", not "DVI-1". Again, you can get those names from under /sys/class/drm/.

    A couple reboots later to ensure that my edits were sticking and working, and I finally got flawless 1080p60, partying like if it is 2008 again!

    ...or you can simply plug this thing to a modern GPU, but where is the fun on that?
    tomman I should have caught this earlier, but didn't because the Linux world keeps giving me material to rant 'till death does its part: do NOT use modern distros on old GPUs, as hardware acceleration features on those are getting nuked left and right!

    I was trying to run some Ren'Py-based VNs on my T40 under Debian Bookworm, when suddenly I notice things are more than laggy. Stuff would run but... performance would be AWFUL. Dicking around, turned out I didn't had any 3D acceleration whatsoever on this thing anymore! After some investigation, found why: Mesa had deprecated more vintage GPU drivers, including R100, R200, i915, i965, and some early Nouveau stuff. Those drivers didn't got nuked right away - instead, starting with release 21.3, Mesa punted them to a new branch named mesa-amber, which can be installed separately on top of whatever Mesa your distro ships as they can coexist side by side. OK, not bad, let's try them...

    First catch: Debian is not shipping this yet despite being a ITP for it due to the usual Nedflanderist puritanical licensing BS that nobody but Debian package Nedflanderist puritanicals care. Ubuntu does ship mesa-amber, but they killed i386 years ago so I can't use that. Fortunately we have properly Debianized sources, so let's build me some .DEBs! Since I'm lazy for setting up a i386 chroot here, I used my ole' Thinkcentre M50 and its totes powerful Northwood to build those packages. Several hours later, I was greeted with this:


    ...wtf Mesa, are you shitting on my parade? Because you are shitting on my parade, that is!

    OK, so mesa-amber is borked, and with no hopes for getting this fixed upstream (they're not doing serious maintenance on that branch, other than the rare compiler bugfix), this means I need to check out older Mesa versions. I'll spare you the gory details (building Mesa .DEBs involves fishing out dozens of patches because half of Mesa's changelog is "LLVM/Clang changed things AGAIN so compiler fixes LOL", one or two segfaults down the road, also did I mention that Northwoods are awesome builders?), but those were my results:

    - Mesa 22.3 + mesa-amber: Broken 3D.
    - Mesa 21.3: Broken 3D.
    - Mesa 20.3 (the one shipped with Bullseye): 3D works OK!

    So... uh, yeah, this means I'm not updating this T40 to any future Debian release just because of the GPU drivers. And now I realized that the one thing that is killing my fleet at home with modern Linux is Mesa breaking older GPUs, nothing else! Can't wait for Wayland to turn all of my computers into paperweights because I commited the heinous crime of living in a commie wasteland without access to last month AMD/nVidia product launches!

    Time to retire the "Linux gives a new lease in life to older computers" motto, because it's no longer valid. At this point, either stick to old Linux releases you can't probably install anymore because the repos have been shutdown or archived for ages, or just stick to Windows :/

    Spoilers: I couldn't run those Ren'Py titles anyway - it can now find a hardware renderer, but will fallback instead to software mode because OpenGL 1.3 is too oooooooold for a dumb visual novel engine where apparently drawing static CGs and text has the same hardware requirements as the original Portal!

    Yes, I'm more pissed off than usual when writing this.

    UPDATE: Turns out mesa-amber isn't completely useless: while glxgears is broken, sm64ex actually renders more or less fine!

    Ironically, I got the same bugs on both Mesa 20.3 and mesa-amber, so I guess the level of bitrot on the ol' R100 GL drivers is uneven. We really need a crowdfunding initiative to give some love to those vintage GPUs, but alas, noone that can code is interested beceuse those GPUs are either not on a Mac, or not old enough!
    wertigon
    Posted by tomman

    5) Stuff like Lutris overcomplicates things - I've seen stuff so overengineered that it would be almost like installing Docker to run games, seriously.


    Welcome to the future where each legacy game will be run in a Linux VM with bare minimals to get Wine running. It's only 300-400 MB overhead for a game, not even enough to fill a single CD ROM. All because Microsoft in their infinite wisdom thought forever binary compatibility is the way things should work. :D
    tomman Two quickies:

    1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052690 - that's what's happening after installing the latest GRUB2 security update and noticing that your Windows boot entries are gone, even after enforcing GRUB_DISABLE_OS_PROBER=false... because some postinstall script has braindamaged logic and will comment that setting without even warning you first!

    2) https://appdb.winehq.org/objectManager.php?sClass=version&iId=22830 For the first time in almost 20 years, Wine's DirectMusic implementation DOES SOMETHING! Enough to let Recettear have sounds, and even some music without resorting to winetricks and native DLL overrides. It's still quite rough (background music won't loop, for example), but you will want to update to wine-devel 8.18 anyway.
    tomman Stuff I've learned in the last ~18 hours after trying to run games that play videos (especially Japanese ones) on Wine:

    1) You don't need to install codec packs anymore on Wine - these days it relies on GStreamer for that, so you need to install a few i386 GStreamer packages (including gstreamer1.0-libav). The problem these days is not codecs, but renderers - you may or may not need (or even want) native quartz.dll, depending on how picky is the game.

    2) Do not mix native and builtin quartz.dll and dsound.dll - at best you will only get nasty audio glitching, at worst, things will get crashy-crashy and not lovey-dovey.

    3) If your game uses DirectMusic (THAT'S WITH YOU RECETTEAR!!!), abandon all hope. While Wine recently started to work again on actually implementing this ancient music synth API (long deprecated and forgotten by MS since Vista), the support for now is unusable. Use Winetricks to install DirectMusic (which also brings native dshow.dll, since it won't work otherwise). Oh, and don't expect to have both DirectMusic and non-DirectMusic sounds working on the same application! (In other words: kiss that OP movie goodbye)

    4) If you're lucky, your game (or VN) will work fine out of the box on a new, clean Wine prefix without any overrides. But Japanese developers can barely make games that work on regular Windows PCs sold in Japan, so expect this to be the exception, not the rule. Wine's target is modern Western games, mostly - far more kids care about playing CoD than your niche bullet hell game, and that's where the efforts are aimed to.

    5) Stuff like Lutris overcomplicates things - I've seen stuff so overengineered that it would be almost like installing Docker to run games, seriously. And Proton does not spark joy on me, sorry.

    6) Wine has an up to date repo for Debian, so use that one instead of the old crusty packages of stable. Their packages are well behaved citizens and will be installed under /opt, while being properly integrated with your Debian box.

    7) Get used to the idea of razing and rebuilding your $WINEPREFIX from scratch every few years - we're dealing with Windows-y things, after all.
    wertigon
    Posted by tomman
    PulseAudio is dead and buried, say hello to the new king of loud penguins, Pipewire!

    If you just upgraded to Bookworm and were using Pulse, you're now already on Pipewire through pipewire-pulse, and most likely you haven't really noticed. THIS is the kind of progress I like - do your goddamned job behind the scenario without anyone ever being aware of your existence! Bravo, Pipewire, you've achieved in a few years what the Pulse folks took almost half a decade to achieve.


    Pipewire is even better than you think - Basically, Pipewire is a stream router. It can stream any type of content, video, audio, text, pr0n, anime, emulation, input devices, sensory devices et cetera... All it does is keep track of which sources go to which sinks.

    And yes, the sink may be anything from a screen to a keyboard to a network interface. Pipewire is simply amazing, especially for low latency communication. Windows and Mac ain't got nuthin on the potential of this baby...
    tomman PulseAudio is dead and buried, say hello to the new king of loud penguins, Pipewire!

    If you just upgraded to Bookworm and were using Pulse, you're now already on Pipewire through pipewire-pulse, and most likely you haven't really noticed. THIS is the kind of progress I like - do your goddamned job behind the scenario without anyone ever being aware of your existence! Bravo, Pipewire, you've achieved in a few years what the Pulse folks took almost half a decade to achieve.

    But the job is not complete - your few ALSA-only games are in YO DAWG mode going through Pulseaudio bridges, and those are being bridged to Pipewire. This is insanity, and the solution is to apt-get install pipewire-alsa, let it nuke the remnants of Pulseaudio, reboot, and hope the house of cards that is the Linux audio jungle doesn't fall apart again in 10 years when some Forward Pushers of Things come up with Yet Another Audio API™.

    Side casualty: projectm-pulseaudio is dead, and the visualizations of Easy Effects (OH GOD, THIS SHIT LOOKS SO IPHONE IT HURTS!) are lame.
    tomman Bought a not-so-cheap USB LAN adapter for the DSL on the routerbox, since dual-port PCI NICs are unobtanium in this country. While I figure out how to configure dual-WAN failover on this thing, getting this horrendously common USB gadget to work properly came with a snag: my adapter uses an ASIX AX88179 USB-Ethernet chipset, which claims to be "driverless" on modern Windows versions (it is not RNDIS, tho), and on Linux it uses some common CDC drivers plus some AX88179-specific bits. Turns out there is a strict loading order of all those pieces of the puzzle, or you will end with this: https://github.com/FreddyXin/ax88179_178a/issues/6

    The workaround is simple, but you gotta be careful - not many users bother checking the kernel logs when deploying some shiny new piece of hardware, and then wonder why stuff works poorly!

    (FWIW, it seems to be finally fixed on kernel 6.1 - plugging the same adapter to any of my Bookworm hosts load the drivers in the correct order)
    tomman After imaging (and verifying!) the Asus, I've decided it's time to give up VLC, the Fermi dGPU, and move on with the Bookworm update. Of course, I fell into a completely unexpected set of pitfalls this time, but as usual, victory was achieved:

    - Upgrade failed halfway because of some long forgotten (self-built) mGBA .DEB. apt-get --fix-broken dist-upgrade was enough to give a push for the process to continue.

    - libdvdcss is installed these days via libdvd-pkg because the DVD CCA goons are still willing to sue people over distribution of DVD players that haven't paid the bribe for a weak crypto key. This one also kept failing, so I had to manually dpkg-reconfigure libdvd-pkg to settle things.

    - For the first time EVER since I become a Debian user 11 years ago, I've had problems with the supposedly supported way of upgrading from oldstable+backports to stable - for whatever reason the Qt6 and the kernel 6.1 had newer version numbers on bullseye-backports rather than bookworm, so the installer left those in place. This also means that while doing the post-install vacuuming of old junk, I ALMOST ended deleting the kernel I was running because apt didn't bothered installing linux-image-amd64, and Synaptic flagged the kernel package as "old/local". Fortunately apt has a safety net that stops you from nerfing your system that way, but COME THE FUCK ON... Fixing Qt6 was fun too - had to remove qmake and friends so i could "downgrade" the packages to the proper, Debian-kosher versions from stable.

    - The noVideo 390.xx blob remains there for now - it won't be autoremoved during upgrade, but by the time Trixie hits stable (in less than 2 years from now on), it will be Nouveau or nothing. ICK! Let's hope Maduro is dead and rotting by then so I can afford new hardware, preferably something with less green and more red, or even blue!
    tomman More stuff I need to find fixes/workarounds on TDE:
    * GTK3 apps ignoring specified font sizes (I really do *not* want to go back to my KDE4-era .xprofile/gtkrc fuckery!)
    * Rendering glitches with GTK2 themes (for example scrollbars being rendered... a bit too flat)
    * TDE's Konqueror insistence on feeding useless file URIs when you try to open a file (this often causes pain when dragging and dropping files into VLC, or trying to play something with mpv from a SMB share since they punted support for smb:// URIs to ffmpeg - this somehow automagically works on MATE because of GVFS doing some Magic™ behind the scenes, but not these old crusty kioslaves!)
    * Find a better way to integrate system notifications from non-TDE apps

    Also need to perform a KDEctomy on my current, now dormant Plasma installs.
    tomman Forget about using libvdpau-va-gl1 on VLC on Bookworm: it's so broken it fails to do any kind of hardware decoding! You might as well fall back down to software decoding and hope that your hardware is not too underpowered for the media you're trying to playback.

    If you have a Radeon (even one like my lowly HD2600), you still have another fallback: native Mesa VDPAU drivers. Except that VLC crashes when trying to play certain media, namely, Blu-Ray menus. Yay, the curse of ATi drivers never ends! Tried also using good ol' Xine (yes, that thing still exists), but... nope, it has aged badly. VERY badly. I completely failed to get hardware decoding working with it: VDPAU would crash (due to the previously mentioned driver issue) or do nothing (va_gl), and VAAPI surprisingly was broken too (the driver would be loaded correctly, but it resorted to software decoding anyway). So yeah, forget about playing discs with menus on Debian 12 :/ (also fuck mpv devs for insisting that disc menus are noise!)

    ---

    And now, for something completely different: testdriving Trinity Desktop Environment R14.1.0 on Debian Bookworm!

    MATE is my DE of choice, but thanks to GTK's braindamage slowly corroding it, I no longer consider MATE a long-term choice for my computer use, so I need a plan B C Z X. Now that TDE is playing fair with Pulseaudio, it's time to start the deployment at home, so here are my setup notes:

    - The Debian repos are here: https://wiki.trinitydesktop.org/Debian_Trinity_Repository_Installation_Instructions

    - Do *not* install the tde-trinity metapackage! It will end replacing a stock Debian branding package (desktop-base) with their own one (destkop-base-trinity), creating potential for weird things to happen. Either install tdebase-trinity, or install their direct metapackage dependencies (tde-core-trinity, tdeedu-trinity, tdegames-trinity, tdetoys-trinity, tdeaccessibility-trinity, tdeaddons-trinity, tdeadmin-trinity, tdeartwork-trinity, tdegraphics-trinity, tdemultimedia-trinity, tdenetwork-trinity, tdepim-trinity, tdeutils-trinity, tdewebdev-trinity). Feel free to ignore those that you do not need/want.

    - I ended tripping a landmine during install on my Inspiron, because one of the dependencies of TDE is libart-2.0-2, which is a library that exists in both Debian and TDE, but the latter ships with a higher version number. Since nothing else uses this thing (it seems), it should be safe to replace... except that in my case it ended installing the i386 version, which was causing the entire setup to abort badly, and no magical spell of apt(-get) will fix it, leaving with a BROKEN Debian install! OUCH. The fix took me some time to figure it out: dpkg -P libart-2.0-2:i386. Then let apt-get --fix-broken do the rest. WEIRD ERROR MAN.

    - This is good ol' KDE 3.5 (Peak KDE, if you will), but that doesn't mean it is stuck in the past! TDE features a optional desktop software compositor, which is actually a custom version of Compton. Put that GPU you paid good money for to good use~

    - Slap these two lines in your ~/.Xresources to stop KTDE's nasty habit of forcing black-on-white consoles:
    xterm*background: black
    xterm*foreground: white

    (Or use your favorite xterm theme, if that's how you roll)

    - Theme integration! A favorite of mine. Sadly you can't use GTK themes with the bizarro Qt3 zombie that TDE uses, but here is how you achieve reasonable integration with your GTK apps (since we're forced to coexist with that pest for as long as our web browsers rely on it): first install gtk-qt-engine-trinity and gtk3-tqt-engine-trinity so you can set your GTK apps to use THEMES NOT NAMED FUCKING ADWAITA (GTK3) or ancient Motif-inspired junk (GTK2) - installing those two will enable the GTK appearance settings page on the TDE Control Center. As for achieving the unified GTK-Qt look (in my case, Cleanlooks), you can install tde-style-qtcurve-trinity and gtk2-engines-qtcurve (please use --no-install-recommends with this one, or it will try to install a bunch of Plasma 5 vomit!) to get the insanely customizable QtCurve theme, which even ships with a quite convincing "Kleanlooks" preset.


    Stuff I still need to work on:
    * Minor font screwups (particularly with filenames with Chinese characters)
    * Find a temperature/network speed monitor taskbar applet (the ksysguard-powered one SUCKS, and I do remember using something much nicer in my KDE3 era!)
    * Figure out how to replace the system beep with an actual audio file (like MATE does)
    * smb:/ network browser won't list machines in my network

    So far, I'm lovin' it™, but there is still work to do. Also, no Wayland stench in the horizon here! Just me, and a (mostly) non-braindamaged desktop!
    tomman How to let your vintage Windows 9x/XP/2K boxes talk to your Samba server:

    Edit your smb.conf's [global] section to look like this:

    # For Win2K/XP compatibility: reenable SMBv1 (tested on WinXP SP3)
    server min protocol = NT1
    client min protocol = NT1
    ntlm auth = yes

    # For Win9x compatibility: reenable even more ancient stuff, create an username map (tested on 95/98/Me)
    lanman auth = yes
    client lanman auth = yes
    client plaintext auth = yes
    username map = /etc/samba/user.map

    # Also ensure this one is set like this
    map to guest = never


    The username map file has a trivial structure that looks like this:
    yourLinuxUsername = YOURWIN9XUSERNAME
    anotherLinuxUsername = IAmAWin9xUser AnotherWin9xAlias BLAH

    This is ONLY needed in 9x/Me since those OS are dumber than rocks and assume that whatever user "account" you're using is the same you want to use to logon into a NT/SMB server (instead of asking for it like NTs do), which most likely is not your case. Restart smbd after you're done with your edits here.
    (I'm not sure if the username map file is case sensitive, but be aware that Win9x is sending usernames in ALL CAPS)

    Don't forget to re-set your SMB passwords after all this (# smbpasswd -a yourLinuxUsername), since NTLM and LANMAN use different algorithms and by default Samba won't save hashed passwords for the latter, preventing your 9x hosts from ever logging in.

    And before the SEKURITAH LOLSEARCHERS come at me with their "reenabling those ancient security algorithms is a bad idea" rants:
    1) FOR AMUSEMENT ONLY!
    2) Don't do this on a machine directly plugged into the raw Internet, a production server, etc.
    3) Go hack into a bank, the Kremlin, or something else!


    ---

    In other news, I replaced the bad RAM in my laptop, so I got rid of the memmap= entry for now. Be aware that memmap= CANNOT be used on UEFI systems with Secure Boot enabled because of "security concerns" (yes, I still believe Secure Boot is a solution looking for a problem), so either get rid of Secure Boot, or replace that RAM ASAP!

    ---

    Just updated my Inspiron 6400 to Bookworm. 4GB of packages that took ~2h30m to install, not bad!

    Here are the gotchas I found along the way:

    - GRUB_DISABLE_OS_PROBER=false. This shit is getting tiring, Debian! Not everybody lives in a LVM set!

    - The default font on this one was set to "Sans Regular", which now maps to Cantarell instead of DejaVu Sans. Turns out that while Cantarell looks ugly at 11pt (the default for new installs), it actually looks pretty nice at 9pt, so I'm keeping that~

    - You won't be able to scan anymore from GIMP via xsane because some random bug reporter took a deprecation warning too serious, without even consulting to actual users of this thing! Your options:
    1) Install "sane" (NOT xsane), then you get xscanimage... which is a barebones version of xsane devoid of nearly all of the functionality. Oh, and that one also triggers the OHMYGOD deprecation warning too!
    2) Revert this stupid patch (because GIMP 3.0 is not shipping anytime soon). For fun, let's do it the Debian Way™... mostly:
    apt-get source xsane
    sudo apt-get build-dep xsane
    cd xsane-0.999/
    patch -R -p1 < debian/patches/0105-deb_gimp_acquire_menu.patch
    debuild -b -uc -us -tc
    sudo dpkg -i ../xsane_0.999-12_amd64.deb
    sudo apt-mark hold xsane


    (the "apt-mark hold" is required since your rebuilt package will have a slightly lower version number than the official one, unless you wanna tamper with debian/changelog too)
    I'll be dropping some angry remarks on those bug reports...
    tomman Yay, I've got... bad RAM~!

    Recently SeaMonkey started crashing at random - sometimes as frequent as 3 times in one hour! Initially we thought it could have been some bad patch or something, until someone at #seamonkey suggested testing my RAM. And of course, memtest86+ found some bad RAM: a dead bit somewhere in the upper ~4GB space seemed to be the possible source of this mayhem (I have 2x4GB DDR3-1333 modules on this Asus, which is apparently the max RAM I can install despite the i5-2450M supporting up to 16GB DDR3 RAM).

    Since the fault was found in a rainy weekend, in a city where the few remaining computer stores are poorly stocked and overpriced to hell and back, that means enforcing a workaround until I can get RAM replacements sorted out. Fortunately there are ways to tell Linux to stay the hell away from bad RAM:

    - Good ol' BadRAM patches: memtest86 can even generate the badram= patterns for you, but unfortunately those patches were optional and never merged upstream (AFAIK). I'm pretty much sure Debian doesn't even ship them, so those are unusable as-is.

    - GRUB: The GRand Unified Bootloader can use badram= patterns as-is too (via the GRUB_BADRAM param on /etc/default/grub), passing those to the e820-generated memory map to the Linux kernel, except that... nope, it can't. At least not in 64-bit machines! Even worse, if you define GRUB_BADRAM with 64-bit offsets, you'll end with an unbootable PC that can't even reach the GRUB menu anymore, requiring to boot via rescue media to undo the setting and hopefully restore bootability. So nope, that ain't do either.

    - memmap: The expected solution these days, where you can define your own memory map and pass that to the kernel commandline. Documentation is of course confusing, but the only thing we need to know here is that for excluding bad RAM areas, all you need to know is 1) the size of the area to exclude, and 2) the offset, then you pass them in a somewhat more user friendly way like "memmap=64K$7400MB" to exclude 64KB of RAM at ~7400MB. Or use hex numbers and offsets, LIKE AN ANIMAL: "memmmap=0x1000$0x0000DEADBEEFB00B". Basically the syntax is "<size>$<address>", and you need to remember to escape that $ on /etc/default/grub with THREE backslashes! (GRUB_CMDLINE_LINUX="memmap=0x1000\\\$0x01234567")

    So it's just matter of telling memtest86+ to output badram= patterns, take the offsets and use them on memmap, right? HAHAHAHAHAHAnope, this shit as expected is not only poorly documented, it's also somewhat misleading because thanks to the magic of MMUs, system-specific memory layouts, and other black wizardry, the kernel and 3rd-party memory testers may not agree on the actual offsets of the bad RAM spots. This of course bite me because I was still experiencing the random SeaMonkey crashes even after excluding the bad memory (and then some!), and it even managed to bite Steam too! So... what gives? Enter the kernel's built-in memory tester, triggered via the memtest=<num-of-passes> option.

    memtest86+ was telling me I had a dead bit at 0x00000000a00f2888, but after using Linux memtest=8 (you may need to try with a larger number of passes since this thing is not at exhaustive as memtest86+ is!), the kernel was finding the same bad bit at 0x000000001e00f2888! That's a 0x14000000 difference, dunno why, but seems to be consistent on each boot so I'll go with that one, therefore my memmap magic param turns out to be "memmap=1M$0x00000001e00f2000", that is, I'm excluding the entire megabyte surrounding that bad offset just to be sure.

    I got very VERY lucky that this hard-to-diagnose fault was ONLY hitting my web browser, and not something more delicate... like a filesystem driver, or the kernel itself, or the shared video memory! Of course the real solution here is to just go out and buy moar RAM, but that's not exactly easy in the land of the Sovereign Bolivar Mark II, still it's something I intend to sort out this week, hopefully! In the meanwhile, let's pray that the faulty RAM stays confined and doesn't spread :/

    ---

    In other news, remember the KDE3.5 revival? My previous experience with Trinity Desktop Environment were ruined because of Arts and Pulse not cooperating (instead, Pulse was hanging while turning that poor ol' Thinkpad single-core CPU into Furnace Mode). After upgrading to Bookworm, TDE followed on and released a new, Bookworm-compatible version, and oh joy, I can now turn on TDE's sound services without clashing badly with Pulse! Poetteringware hateboner averted. Now it's time to plan the deployment of TDE into the rest of my fleet, since MATE is getting devoured slowly by the GTK3+ worms :/
    tomman Bookworm launched... without the noVideo blob for some "legacy" GPUs, namely my Fermi 610M:
    https://tracker.debian.org/pkg/nvidia-graphics-drivers-legacy-390xx
    https://bugs.debian.org/1006719
    https://bugs.debian.org/1033776

    Remember, the 390-series blob went EOL last December, and that was reason more than enough to not ship it with the latest Debian stable. Even worse, a bunch of CVEs were disclosed recently affecting a large number of nVidia's blob... including already EOL'd versions, so it doesn't make any sense to ship obsolete, broken, and potentially insecure software with a stable distro.

    This also means for those of us stuck forever on Tesla/Fermi GPUs that we no longer have the right of having good, stable drivers with great performance for our metal. All that it's left is Nouveau and the big punch to the liver that comes to it with regards of its (lack of) performance because they never could get reclocking properly implemented for those GPUs, and I can't really blame them since, unlike Asahi Linux, noone is throwing money at them to support the ever-growing numbers of nVidia GPUs on Linux boxes (after all, "the blob works fine for the 99%"... until it no longer supports your card, but by then you're due for a new computer, right? RIGHT?!).

    The 390 branch is still available from Sid, and it should work for now (assuming you figure out which packages to install), but it won't work for much longer, so maybe it's time for me to just write off this useless extra GPU for which I paid good money 11 years ago :/ Or, if I'm masochist enough, risk frying this laptop for good with scripts like this: https://github.com/ventureoo/nouveau-reclocking

    (On the flip side, I would gain proper PRIME offload, something that noVideo refused to give us many years ago)

    Remember kids:
    tomman Today is Bookworm's Release Day~!

    GO.

    ---
    Just upgraded Ye Olde IBM TV Box: another traumatic upgrade experience because the Radeon HD2600 is starting to show signs of the RoHS pox (or simply wants to die), as the machine hung early in the install phase, then after a reboot the display went corrupted... and hung again.

    After removing the case, poking it at the stupid AGP card, and trying a couple times ago, I'm gladly surprised of the battle-tested, highly resilient Debian package managers - here is how you recover from a botched upgrade (flaky hardware, blackouts, etc) without having to pull the nuclear option:

    - If the machine boots, that's good! Try booting to recovery mode (Advanced Options -> select any kernel that says "Recovery"), then give your root password and move on from there.
    - Try rerunning apt-get dist-upgrade. It will figure out that the last run was interrupted and will tell you what command to execute, which will be either dpkg --configure -a, or apt --fix-broken install
    - You may need to repeat that a few times until you're able to do a clean dist-upgrade, then reboot~!

    Some side effects: I lost all of my locales (except for en_US.ISO-8859-1), so I had to run dpkg-reconfigure locales before the first reboot to clean up that. Also had to do the GRUB_DISABLE_OS_PROBER=false so I don't lose the Windows boot entry (remember: dualbooters now have to do that because $RAISINS)

    As for the loss of VAAPI hwdec on VLC, there is a workaround: VLC still supports VDPAU, and there is a VDPAU-to-VAAPI bridge available on the repos: libvdpau-va-gl1. Install that, setup VLC to use "VDPAU output" as video output, done. Or use something else not made by braindamaged Frenchies, I guess...

    2/5 done~
    tomman Look, I'm not against new tech - I'm NOT that much of a luddite (yet!)

    I'm against new halfassed tech designed by committee, where you're replacing a pile of hacks for a bunch new shiny code with many shortfalls that aren't a 1:1 replacement for most use cases, and where anyone presenting a sensible complaint gets promptly dismissed because You Don't Fit The Vision™.

    For me, Wayland IS my systemd moment.

    If I'm "going under" with Xorg, so be it. But then that day is far away, considering that Win32 is still a thing :P
    wertigon
    Posted by tomman
    From now on, I hereby decree that Wayland is PERMABANNED in THIS house. If Debian ever caves to the Wayland "forward thinkers", that's the day I'm staying with the last Xorg-enabled version until it dies of bitrot, THEN I'm quitting computers for good.


    Anyone tying themselves to the Xorg ship mast is doomed to go under sooner, rather than later.

    Xorg is based on heaps upon piles upon mounds of hacks to get it running on a modern architecture. As soon as Xorg is off the table, you can optimize new drivers to be like one third the size in the active codepath. Xorg support will still remain for a long while as a backwards compatibility option, but I think direct kernel support acceleration could go away as early as 2026 or so. Of course, that means the 2026 LTS kernel will no longer accelerate Xorg on hardware, not that it is completely unbootable.

    Xorg as it stands is already a rudderless ship on life support, and is rapidly moving towards legacy status, where it will linger until deemed obsolete. Now, one does not simply delete Xorg, far too many hooks for that. But the work to remove all hooks is more or less completed, so now we can start extracting big chunks of Xorg to Wayland. Are there some vital protocols left, yes, but those are edge cases for the most part. Things like HDR and stuff like that. Old tech, Wayland should handle pretty well now.
    tomman Asahi Linux (actually marcan) To Users: Please Stop Using X.Org

    Gotta love the smell of clickbait and flamebait in the morning~ But we can't expect better from a former console hacker/drama queen from Spain. I'll try to keep this polite, so I'm going to say this: MY computer, MY rules. No software developer decides what I should use and what I shouldn't, no matter the hardware. Please stop "pushing" my desktop "forward", THANKS. NOONE ASKED YOU FOR THAT.

    From now on, I hereby decree that Wayland is PERMABANNED in THIS house. If Debian ever caves to the Wayland "forward thinkers", that's the day I'm staying with the last Xorg-enabled version until it dies of bitrot, THEN I'm quitting computers for good.

    Hector Martin, welcome to my select list of Assholeware™ developers, just next to Moonchild, Tobin, and Jamie W. Zawinski. I'll be avoiding any project you're actively involved on from now onwards.
      Main » Discussion » (Mis)adventures on Debian ((old)stable|testing|aghmyballs) » New reply
      Get an ad blocker.