Home | News | Download | Packages | Forum | Wiki | Github

[Solved] Newbie problem with X

(Masato the Empty) #21

You mean you’re using an older ISO like in that other thread? I see. I guess I have no info on the CD you’d be using…

The linux metapackage depends on all the blob packages.
# xbps-query -x linux linux4.9>=0 linux-firmware-amd>=0 linux-firmware-intel>=0 linux-firmware-nvidia>=0 linux-firmware-network>=0 dracut>=0

Actually, that’s interesting. Upgrading the Linux package wouldn’t require an upgrade of any of those depends, except going to 4.9 (so they finally bumped it). So what I don’t get is why some of them still got upgraded.

Additionally, if not the firmware, then it would have to be in something else that was pulled in. You’ve got a weird one on your hands.

No, I got the package name wrong. there is no ‘radeon’


The .iso I’m using is from about a month earlier, 2016-03-16.

Wild guess is that they weren’t installed by the installer which may go by hw probing but if listed as dependencies of the meta-package, they would be installed. I’m thinking they were listed by xbps as being installed, not upgraded.

Thanks so much for the help. I’ll give the “nomodeset” and amdgpu a try this evening. Yeah, this has been a weird one from the beginning. It was my first EFI machine and there is no “BIOS key” that I can find to go into BIOS when booting. When I first got it, I had to go through about about 6 Windows menus to get it to boot into BIOS. With Arch, I installed refind and things have been much smoother. I had wanted it to dual boot Windows for a program I can’t get working in wine, but Windows always wanted to do a “recovery” which I was suspicious of so I ended up deleting it. I’m using the old Windows partition for Void. :grin:


I’m stumbling in the dark here. Blacklisted radeon in both places but it still loads. rmmod says it is in use. amdgpu also loads. With “nomodeset” I get “no screen found” or something like that and xorg exits. At least it doesn’t lock up. :slight_smile: Without it, I still get the lockup but Xorg is still using the radeon driver. No errors in dmesg. Xorg.0.log still immediately ends after loading glamor. I’m still curious about the fact that Arch goes on to initialize EGL at this point. It makes me wonder if something is still missing.

Edit: Turns out the best way to get rid of radeon is rd.driver.blacklist=radeon as a boot parameter. But I’ve also found that my video chip is GCN2 which isn’t really supported by amdgpu. So, I think I’m pretty well stuck at this point. I think I’ll wait for a few updates and try again.

(Masato the Empty) #24

did you update the initrd after blacklisting the module in /lib/modules.d/?

additionally before you do the dracut update, you can keep the actual module file out of the early boot by creating a blacklist file in /etc/dracut.conf.d (has to be named .conf) with the line
omit_drivers+=" radeon "
and any other modules you find on there that you’d rather keep out. (you can have multiple omit_drivers lines for better readability)

Once you’ve made your settings, just run dracut with the --force (otherwise it won’t overwrite) and it will update the initramfs for the currently-running kernel. (pass it any kernel version for it to make it for that kernel)

(Masato the Empty) #25

I’ve read that’s good for temporary testing, I guess in favor of blacklisting in the initramfs. But meh. Do what works.

regarding your chip… well there are still a few module options to play with. do a modinfo -p radeon to see a listing. There’s quite a few. Might want to look around the internet to see if there’s a good place to start.

Just offhand, try setting radeon.runpm to 0 or 1; there are some issues with the default (which depends on the detected chip) but I don’t really know if they apply to you since you don’t believe you’re on a hybrid graphics/powerxpress laptop.


Heh, that was rather uncanny. I hit “save” for my edit just as your post came. See my previous message. Thanks again for your help. I may try doing a fresh install again and fiddle around with it now and then, but given the situation, I just am not confident I can use it for my main production computer at this time.

(Masato the Empty) #27

by the way, where did you see that GCN2 isn’t supported? From what I can read, it should be. Kaveri is a “sea islands” graphics core, and kernel support is optional. Ours has it (CONFIG_DRM_AMDGPU_CIK). Did the kernel itself tell you this when you tried to load it? If not, you should try it.


If you did a fresh install you can hold packages using for example:
$ sudo xbps-pkgdb -m hold linux4.4-4.4.5_1
Also the old 4.? kernel gets updated by default to a new minor version as well as the latest series being installed.

You could try holding firmware packages too:
[] linux-firmware-amd-20161206_1 Binary firmware blobs for the Linux kernel - AMD CPU/GPU microcode
] linux-firmware-intel-20161206_1 Binary firmware blobs for the Linux kernel - Intel CPU/GPU microcode
[] linux-firmware-network-20161206_1 Binary firmware blobs for the Linux kernel - network
] linux-firmware-nvidia-20161206_1 Binary firmware blobs for the Linux kernel NVIDIA GPU microcode
And perhaps some xorg stuff as well if you liked.

This lists the files in an installed package:
$ xbps-query -f linux-firmware-amd
So you could make a copy of important bits manually to revert to if updates broke it, e.g here make a backup copy of /usr/lib/firmware. The old kernel on hold can be chosen from the boot menu. Also certain desktops or login managers can cause graphics hangs with particular machines.


Arch’s wiki. At least, that’s what I understood from it and the links they give. Mine appears to be an A8-7100.

I’ve also seen some sites that say that glamor is somewhat unstable and since the log ends with that, I still have a suspicion that that may be where the problem is. I created a xorg.conf.d file that has ‘Disable “glamoregl”’ which the log shows is being read, but it still insists on loading it anyway. Early in the log is says ‘“glamoregl” will not be loaded unless you’ve specified it to be loaded elsewhere.’ I haven’t. But, later in the log, …’(II) Loading sub module “glamoregl”’ and four lines later, all dealing with glamor, the log ends.

I’ll give the runpm option a try in a few minutes. I’m in the middle of something right now and can’t reboot.

BTW, the computer is a Dell Inspiron 15-5545.

(Masato the Empty) #30

ah that’s it. when the page was made, it was experimental, but I don’t think CI is considered that anymore. From the links I’ve seen, “Southern Islands” chips still are.


@hralgmir Thanks. That’s beginning to look like my only option.

@masato I tried both runpm options and couldn’t see any difference. I did get amdgpu to load and radeon doesn’t show up in lsmod. However, xorg still loads radeon along with amdgpu. I tried ‘Disable “radeon”’ and get the same messages I get with glamoregl.

Anyway, I spent all last weekend and every evening this past week fighting this thing. I work 10-12 hours a day, most of which is on the computer, and this isn’t the way I like to spend my evenings. :slight_smile: I’m going to reinstall one more time and freeze the kernel. Heh, I used Debian from Slink to Lenny and often waited 2 years or more for updates. My main concern is not knowing when I can try an update again. Having it give me an unusable system is obviously unacceptable.

Thank you very much for your help. I’m just not in a position to keep experimenting.

(Masato the Empty) #32

Too bad, but it’s your time after all, so no faulting you on that. (me? I can get pretty obsessive when running into issues, and I either have to get to the point where its’ clear that it can’t be done (and usually why) or I’m just too pissed to even look at it ever again before I can let go).

What gets me is that we don’t really know where the issue is occuring. microcode? the fact that your amd firmware is apparently not updated suggests no, so where then? (if it were the kernel, then going back to the old kernel should get rid of the issue, and we’d have a better target, but from what you’ve indicated, the change is permanent!)


Hmm so upgrading only the kernel means the older kernel no longer works.

And as Masato pointed out, the new kernel would overwrite /usr/lib/firmware in the install procedure in the template:
# Remove firmware stuff provided by the “linux-firmware” pkg.
rm -rf ${DESTDIR}/usr/lib/firmware
So mount the USB image with the old firmware in it and copy /usr/lib/firmware from that to the install?

The do_install part of the template is probably the relevant bit:
After copying back the old firmware, perhaps run update-grub, mkinitrd, depmod -a and so forth to get it back in the initrd?

(Masato the Empty) #34

If he’s still working on it, then to remove firmware, he would just xbps-remove the package (but he’d have to remove the linux metapackage in order to accomplish that…)

If you’re bored, here’s a little toy to play with. It’s a script meant to assemble a package from files in a running system where there’s no cached package file, pretty much meant to build package versions from the a running liveCD, or even from your own system just after install.

It’s not perfect though. Note that it can only package the files; it won’t handle install/remove scripts/messages as I don’t yet understant how scripts and other non-package files are encoded in the database.

Other than that, I think I’ve got the bugs out… (note it shouldn’t damage anything since it only does xbps-query and xbps-create, which don’t affect your package database).

I did it because I was playing around with the concept; I’d already done it manually which was pretty easy, so I got to thinking about scripting it (which is not always as easy). But I couldn’t resist, and so here it is.

(filename xbps-puller)
# segregate and rebuild a package from a running Void system without an xbps
# cache. Most useful for pulling package versions from Void LiveCDs

# TODO:	figure out if it's possible to get INSTALL/REMOVE scripts and other
#	related files; at present, we're just packing up installed files.

# Note: installs pax, because that's what I've been making use of lately

usage() {
  printf "xbps-puller:\trebuild xbps-package from running system without xbps cache\n" 1>&2
  printf "Usage: xbps-puller <pkgname>\n" 1>&2
  printf "\t<pkgname> must exist in the xbps database\n" 1>&2
  exit 1

[ -z $pkgname ] && usage

pkginfo="`xbps-query $pkgname`" || {
  printf "%s\tNo such package in xbps database\n" $pkgname 1>&2
  exit 1

while IFS='' read _info; do
  case "$_info" in
    \	*|\ *)
      [ $lastinfo == conflicts ] || continue
      conflicts="$conflicts $_line"
      architecture=`echo $_info | sed "s/^architecture:\ //"`
      homepage=`echo $_info | sed "s/^homepage:\ //"`
      license="`echo $_info | sed "s/^license:\ //"`"
      short_desc="`echo $_info | sed "s/^short_desc:\ //"`"
      pkgver=`echo $_info | sed "s/^pkgver:\ //"`
done <<_EOT

maintainer="local <root@localhost>"
newpkg=`echo $pkgver | sed "s/$pkgname/$pkgname-manual/"`

xbps-query -f $pkgname | sed 's/\ ->.*//'> $listfile

[ -f /usr/bin/pax ] || {
  xbps-install -S
  yes | xbps-install pax

mkdir /tmp/$pkgname
pax -rwv -p e < $listfile /tmp/$pkgname

export architecture homepage license maintainer short_desc \
  newpkg conflicts pkgname

cd /tmp
xbps-create --architecture $architecture \
  --homepage $homepage \
  --license "$license" \
  --maintainer "$maintainer" \
  --desc "$short_desc" \
  --pkgver $newpkg \
  --conflicts "$conflicts" \
  --compression xz \
rm -rf $pkgname
printf "created $newpkg.$architecture.xbps in /tmp\n"
rm $listfile

Note it builds the package and dumps it in /tmp because there’s not enough room on the overlay filesystem in the liveCD for some packages.


Yeah, I’m pretty close to that last status. I left a fresh install running last night and have a few minutes before church this morning. I installed the X stuff and pekwm and it works fine. I haven’t done a “-u” but did update linux4.4 to the latest version. No problem. Then I installed synergy which updated libgcc and libstdc++. Rebooted and startx freezes. Copied those 2 libs from the install media and cleaned up the symlinks, rebooted and it works again. No more time this morning but perhaps that tells us something.

(Masato the Empty) #36

OT, but is your handle related to Dostoevsky? (I haven’t read “the idiot” but from the synopsis, it sounds like a book that would interest me. haven’t read any works of fiction in a few years though…)

So you’ve nailed down the culprits it seems. The real trick will be in figuring why, and work around it.


Very perceptive. Yes. Long ago and far away in the days of CompuServe and AOL, before the Internet, I was on GEnie, contrarian that I am, and used “Idiot” as my handle. It made some people uncomfortable so I started using Myshkin instead. Actually, The Idiot is not a happy story and, IMO, Prince Myshkin is a failed Christ-figure. The genius of Dostoevsky is in portraying why he (Myshkin, not Christ) failed, although I’m sure many that read the book will miss it since he never says it directly but only by his portrayal of the prince.

As for the culprit, it certainly explains why booting a different kernel made no difference. Without old version repositories, I’m not sure how to move forward. It could still have something to do with glamor for it still fails but doesn’t lock up the system. The lines after the one it was locking up before now say
"couldn’t get display device"
(EE) modeset(0): glamor initialization failed

My current Arch log (finally found it) says at that point:
(II) glamor: EGL version 1.4 (DRI2):
(II) RADEON(0): glamor detected, initialising EGL layer.

It looks like “modeset(0)” is the output from amdgpu as a couple of lines later the logs are again in sync with modeset(0) replacing RADEON(0). The Gentoo website mentions a similar problem and gives the flags that mesa should be compiled with to correct it. Is there a way to see the compile configuration of Void’s packages?

(Masato the Empty) #38

Yes, look at the void-packages tree (either online, which you can get to it by clicking on the package in the package search page) but even better is to clone the repository yourself, which is really a must if you think you might build anything nontrivial for your system (I try to work outside a distro’s PM system as little as possible; the only things currently living in /usr/local on my Void system are a few scripts and small (single-sourcefile) programs. See here (wiki) for quick info, and here (manual) for when you want to actually make use of it (packaging software)

The information you want here is almost always in the template, (only exceptions I can think of would be items distributed as source like dkms) You might find they’ve got some similarities with Arch build templates, which from what I read also borrows ideas from BSD port systems.

Regarding getting old packages.
My script does that, but you don’t want to use it as it is now because the way I set it up will break things that depend on those packages. (right now, it’s a proof-of-concept toy)

The most important part is where xbps-query -f was piped to a file, which was then taken as input by pax to copy the needed files to another location, where you then run xbps-create, supplying your own metadata values. That’s the part that I first tried manually, which made me want to script it.

The bulk of the script (and the part that was a real pain) is for parsing out the metadata to pass to xbps-create. What needs to be done is:

  • pull the base-64 encoded files from the xbps database so I can re-create the install/remove scripts and other “meta” files for the package manager
  • work out naming/versioning… I guess one possibility is to simply use the same packagename and version, and then you’d just xdowngrade to the package and place it on hold to prevent any upgrades (which will have cascade effects, and is the reason holding packages isn’t a longterm solution to most problems)

I may or may not actually get to this…

However, for you immediate present and near future needs, a workaround is to make sure those packages don’t get updated (don’t update gcc!) Again, it’s definitely not a viable long term solution, but it can buy some time to breathe and reflect.

One question that remains is whether the problem could be from an asymmetric upgrade of sorts. (by which I mean something in the dependency chain that should be currently built against gcc6 didn’t get updated, but that doesn’t match up to your report of doing a -u for the whole system)

Don’t you just love problems that nobody else has, or can get to the bottom of? (I feel for you there)

(Masato the Empty) #39

On the subject of literature, it just seems that there are few “classics” of this nature in the modern era (fiction as a conveyance of philosophical ideas/speculation). Frank Herbert’s Dune series comes to mind as does some of CS Lewis’ other fiction (by other I mean non-Narnia; it seems people really read more into Narnia than Lewis himself intended).

Bit of trivia - the silent planet series was Lewis’ effort to satisfy a wager/game that he and Tolkien had going; Lewis was to write a story about space travel, and Tolkien was to write a story about time travel. Tolkien’s never got anything published, though he did attempt to base it on his middle earth mythology, specifically the “drowning of Andunie” story (related to his drafts regarding the destruction of Numenor). - source - one of Christopher Tolkien’s history of middle earth books (commentaries on the extensive unpublished works of his father).

Anyway, there are a few books out there that I’d probably find stimulating, from Dostoevsky and Tolstoy, as well as Camus’ ‘the stranger’ (also not a particularly uplifting work from what I understand) and some others. However, if I start reading philosophical works more, I have gotten into my mind that Kierkegaard is where I need to start reading, as his writings seem to be fairly appropriate to where I’ve been going in the last 5 - 10 years.


Well, that’s one of the major problems. gcc isn’t installed and the only one I can find is the current one. I assume libgcc is connected to it.

However, I have thought of a possible work-around but there are a lot of “ifs” involved. I remembered that I had synergy running early on and wondered how that could be. Well, it worked immediately after I installed it. Thus, I’m wondering if after booting, I copy the old libgcc and links to /usr/lib, then startx, and in an xterm, copy the new libgcc back in. It worked earlier today but I kept getting the shlibs error and I couldn’t get anything else installed so I’ve rebooted back into Arch. It’s kind of a duct tape and chewing gum approach, but if that’s the only library that is causing the problem, it might work. In the meantime, I’ll only update things that must be updated to install the packages I need. Perhaps the next version of libgcc won’t have the problem (I’m an incurable optimist).

No. :smile: Perhaps because far too often, it turned out I did something stupid to cause it.