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


    [b]…[/b] — bold type
    [i]…[/i] — italic
    [u]…[/u] — underlined
    [s]…[/s] — strikethrough
    [code]…[/code] — code block
    [spoiler]…[/spoiler] — spoiler block
    [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


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


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


    [youtube]…[/youtube] — video ID only please
    Thread review
    tomman As per this comment on the related Ubuntu bugreport, adding iommu=soft seems to silence the endless stream of swiotlb bullshittery on systems using Broadcom 4401 NICs, like my Inspiron 6400.

    No other side effects have been noticed so far. Unfortunately, outside the Ubuntu bugreport all reports related to this stupid bug have been stalled (or even closed), as nobody seems to care about old computers anymore, and this comes out from the OS that supports pretty much every Network Interface Chipset known to mankind...
    tomman Been using xterm since I got bored of konsole/gnome-terminal (too much stuff for my liking), even back when DEs weren't braindamaged. Normally I dislike minimalism, but come on, it's a terminal, you should not get in the way! ("tabbed terminals"? Dude, windows are free!)

    I haven't even touched my xterm settings - I use whatever defaults are shipped by my distro of choice.

    Yes, I know xterm has a menu. No, I've never used it intentionally.
    CaptainJistuce Xterm also has ths advantage of trying to actually emulate the terminals it claims to emulate, instead of claiming to be a specific DEC terminal and then behaving wildly diffrently.

    On the other hand, something libvte-based will probably be better-behaved with newer software because of the nesticle effect.
    Screwtape Recently, Debian Testing finally updated to gnome-terminal 3.34, in which they finally got around to making all the various menu-options accessible from title-bar controls, so you can use them even when the menu-bar is hidden. For a straight-up GNOME 3 desktop, that's an improvement.

    For people using gnome-terminal on a non-GNOME 3 desktop, it can be a drawback. Title-bar controls mean a client-drawn title-bar, so window-managers that actually manage windows (like i3, dwm or awesome) now have extra, redundant title-bars hanging around eating up space.

    I'm not angry, because it's reasonable for the GNOME people to make gnome-terminal better for GNOME at the expense of other environments, but I'm now in the market for an alternative, visually-lighter-weight terminal emulator. Unfortunately, it seems that gnome-terminal is absolutely the most polished terminal emulator around, and everything else is a step down.

    My current shortlist of alternatives is:

    - xterm is a bit primitive, but rock-solid, and I already have it configured to my liking.
    - pterm is a straight-up port of PuTTY to POSIX, and it feels a bit weird to use it as a local terminal
    - QTerminal feels weird because it's Qt-based, and sometimes it lays out Unicode text oddly

    I'm definitely not interested in:

    - st, because I don't want anything to do with the suckless "community"
    - kitty, because I'm not interested in managing Yet Another Config File
    - alacritty, ditto
    funkyass does the kernel project accept bug reports directly, or just from downstream?
    Posted by tomman
    Looks like my Inspiron 6400 kinda disliked it.... or at least the wired NIC (some Broadcom IC that has worked flawlessly since the good ol' 2.6 series) started vomiting at my kernel log:
    ...kernel log snipped, look at the bugreport...

    If there is network traffic of ANY kind, I'll get my kernel log spammed to death and back with that crap. This time I'm not alone, as some guy is experiencing regressions with the b44 driver on Ubuntu:

    "If it is not broken, don't fix it!"
    Linus, where are your angry yells when they're needed?!
    In the meanwhile I've filled a Debian bug, and refrained from booting 5.2 on this laptop anymore (4.19 works fine)

    Three weeks later, my bug report remains untriaged. Yay opensource.

    Still better than the dude that reported it to Fedora, whose bug report just got closed because nobody cares it went "stale" due to newer kernel releases (which still contain the bug).

    The machine is stable and networking works fine, it's just that your kernel log is rendered useless, which can go from "meh" to "kinda dangerous" (as I routinely use it to diagnose misbehaving/faulty hardware).
    tomman There is a legit use for PulseAudio beyond "juggling with multiple soundcards": visualizations!

    If you let Pulse move into your house, you get rights to the awesome projectM library, with support for the equally awesome Milkdrop visualizations, and it also ships with a Pulseaudio monitor app that can convert every boop and beep emitted by your applications into pure LSD.

    ...or at least it should do so if it wasn't too busy segfaulting aborting with a double-free on Debian. Once again, the fault is not on Lennart, but on projectM themselves.

    How to properly build Debian packages from sources with user modifications
    dch --nmu
    quilt new someusefulname.patch
    quilt add path/to/filename/to/patch.cplusplusisshit
    <repeat for each file to modify>
    your-favorite-text-editor ...
    quilt refresh
    <repeat for every change>
    dpkg-buildpackage -b -us -uc -tc

    Anyway, in the case of projectM, just merge this patch, build your debs, and install the resulting libprojectm-qt1v5 (you don't need to install everything else), because we won't be getting this merged downstream until the next Debian release cycle :/

    There you have, you can get your Lennarts high too :D
    tomman Doing some research, this nasty bug was introduced sometime after kernel 4.19 (maybe around the initial 5.0 releases), due to some changes in DMA direct functions, because someone decided to get SWIOTLB involved on all this. This is the offending commit:

    Not all devices play nice with this change, including my Broadcom BCM4401 NIC.
    Playing with the swiotlb= kernel parameter only causes DMA failures or even null pointer dereferences, leading to system unstability and -why not?- crashes.
    And surprise surprise, I found several other ancient Dell hardware users with the EXACT SAME BUG: (Fedora) (Arch)

    Some may blame this recent commit on the b44 driver itself:
    ...but it's not the first time b44 and swiotlb don't play nice:!topic/linux.kernel/GEx80ZCue1o

    tl;dr: if you own a Dell system with a wired BCM4401 NIC, AVOID 5.X KERNEL RELEASES!
    tomman Backports now has some cool stuff for Buster, including a new 5.x-series kernel, so I took the offer.

    Looks like my Inspiron 6400 kinda disliked it.... or at least the wired NIC (some Broadcom IC that has worked flawlessly since the good ol' 2.6 series) started vomiting at my kernel log:
    ...kernel log snipped, look at the bugreport...

    If there is network traffic of ANY kind, I'll get my kernel log spammed to death and back with that crap. This time I'm not alone, as some guy is experiencing regressions with the b44 driver on Ubuntu:

    "If it is not broken, don't fix it!"
    Linus, where are your angry yells when they're needed?!
    In the meanwhile I've filled a Debian bug, and refrained from booting 5.2 on this laptop anymore (4.19 works fine)


    If you're updating to kernel 5.2 with the nVidia blob, be aware that the version on Buster will not build with it. Yup, it's that time of the year again, the joys of proprietary kernel modules. nVidia has already fixed this upstream, but until the fixed version lands on buster-backports, you have to fetch the DKMS module from Debian Snapshots (in my case, this one)
    Wowfunhappy I'm sure someone will package Virtualbox for Buster, at some point. Unofficially, of course.
    Screwtape > ls -U shows that the MATE provider was created first...

    Is that a straight "ls -U", or something like "ls -U *Notifications*"? Because if it's the latter, the list of items is provided by the shell, rather than by ls, and the shell might do its own sorting or something.

    > WTF Loonix?!

    I think renaming does put the new name at the end of the "ls -U1" list, so that would explain why renaming the KDE service put it last.

    However, note that ext4 filesystems support "directory indexing", which stores a directory's filenames in a B-Tree index, so they'll always be iterated in sorted order regardless of creation order.
    tomman ls -U shows that the MATE provider was created first, yet both grep and DBus pick the Plasma entry!

    However, moving the file org.kde.plasma.Notifications.service to org.kde5.plasma.Notifications.service actually changes everything:

    tomman@himawari:/usr/share/dbus-1/services$ grep -RI 'org.freedesktop.Notifications' /usr/share/dbus-1/services/
    /usr/share/dbus-1/services/org.kde5.plasma.Notifications.service:Exec=/usr/bin/plasma_waitforname org.freedesktop.Notifications

    In this case, the MATE provider is seen first, and indeed DBus invokes the MATE provider whenever someones wants to notify something.

    WTF Loonix?!
    tomman So yeah, something broke. On this very last laptop, notifications stopped working on MATE.

    I noticed because I downloaded a file, and instead of the fancy MATE notification, I got a horrible plain unstyled XUL notification from Seamonkey. Checked with the MATE notification settings... just to get a hang, and after a while, a DBus error!

    But on my Dell, notifications work fine, so go figure. Maybe I did uninstalled some seemingly-harmless cruft during post-upgrade cleanup? Both laptops have more or less the same packages. Checked the install of mate-notification-daemon, and it was fine. Tried manually invoking the daemon (which lives at /usr/lib/mate-notification-daemon/mate-notification-daemon), and notifications worked for a while... but then the daemon exits after a few seconds of inactivity or so, because it's supposed to be invoked on the fly via DBus. Once it exits, notifications stop working.

    Long short story: I have both MATE and KDE installed. I rarely use KDE these days because Plasma 5 is a terminal cancer, and it's too bloated for my older Dell anyway. Both ship with DBus service files for their respective notification daemons (org.kde.plasma.Notifications.service / org.freedesktop.mate.Notifications.service). Turns out that notifications have been working for me by sheer luck all these years, but my luck just ran out, as when DBus finds several providers for the same service, it will pick the first it finds (and not necessarily the newest one it finds, unlike what some people claim that the docs say - this poor guy had the same problem as me but on Fedora). There is a easy way to check who will win on your specific setup:

    tomman@himawari:/usr/share/dbus-1/services$ grep -RI 'org.freedesktop.Notifications' /usr/share/dbus-1/services/
    /usr/share/dbus-1/services/org.kde.plasma.Notifications.service:Exec=/usr/bin/plasma_waitforname org.freedesktop.Notifications

    Ol' Dell:
    tomman@tomman-lp-c2:~$ grep -R 'org.freedesktop.Notifications' /usr/share/dbus-1/services/
    /usr/share/dbus-1/services/org.kde.plasma.Notifications.service:Exec=/usr/bin/plasma_waitforname org.freedesktop.Notifications

    grep doesn't seem to care about alphabetical order or file dates - timestamps are consistent across both laptops, since they're both using stock Debian packages:
    tomman@tomman-lp-c2:/usr/share/dbus-1/services$ ls -l *Notifications*
    -rw-r--r-- 1 root root 115 ene 9 2019 org.freedesktop.mate.Notifications.service
    -rw-r--r-- 1 root root 114 feb 13 2019 org.kde.plasma.Notifications.service

    tomman@himawari:/usr/share/dbus-1/services$ ls -l *Notifications*
    -rw-r--r-- 1 root root 115 ene 9 2019 org.freedesktop.mate.Notifications.service
    -rw-r--r-- 1 root root 114 feb 13 2019 org.kde.plasma.Notifications.service

    ...yet on this Asus, the Plasma provider wins. And it starts. And it sits there, frozen. And eventually DBus times out and vomits a completely user-unfriendly error message, and leaves me with a hung notifications daemon and no notifications at all.

    Technically the blame lies on MATE, as they refuse to obey the DBus specs and just keep their daemon running session-wide so DBus doesn't have to play the mailman game, ringing doors until it finds someone willing to receive the package. I guess I could go ahead and delete the Plasma notification provider... but on this Asus I actually use KDE once in a blue moon. Or figure out a way to make DBus (and grep and anyone else that only cares about the order in which files were created into the filesystem) to always pick the MATE notification service first...
    tomman The broken Steamlaptop has been busted!

    Well, it rebooted at first try. Definitely my most clean Debian dist upgrade to date. Sega 32X Optimus graphics still work fine (and the nVidia blob is still causing some kernel bug when turning off discrete graphics - harmless, but still annoying).

    Time to clean up, curse Oracle, reinstall VirtualBox, curse Oracle again, figure out if my Project64 ROMs still run on whatever Mupen64Plus build they ship (apparently it's still 2.5.0, so those non-N64 Mario hacks should work), and call it done.

    So, for those following the count at home, I'm at 3xBuster and 2xJessie setups here. The Jessie ones will stay there, even past LTS. I can't believe that I first switched to Debian at hone back in 2012, when Wheezy was still in testing. The very same laptops have been upgraded over and over and over (Wheezy->Jessie->Stretch->Buster), and this time, the upgrade went real smooth. Try doing that with Fedora. Or with Windows :P
    Posted by tomman
    There is OVF which is supposed to be a interoperable format to easily move "appliances" between virtualization solutions, but in practice it has largely failed.

    As I understand it, it's great for Linux VMs, because the Linux kernel generally includes all the drivers for everything everywhere, but I can just run Linux software directly, I don't need a VM for it. I need a VM to run Windows software, but Windows installations tend to have very specific hardware drivers installed in the registry, so moving an installation from one VM platform to another (or one motherboard to another) gets you blue-screens.

    libvirt's virt-manager is a shiny easy-to-use front-end like VBox has, but.... it's designed by RedHat for RedHat's customers. So, for example, you don't keep a bunch of VM images in your home directory, you connect to a daemon that manages all the VMs on a system. Bad luck if you've got a small root partition and a big home partition! Video always runs through VNC or SPICE, for ease of managing a fleet of VMs on servers from your workstation, but bad luck if you wanted 3D acceleration. When creating a VM, it asks for a bootable CD image to install from, which is exactly what you want when dealing with modern server OSs, but sucks if you want to install Win95 or something a bit niche.

    GNOME's "Boxes" is an even shinier, even simpler libvirt front-end, but... well, GNOME 3.

    QEMU is vastly more powerful and flexible, but of course much trickier to use. It's actually pretty easy for the real simple stuff; you can boot up a floppy image with "qemu-system-i386 -fda disk1.img", but of course more complex things like ejecting one floppy and inserting another are... less easy.
    tomman I guess I'll have to take a look on that someday... but then your current options for 3D accel are:

    1) GPU passthrough: not feasible on a laptop, nVidia blob blocks that unless you're paying good money for a Quadro (hacks do exist), and you need to buy a extra video card that you can't use for anything else
    2) GPU virtualization: some newer Intel IGPs can do that (GVT-d), but then it implies buying new (and very specific) hardware. Weirdly enough, neither AMD nor nVidia offer something like that yet!
    3) VirtGL: Unfortunately it doesn't do D3D yet, which means no Aero, possible troubles with W8/10 desktops, and no Win32 games - OGL workloads should be fine.
    ‮strfry("emanresu") It has a nice GUI called virt-manager. I can't remember using 3D acceleration, but Arch Wiki says it exists.
    Installation of non-free edition

    Debian 10 "Buster"

    Packages for VirtualBox are not available in Debian 10 and won't be in buster-backports either. A recommended alternative is Virtual Machine Manager (buster/virt-manager).

    Well, fuck you Debian, and FUCK YOU VERY MUCH, ORRIBLE.

    So yeah, VirtualBox is pretty much done on Debian, partly because their maintainers can't make a goddamned exception to their absurdly rigid "no new versions from upstream on Stable, even if upstream have separate maintenance branches" (remember the whole Iceweasel fiasco), but mostly because Orrible doesn't want anyone using their products without paying them dearly, because Larry wants to buy another boat. Build my own .debs it is, because I really can afford wasting 3GB of disk for a single program I use every now and then.

    Also, fuck you One Raging Asshole Called Larry Elison.
    tomman Bring me a nice foolproof GUI (like the one VBox has), and decent 3D acceleration that doesn't require me to buy a second videocard and play PCI pass-through shenanigans, and I'll reconsider.

    But then, that will eventually happen if Oracle continues alienating its userbase. VMWare is quite irrelevant on desktop nowadays (not to mention that it's closed source and not free), and Hy-perv is Windows-only (and useless for desktop, to boot). Either libvirt/QEMU gets user-friendly enough to reach "appliance" status (the one that VBox has today), or VBox gets forked (I guess that it will unleash the wrath of Larry, but whatever)

    Regarding that nVidia flickering bug, I found the ticket:
    A 4 year old regression introduced to fix something for some unnamed paying customer by some developer that eventually left Oracle. Fixes were initially rejected, then the usual "it's Open Source, patches welcome!", then some bikeshedding, and eventually a compromise: not a checkbox, but an environment variable. Except that the bug somehow ended hitting Windows users too, where setting environment vars is NOT a walk in the park because lolMicrosoft. And it seems that the bug was reintroduced on the latest Vbox 6.0.x, without hopes for a solution because it somehow only affects users on nVidia hardware using the blob.

    So yeah, endure ATi driver hell, Intel is Good Enough, or if you're lucky to own one of the 3 GPUs with half-decent Nouveau support, uninstall the blob. All of this for having a shiny desktop (or in the case of W8/10, a desktop at all, thanks to forced DWM)
    ‮strfry("emanresu") I remember libvirt/QEMU as being okay to use. What's the downside?
      Main » Discussion » (Mis)adventures on Debian ((old)stable|testing|aghmyballs) » New reply
      Yes, it's an ad.