Re: [gentoo-user] OT: cleanup after USB backup drive unplugged?
> > I replaced it with a USB3 drive, so I needed to update the udev rules > that automatically mount it and then "umount" it when it's removed. > Pretty sure you'd risk filesystem corruption by not umounting before you remove the device. Did it used for force an fsck on each mount because the filesystem was "dirty"? If not, i have a fundamental misunderstanding of how this stuff works.
Re: [gentoo-user] OT: cleanup after USB backup drive unplugged?
On Friday, 12 January 2018 09:58:17 GMT Adam Carter wrote: > > I replaced it with a USB3 drive, so I needed to update the udev rules > > that automatically mount it and then "umount" it when it's removed. > > Pretty sure you'd risk filesystem corruption by not umounting before you > remove the device. Did it used for force an fsck on each mount because the > filesystem was "dirty"? If not, i have a fundamental misunderstanding of > how this stuff works. Yes, the sequence ought to be: sync && umount /dev/ || eject /dev/ I don't recall if eject includes the previous steps and therefore it is superfluous. I find some applications are reluctant to let go of filesystems on pluggable devices and umount can fail. In this case --lazy option of umount should work: umount -l /dev/ -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] OT: cleanup after USB backup drive unplugged?
On Fri, Jan 12, 2018 at 6:39 AM, Mick wrote: > On Friday, 12 January 2018 09:58:17 GMT Adam Carter wrote: >> >> Pretty sure you'd risk filesystem corruption by not umounting before you >> remove the device. Did it used for force an fsck on each mount because the >> filesystem was "dirty"? If not, i have a fundamental misunderstanding of >> how this stuff works. > > Yes, the sequence ought to be: > > sync && umount /dev/ || eject /dev/ > > I don't recall if eject includes the previous steps and therefore it is > superfluous. > Actually, all but umount are superfluous for a USB device. umount already ensures that all writes are written to disk - the system call does not return until the disk is completely settled. All a sync would do is force all your other filesystems to also flush their write caches, which could cause performance issues and potentially make it take longer to flush the drive you actually want to remove. There is no need to run eject on a USB drive - just pull the thing and udev will clean up the device nodes. For other busses like SATA there might be benefits to deleting the device before hot swapping them, but I'm not sure if eject actually works on those. If you umount the device, and wait for the command to terminate, then you're fine removing it. This is all somewhat orthogonal to your original question though - these are all things that you ought to do before you remove the device, not after. One thing I tend to do with scripts for backups to external devices that I don't intend to leave mounted is build the mount and umount into the backup script itself. I usually also include a check to ensure that some file/directory exists which I expect to be on the drive, which prevents the backup script from dumping a full backup into your mountpoint if it isn't mounted (possibly on a filesystem with insufficient space - actually, making /mnt a tmpfs with a tiny RAM allotment might make sense for just this reason). If you're running your backups in a service this could also be stuff that goes into the service config (esp with systemd you can make a mount a pre-req and have it automatically unmounted on termination whether successful or not; you could probably script the same sort of thing with openrc, but there is less benefit there since you don't have things like timer units to trigger them and they're not containerized/etc). -- Rich
Re: [gentoo-user] OT: cleanup after USB backup drive unplugged?
On January 12, 2018 10:58:17 AM GMT+01:00, Adam Carter wrote: >> >> I replaced it with a USB3 drive, so I needed to update the udev rules >> that automatically mount it and then "umount" it when it's removed. >> > >Pretty sure you'd risk filesystem corruption by not umounting before >you >remove the device. Did it used for force an fsck on each mount because >the >filesystem was "dirty"? If not, i have a fundamental misunderstanding >of >how this stuff works. Systemd's automount solves this nicely. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-user] Re: OT: cleanup after USB backup drive unplugged?
On 2018-01-12, Rich Freeman wrote: > On Fri, Jan 12, 2018 at 6:39 AM, Mick wrote: >> On Friday, 12 January 2018 09:58:17 GMT Adam Carter wrote: >>> >>> Pretty sure you'd risk filesystem corruption by not umounting >>> before you remove the device. That's why I don't do that. > This is all somewhat orthogonal to your original question though - > these are all things that you ought to do before you remove the > device, not after. Quite. > One thing I tend to do with scripts for backups to external devices > that I don't intend to leave mounted is build the mount and umount > into the backup script itself. Good point. That's probably what I should be doing instead of having udev mount the drive when it's plugged in. I think I'll work on that in my spare time. If I label the partition in question, it should be pretty simple... > I usually also include a check to ensure that some file/directory > exists which I expect to be on the drive, which prevents the backup > script from dumping a full backup into your mountpoint if it isn't > mounted (possibly on a filesystem with insufficient space - Yep, that's being done. The backup won't attempt to run if the external drive isn't mounted. -- Grant Edwards grant.b.edwardsYow! Inside, I'm already at SOBBING! gmail.com
Re: [gentoo-user] OT: cleanup after USB backup drive unplugged?
On Friday, 12 January 2018 13:28:39 GMT Rich Freeman wrote: > There is no need to run eject on a USB drive - just pull the thing and > udev will clean up the device nodes. One other small point: I've found that running eject on a USB drive on, say, /dev/sda marks /dev/sda unavailable for further mounts. -- Regards, Peter.
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On 01/11/18 14:41, Mick wrote: Are any of you planning to replace your Intel PCs and what are you considering as a replacement at present? I was planning to replace two of my PCs with Ryzen, but that plan was in place before Meltdown happened. At least then I'll be able to get microcode/firmware updates, as pretty much everything I own now (well, besides my laptop) is between 5-11 years old. Dan
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On 01/11/2018 05:02 PM, Rich Freeman wrote: > On Thu, Jan 11, 2018 at 5:41 PM, Mick wrote: >> Most vendors only sell Intel in their laptops. I could build a desktop I >> guess, but Ryzen is also affected by Spectre. With Intel's burning platform >> I >> want to jump off, but I'm not sure if spending money at this stage will >> materially improve my PC security ... or if it is wiser to wait for the next >> round of 'improved' CPUs. >> > I wouldn't let Spectre drive you to hold off on buying a CPU. If > you're happy with what you have stick with it. If not get what makes > the most sense, which is probably Ryzen at this point unless your > particular workload benefits from the marginal single-thread > performance of Intel even after any Meltdown handicaps. > > IMO Spectre is going to drive some microcode updates for relatively > recent CPUs, compiler improvements, and some hand-tuning of > particularly critical code. > FYI : The microcode updates pushed out for AMD by Gentoo seem to be only for : Fam16h, Fam17h CPUs. Fam15h, Fam10h, no change. "dmesg" output unchanged, before and after updating. ( Yes, the firmware update is built-in to the kernel. ) [ 0.114108] smpboot: CPU0: AMD FX(tm)-9590 Eight-Core Processor (family: 0x15, model: 0x2, stepping: 0x0) [ 0.114113] Performance Events: Fam15h core perfctr, AMD PMU driver. [ 10.296207] microcode: microcode updated early to new patch_level=0x0600084f [ 10.296915] microcode: CPU0: patch_level=0x0600084f [ 10.297658] microcode: CPU1: patch_level=0x0600084f [ 10.298338] microcode: CPU2: patch_level=0x0600084f [ 10.299093] microcode: CPU3: patch_level=0x0600084f [ 10.299813] microcode: CPU4: patch_level=0x0600084f [ 10.300502] microcode: CPU5: patch_level=0x0600084f [ 10.301193] microcode: CPU6: patch_level=0x0600084f [ 10.301849] microcode: CPU7: patch_level=0x0600084f [ 10.302601] microcode: Microcode Update Driver: v2.01 , Peter Oruba
Re: [gentoo-user] Re: glibc emerge error
On 01/11/2018 08:29 AM, Nikos Chantziaras wrote: > On 11/01/18 15:28, Corbin Bird wrote: >>> Why are you setting LD_LIBRARY_PATH system-wide to begin with? Don't >>> do that. >> >> Unfortunately, I had to ( and didn't realize the implications. ) >> In .bashrc : >>> export LD_LIBRARY_PATH=$VULKAN_SDK/lib:$LD_LIBRARY_PATH >> >> Required by the Vulkan Loader ( Mesa && Chromium ). > > I think this is what the /etc/ld.so.conf.d/ directory is there for. > Have you tried something like this instead: > > echo "$VULKAN_SDK/lib" > /etc/ld.so.conf.d/vulkan-loader.conf > env-update > > Will try this method and see what happens. Checked a file already there. In the "05gcc-x86_64-pc-linux-gnu.conf" there were no $PATH variables. Put explicit paths in instead. This will be interesting. Corbin
Re: [gentoo-user] Re: OT: cleanup after USB backup drive unplugged?
On 12/01/18 15:39, Grant Edwards wrote: >> I usually also include a check to ensure that some file/directory >> > exists which I expect to be on the drive, which prevents the backup >> > script from dumping a full backup into your mountpoint if it isn't >> > mounted (possibly on a filesystem with insufficient space - > Yep, that's being done. The backup won't attempt to run if the > external drive isn't mounted. Dunno quite how it works, but you could automate everything through udev. When I stick something in, KDE offers to mount it for me, in /run/media/$USER/abcd-efgh. I think that last bit is unique to the media, and the same every time, so you could make udev detect that something's been plugged in and, if it's your backup drive, auto-run the backup. Or, of course, if your backup expects the drive at that location, it simply refuses to run if that location doesn't exist. Cheers, Wol
[gentoo-user] Re: OT: cleanup after USB backup drive unplugged?
On 2018-01-12, Wols Lists wrote: > On 12/01/18 15:39, Grant Edwards wrote: I usually also include a check to ensure that some file/directory exists which I expect to be on the drive, which prevents the backup script from dumping a full backup into your mountpoint if it isn't mounted (possibly on a filesystem with insufficient space - > >> Yep, that's being done. The backup won't attempt to run if the >> external drive isn't mounted. > > Dunno quite how it works, but you could automate everything through > udev. Yes, that's what I was doing. The original question was what action should udev take when a USB drive is unplugged. As somebody pointed out, it's probably safer to explicity mount the drive as part of the backup operation then unmount when the backup is finished. Now, instead of having udev mount the drive when it's plugged in, the backup script handles that. > Or, of course, if your backup expects the drive at that location, it > simply refuses to run if that location doesn't exist. Right. -- Grant Edwards grant.b.edwardsYow! Is it NOUVELLE at CUISINE when 3 olives are gmail.comstruggling with a scallop in a plate of SAUCE MORNAY?
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
AMD says they are releasing microcode updates for their previous generation CPU's (Opteron, FX, etc) next week. So much better than intel throwing older CPU owners to the wolves. In terms of what CPU to get - I would get either an AMD G34/C32 Opteron (pre-PSP) with a compatible libre firmware board (KGPE-D16 or KCMA-D8) or if you can afford it a POWER9 system as IBM quickly released updates for POWER to solve this issue and if they ever stopped due to considering your system "too old" POWER9 is owner controlled and documented so the community could theoretically patch its own microcode. You can make a C32 libre firmware gaming system for around 500-700, so that is quite affordable.
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On Fri, Jan 12, 2018 at 11:23 AM, Corbin Bird wrote: > > On 01/11/2018 05:02 PM, Rich Freeman wrote: >> >> IMO Spectre is going to drive some microcode updates for relatively >> recent CPUs, compiler improvements, and some hand-tuning of >> particularly critical code. >> > > The microcode updates pushed out for AMD by Gentoo seem to be only for : > Fam16h, Fam17h CPUs. > FWIW even the 17h microcode doesn't seem to be updating on my Ryzen: dmesg | grep microco [0.989279] microcode: CPU0: patch_level=0x08001129 [0.989421] microcode: CPU1: patch_level=0x08001129 [0.989565] microcode: CPU2: patch_level=0x08001129 [0.989708] microcode: CPU3: patch_level=0x08001129 [0.989857] microcode: CPU4: patch_level=0x08001129 [0.990001] microcode: CPU5: patch_level=0x08001129 [0.990183] microcode: CPU6: patch_level=0x08001129 [0.990332] microcode: CPU7: patch_level=0x08001129 [0.990475] microcode: CPU8: patch_level=0x08001129 [0.990619] microcode: CPU9: patch_level=0x08001129 [0.990764] microcode: CPU10: patch_level=0x08001129 [0.990905] microcode: CPU11: patch_level=0x08001129 [0.991095] microcode: Microcode Update Driver: v2.2. That said, there still isn't any AMD documentation around the microcode updates that I've been able to find, so I have no idea what the correct patch level is even supposed to be. I just know that I'm not getting a message about early updates. I do have linux 4.4.13 which includes the family 17h patch. The other odd thing is that a firmware update was released for my motherboard (ASRock AB350 Pro4) on the 10th, and if I flash it grub will no longer boot the linux kernel, and it is pretty slow overall, but it will still boot memtestx86 just fine. I figured I'd wait a few days and see if there is any further info on it. -- Rich
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On Friday, 12 January 2018 17:47:46 GMT Rich Freeman wrote: > On Fri, Jan 12, 2018 at 11:23 AM, Corbin Bird wrote: > > On 01/11/2018 05:02 PM, Rich Freeman wrote: > >> IMO Spectre is going to drive some microcode updates for relatively > >> recent CPUs, compiler improvements, and some hand-tuning of > >> particularly critical code. > > > > The microcode updates pushed out for AMD by Gentoo seem to be only for : > > Fam16h, Fam17h CPUs. > > FWIW even the 17h microcode doesn't seem to be updating on my Ryzen: > > dmesg | grep microco > [0.989279] microcode: CPU0: patch_level=0x08001129 > [0.989421] microcode: CPU1: patch_level=0x08001129 > [0.989565] microcode: CPU2: patch_level=0x08001129 > [0.989708] microcode: CPU3: patch_level=0x08001129 > [0.989857] microcode: CPU4: patch_level=0x08001129 > [0.990001] microcode: CPU5: patch_level=0x08001129 > [0.990183] microcode: CPU6: patch_level=0x08001129 > [0.990332] microcode: CPU7: patch_level=0x08001129 > [0.990475] microcode: CPU8: patch_level=0x08001129 > [0.990619] microcode: CPU9: patch_level=0x08001129 > [0.990764] microcode: CPU10: patch_level=0x08001129 > [0.990905] microcode: CPU11: patch_level=0x08001129 > [0.991095] microcode: Microcode Update Driver: v2.2. My AMD: [0.025000] smpboot: CPU0: AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G (family: 0x15, model: 0x30, stepping: 0x1) is similarly failing to show signs of early microcode update, as it always did: $ dmesg | grep -i microcode [1.348991] microcode: CPU0: patch_level=0x06003106 [1.349718] microcode: CPU1: patch_level=0x06003106 [1.350434] microcode: CPU2: patch_level=0x06003106 [1.351158] microcode: CPU3: patch_level=0x06003106 [1.351879] microcode: Microcode Update Driver: v2.2. > That said, there still isn't any AMD documentation around the > microcode updates that I've been able to find, so I have no idea what > the correct patch level is even supposed to be. I just know that I'm > not getting a message about early updates. I do have linux 4.4.13 > which includes the family 17h patch. I'm on 4.14.12-gentoo now. > The other odd thing is that a firmware update was released for my > motherboard (ASRock AB350 Pro4) on the 10th, and if I flash it grub > will no longer boot the linux kernel, and it is pretty slow overall, > but it will still boot memtestx86 just fine. I figured I'd wait a few > days and see if there is any further info on it. No Asus MoBo firmware updates here ... but would they be even required/ necessary for the CPU bugs? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On Fri, Jan 12, 2018 at 1:42 PM, Mick wrote: > On Friday, 12 January 2018 17:47:46 GMT Rich Freeman wrote: > >> The other odd thing is that a firmware update was released for my >> motherboard (ASRock AB350 Pro4) on the 10th, and if I flash it grub >> will no longer boot the linux kernel, and it is pretty slow overall, >> but it will still boot memtestx86 just fine. I figured I'd wait a few >> days and see if there is any further info on it. > > No Asus MoBo firmware updates here ... but would they be even required/ > necessary for the CPU bugs? It shouldn't be. I'm not sure if Ryzen has anything equivalent to the Intel Management Engine. Intel has been scrambling to patching the firmware for that (which basically gives a hardware-level rootkit to anybody who exploits it). The official docs just mentioned adding support for additional processors with an AGESA update. I wouldn't be surprised if at some point the motherboard vendors slip in the microcode updates there as well. When I was having issues getting linux to update the microcode I figured I'd check the firmware for updates. When it failed to boot I just rolled it back. They actually did 2 firmware releases, with one being used as a bridge to the other. That also makes me wonder if there is a microcode update of some kind in there. -- Rich
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On 01/12/2018 12:42 PM, Mick wrote: > On Friday, 12 January 2018 17:47:46 GMT Rich Freeman wrote: >> On Fri, Jan 12, 2018 at 11:23 AM, Corbin Bird > wrote: >>> On 01/11/2018 05:02 PM, Rich Freeman wrote: IMO Spectre is going to drive some microcode updates for relatively recent CPUs, compiler improvements, and some hand-tuning of particularly critical code. >>> The microcode updates pushed out for AMD by Gentoo seem to be only for : >>> Fam16h, Fam17h CPUs. >> FWIW even the 17h microcode doesn't seem to be updating on my Ryzen: >> >> dmesg | grep microco >> [0.989279] microcode: CPU0: patch_level=0x08001129 >> [0.989421] microcode: CPU1: patch_level=0x08001129 >> [0.989565] microcode: CPU2: patch_level=0x08001129 >> [0.989708] microcode: CPU3: patch_level=0x08001129 >> [0.989857] microcode: CPU4: patch_level=0x08001129 >> [0.990001] microcode: CPU5: patch_level=0x08001129 >> [0.990183] microcode: CPU6: patch_level=0x08001129 >> [0.990332] microcode: CPU7: patch_level=0x08001129 >> [0.990475] microcode: CPU8: patch_level=0x08001129 >> [0.990619] microcode: CPU9: patch_level=0x08001129 >> [0.990764] microcode: CPU10: patch_level=0x08001129 >> [0.990905] microcode: CPU11: patch_level=0x08001129 >> [0.991095] microcode: Microcode Update Driver: v2.2. > My AMD: > > [0.025000] smpboot: CPU0: AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G > (family: 0x15, model: 0x30, stepping: 0x1) > > is similarly failing to show signs of early microcode update, as it always > did: > > $ dmesg | grep -i microcode > [1.348991] microcode: CPU0: patch_level=0x06003106 > [1.349718] microcode: CPU1: patch_level=0x06003106 > [1.350434] microcode: CPU2: patch_level=0x06003106 > [1.351158] microcode: CPU3: patch_level=0x06003106 > [1.351879] microcode: Microcode Update Driver: v2.2. > > >> That said, there still isn't any AMD documentation around the >> microcode updates that I've been able to find, so I have no idea what >> the correct patch level is even supposed to be. I just know that I'm >> not getting a message about early updates. I do have linux 4.4.13 >> which includes the family 17h patch. > I'm on 4.14.12-gentoo now. > > >> The other odd thing is that a firmware update was released for my >> motherboard (ASRock AB350 Pro4) on the 10th, and if I flash it grub >> will no longer boot the linux kernel, and it is pretty slow overall, >> but it will still boot memtestx86 just fine. I figured I'd wait a few >> days and see if there is any further info on it. > No Asus MoBo firmware updates here ... but would they be even required/ > necessary for the CPU bugs? In the old days, Windows / DOS, did not have any "microcode update loader". For those old versions of Windows / DOS, an updated BIOS was the only way to update the CPU microcode. I have seen something calling itself the "microcode update loader" in Win 7 x64. Have no idea what it is really doing. --- The Fam16h and Fam17h microcode updates were new to Gentoo? I don't recall ever seeing them before. Corbin
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On Fri, Jan 12, 2018 at 2:58 PM, Corbin Bird wrote: > > The Fam16h and Fam17h microcode updates were new to Gentoo? > I don't recall ever seeing them before. > They're new in general - they first appeared last week and they're being treated as if they're related to Spectre. I've yet to see any kind of official release of them, but that seems to be par for the course for AMD the more I hunt around for documentation. It seems like Suse first released it, and claimed that it disabled branch prediction, whatever that means (certainly it can't completely disable it without tanking performance). I'm not sure if it has been merged upstream yet. The 17h loader updates were merged into linux 4.4.13 (Gentoo backported it as well), but I'm not sure about the microcode itself. Separately there are some lkml patches proposed by AMD to use an MSR setting to make LFENCE block speculative execution. It looks like the strategy is to enable that on amd64, and verify that the setting took (a guest VM wouldn't be able to set the MSR). If the setting isn't effective then it would fall back to Retpolines (which is the Intel fix for Spectre), which have more overhead (this is in addition to the much larger overhead for the meltdown fix on Intel). If somebody actually sees anything official from AMD clearly giving a checklist for Spectre remediation I'm all ears. To its credit, Intel at least published one of those (even if it amounts to "pound sand" for older CPUs). -- Rich
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On 01/12/2018 02:06 PM, Rich Freeman wrote: It shouldn't be. I'm not sure if Ryzen has anything equivalent to the Intel Management Engine. It does, it is called AMD PSP. Like ME it is closed source and it can't be disabled - no matter what people might claim.
Re: [gentoo-user] Re: OT: cleanup after USB backup drive unplugged?
On Fri, 12 Jan 2018 16:42:25 +, Wols Lists wrote: > Dunno quite how it works, but you could automate everything through > udev. When I stick something in, KDE offers to mount it for me, in > /run/media/$USER/abcd-efgh. > > I think that last bit is unique to the media, and the same every time, > so you could make udev detect that something's been plugged in and, if > it's your backup drive, auto-run the backup. Be careful with that, because udev blocks while any RUN command is executed, so make sure whatever you run detaches immediately. -- Neil Bothwick One-seventh of life is spent on Monday. pgp3g63byTXDs.pgp Description: OpenPGP digital signature
[gentoo-user] Re: glibc emerge error
On 12/01/18 18:31, Corbin Bird wrote: On 01/11/2018 08:29 AM, Nikos Chantziaras wrote: On 11/01/18 15:28, Corbin Bird wrote: Why are you setting LD_LIBRARY_PATH system-wide to begin with? Don't do that. Unfortunately, I had to ( and didn't realize the implications. ) In .bashrc : export LD_LIBRARY_PATH=$VULKAN_SDK/lib:$LD_LIBRARY_PATH Required by the Vulkan Loader ( Mesa && Chromium ). I think this is what the /etc/ld.so.conf.d/ directory is there for. Have you tried something like this instead: echo "$VULKAN_SDK/lib" > /etc/ld.so.conf.d/vulkan-loader.conf env-update Will try this method and see what happens. Checked a file already there. In the "05gcc-x86_64-pc-linux-gnu.conf" there were no $PATH variables. Put explicit paths in instead. This will be interesting. Yes, you do add explicit paths in it. This: echo "$VULKAN_SDK/lib" > /etc/ld.so.conf.d/vulkan-loader.conf will write an explicit path (the variable is expanded by the shell.)
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
> > If somebody actually sees anything official from AMD clearly giving a > checklist for Spectre remediation I'm all ears. To its credit, Intel > at least published one of those (even if it amounts to "pound sand" > for older CPUs). > AMD have revised their guidance on Variant 2 from "near zero risk" to "difficult" http://www.amd.com/en/corporate/speculative-execution
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
> They're new in general - they first appeared last week and they're > being treated as if they're related to Spectre. I've yet to see any > kind of official release of them, but that seems to be par for the > course for AMD the more I hunt around for documentation. It seems > like Suse first released it, and claimed that it disabled branch > prediction, whatever that means (certainly it can't completely disable > it without tanking performance). > From: https://www.phoronix.com/scan.php?page=news_item&px=AMD-Branch-Prediction-Still "I reached out to AMD and on Friday heard back. They wrote in an email to Phoronix that this Zen/17h microcode update does *not* disable branch prediction. They'll be working with SUSE to re-clarify this microcode update description"
Re: [gentoo-user] Re: glibc emerge error
On 01/12/2018 04:14 PM, Nikos Chantziaras wrote: > echo "$VULKAN_SDK/lib" > /etc/ld.so.conf.d/vulkan-loader.conf Found out what was giving me an extra slash in the output "...x86_64//lib" The $VULKAN_SDK PATH had a slash at the end. Works now. Thank you. Corbin
