Re: [gentoo-user] Is sys-firmware/intel-microcode-20180108 complete?
On Thursday, 11 January 2018 05:08:01 GMT Adam Carter wrote: > Looks like there was an issue with intel-microcode-20180108. > > 50/94 files are different from intel-microcode-20171117_p20171215-r1 to > intel-microcode-20180108-r1, they are; --->8 Thanks for the info. My 03-06-f2 isn't in the list, I see. -- Regards, Peter.
Re: [gentoo-user] glibc emerge error
On 01/10/2018 12:22 PM, Matthias Hanft wrote: > Corbin Bird wrote: >> Is anyone else having a sys-libs/glibc emerge compile failure? >>> *** LD_LIBRARY_PATH shouldn't contain the current directory when >>> *** building glibc. Please change the environment variable >>> *** and run configure again. >> Same error regardless of the version of glibc I attempt to emerge. > Sure - this error always comes up here, too. Just enter > > export LD_LIBRARY_PATH= > > immediately before emerge, and it works. > > -Matt > > PS: And if you get some message concerning some variables which > are too big (or something like that), enter > mount -t tmpfs none /var/tmp/portage > just before emerge (and "umount /var/tmp/portage" afterwards). > I have to do this for the emerge of a few packages - I think > it's because of my 17 TB filesystem. > > Thanks, that fixed it. Corbin
Re: [gentoo-user] Re: glibc emerge error
On 01/10/2018 01:53 PM, Nikos Chantziaras wrote: > On 10/01/18 19:55, Corbin Bird wrote: >> Is anyone else having a sys-libs/glibc emerge compile failure? >> >>> checking for python3... python3 >>> checking LD_LIBRARY_PATH variable... contains current directory >>> configure: error: >>> *** LD_LIBRARY_PATH shouldn't contain the current directory when >>> *** building glibc. Please change the environment variable >>> *** and run configure again. >>> * ERROR: sys-libs/glibc-2.25-r10::gentoo failed (configure phase): >>> * failed to configure glibc >> >> sys-libs/glibc-2.25-r9 was set to masked / prompting this upgrade / >> re-compile: >> >> https://packages.gentoo.org/packages/sys-libs/glibc >> >> Same error regardless of the version of glibc I attempt to emerge. > > 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 ). Corbin
[gentoo-user] Re: glibc emerge error
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
[gentoo-user] OT: cleanup after USB backup drive unplugged?
[This has nothing to do specifically with Gentoo.]
What cleanup actions would you have put in a script to be triggered by
udev when a USB or Firewire backup drive has been unplugged?
The external Firewire drive I used for nightly backups died yesterday.
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.
Both rules are firing when they should:
KERNEL=="sd?1",\
SUBSYSTEMS=="scsi",\
ENV{ID_SERIAL}=="WD_My_Passport_259F_57584A314143353435594B54-0:0",\
ACTION=="add",\
SYMLINK+="passport",\
RUN+="/bin/mount -text4 -o atime /dev/%k /extbackup"
KERNEL=="sd?1",\
ACTION=="remove",\
ENV{ID_SERIAL}=="WD_My_Passport_259F_57584A314143353435594B54-0:0",\
RUN+="/usr/local/bin/myumount /extbackup"
Here's the embarassing part: The /usr/local/bin/myumount script went
missing (backup drive is dead), and I can't recall exactly what it
did. Obviously, one should never unplug the drive while it's mounted,
but if that _does_ happen, what would one put in myumount to mitigate
the situation.
The only think I can think of is to do a "umount -l".
--
Grant Edwards grant.b.edwardsYow! How many retured
at bricklayers from FLORIDA
gmail.comare out purchasing PENCIL
SHARPENERS right NOW??
[gentoo-user] Re: glibc emerge error
On 2018-01-11 07:28, Corbin Bird wrote:
> > export LD_LIBRARY_PATH=$VULKAN_SDK/lib:$LD_LIBRARY_PATH
This is wrong, because it will put the current directory (as represented
by the empty string) into the list even if it wasn't there originally.
Try something like this (untested):
export LD_LIBRARY_PATH=$VULKAN_SDK/lib${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"}
see man bash, "Parameter expansion".
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On Wednesday, 10 January 2018 01:46:08 GMT Rich Freeman wrote: > On Tue, Jan 9, 2018 at 8:33 PM, Corbin Bird wrote: > > On 01/09/2018 01:56 AM, Mick wrote: > > > > At this point, the only sure bet, is a non x86, x86_64, ARM, ARM64 CPU. > > > > Don't know enough to make a recommendation on a particular CPU arch at > > this > > point. > > Good luck with that... > > If you aren't hearing about Spectre fixes for a CPU it is most likely > because it is so obscure that nobody has bothered to check whether it > is vulnerable. > > Sure, there are some CPUs that have been tested and found to be ok. > However, almost anything modern is vulnerable to spectre. I just > wasn't something that was on anybody's radar. New CPUs are likely to > be resistant to these types of attacks regardless of vendor. Yes, but I would be surprised if new 'fixed' CPUs land anytime before 2019 ... if not 2020. I'd rather not be running an old Intel i7 which has not had its microcode patched all the way until then - if the complimentary microcode patch is *also* improving security besides speed, after the consequential kernel patches. > Sure, if I was about to place an order for 1000 CPUs tomorrow I'd > probably pick AMD over Intel to avoid the PTI overhead, but that is > about as far as I'd let these vulnerabilities affect purchase > decisions. There are lots of good reasons to go with ARM vs x86, but > this isn't really one of them. And outside of x86/ARM I think almost > any other CPU choice is going to be a niche item. I've seen Linus making statements back in 2016 of the year of the ARM laptop being upon us (Chromebook anyone?) and I've seen the 10nm Qualcomm Snapdragon 835 ARM laptop by Asus featuring on CES 2018 with impressively long battery life, but I have no idea how it compares in performance terms with the equally vulnerable current x86 arch machines. That may be a different discussion anyway. 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. Are any of you planning to replace your Intel PCs and what are you considering as a replacement at present? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
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. -- Rich
