Re: [gentoo-user] Qustions re Dell M.2 PCIe NVMe Solid State Drives under Gentoo
On 3/6/21 4:52 am, antlists wrote: > On 28/05/2021 17:17, Walter Dnes wrote: >>> Anything with spinning disk "is obsolete" they are trying to give it >>> way because nobody is buying them (you can buy them for few dollars), >>> don't expect it to last long. >> >> I've never had a hard drive fail on me. That includes a 2008 core2 >> duo that I shut down last autumn. Web surfing was getting painfully >> slow, and really large spreadsheets were dying in 3 gigabytes of ram, >> but otherwise it still worked. 256 G SSD is not enough for me now. >> That takes us into 512 G SSD territory, which will be "adequate" for >> now, but who knows about my future needs. >> > I've recovered (or tried to) drives for other people, but again I've > been lucky in that I've never lost one of my own drives. > > ... > > I'm planning to buy one of those shingled horrors - a Seagate BaraCuda > 12TB - for backups. Use btrfs or LVM, and rsync in-place copy. A good > idea in any case, but probably an even better idea if your main > storage is SSD. > > Cheers, > Wol Bounght a 4Tb usb3 backup drive that contains an SMR baracuda - took quite a few days to transfer the 2Tb from its predecessor. Backup (Borgbackup on btrfs) is quite fast with small changes between backup sets - miserably slow otherwise. I am still in two minds if SMR is usable (i.e., will finish before the next run is due!) in my scenario. BillK
Re: [gentoo-user] Qustions re Dell M.2 PCIe NVMe Solid State Drives under Gentoo
On 28/05/2021 17:17, Walter Dnes wrote: Anything with spinning disk "is obsolete" they are trying to give it way because nobody is buying them (you can buy them for few dollars), don't expect it to last long. I've never had a hard drive fail on me. That includes a 2008 core2 duo that I shut down last autumn. Web surfing was getting painfully slow, and really large spreadsheets were dying in 3 gigabytes of ram, but otherwise it still worked. 256 G SSD is not enough for me now. That takes us into 512 G SSD territory, which will be "adequate" for now, but who knows about my future needs. I've recovered (or tried to) drives for other people, but again I've been lucky in that I've never lost one of my own drives. And as for nVME, some magazine did a "test to destruction" of solid-state drives. They lasted almost for ever - I think the computer(s) were configured to hammer the drives 24/7 and they lasted over 18 months - that's probably a decade and more in normal usage. The one thing to watch out for, is that if you DO encounter problems, DO NOT shut the machine down. If a drive suffers failure, stage 1 seems to be to go read-only. YOU MUST back it up immediately, because stage 2 is to commit suicide on reboot. But you're highly unlikely to meet that scenario in normal use. I'm planning to buy one of those shingled horrors - a Seagate BaraCuda 12TB - for backups. Use btrfs or LVM, and rsync in-place copy. A good idea in any case, but probably an even better idea if your main storage is SSD. Cheers, Wol
Re: [gentoo-user] app-misc/ca-certificates
On 6/2/21 1:48 AM, Fannys wrote: Tech should be based on tech. Not faith and trust on the other party. That's where detection of breach of trust comes into play. Thus DNSSEC and things related. -- Grant. . . . unix || die
Re: [gentoo-user] app-misc/ca-certificates
On 6/2/21 1:21 AM, J. Roeleveld wrote: Do you know which extensions add this? I don't remember exactly (they weren't compatible with Firefox 78) but from memory, they were from the CZ NIC operator. They have many things related to this. -- Grant. . . . unix || die
[gentoo-user] Curious about order that emerge -u builds/installs
I've noticed something surprising (to me) about the order that 'emerge -auvND world' decides to install/upgrade/reinstall packages. The situation is as follows: * A large number of packages need to be build/installed/reinstalled * Hit control-C during the build of package X * Restart 'emerge -auvND world' I expect that it will start by building package X and resume with the remainder of the packages in the same order as before. Often it does not. The order of package bilds often seems to be quite different after the interruption than it was the first time -- often X is a fair ways down the list. Why is that? -- Grant
[gentoo-user] strange messages in emerge(1) output: "sandbox" broken?
Is this an error? The messages don't even say what pgm they come from: >>> Installing (1 of 103) sys-devel/automake-1.16.3-r1::gentoo * ACCESS DENIED: open_wr: /dev/tty * ACCESS DENIED: open_wr: /dev/tty * ACCESS DENIED: open_wr: /dev/null /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/ebuild.sh: line 11: /dev/null: Permission denied * ACCESS DENIED: open_wr: /dev/tty * ACCESS DENIED: open_wr: /dev/null * --- ACCESS VIOLATION SUMMARY --- * LOG FILE: "/var/tmp/portage/sys-devel/automake-1.16.3-r1/temp/sandbox.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /dev/tty A: /dev/tty R: /dev/tty C: /bin/bash -rcfile /usr/share/sandbox/sandbox.bashrc -c /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/misc-functions.sh __dyn_instprep F: open_wr S: deny P: /dev/tty A: /dev/tty R: /dev/tty C: /bin/bash /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/misc-functions.sh __dyn_instprep F: open_wr S: deny P: /dev/null A: /dev/null R: /dev/null C: /bin/bash /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/misc-functions.sh __dyn_instprep F: open_wr S: deny P: /dev/tty A: /dev/tty R: /dev/tty C: /bin/bash /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/ebuild-ipc exit 1 F: open_wr S: deny P: /dev/null A: /dev/null R: /dev/null C: /usr/bin/python3.8 /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/ebuild-ipc.py exit 1 * * ACCESS DENIED: open_wr: /dev/tty * ACCESS DENIED: open_wr: /dev/tty * ACCESS DENIED: open_wr: /dev/null /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/ebuild.sh: line 11: /dev/null: Permission denied * ACCESS DENIED: open_wr: /dev/tty * ACCESS DENIED: open_wr: /dev/null * --- ACCESS VIOLATION SUMMARY --- * LOG FILE: "/var/tmp/portage/sys-devel/automake-1.16.3-r1/temp/sandbox.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /dev/tty A: /dev/tty R: /dev/tty C: /bin/bash -rcfile /usr/share/sandbox/sandbox.bashrc -c /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/misc-functions.sh die_hooks F: open_wr S: deny P: /dev/tty A: /dev/tty R: /dev/tty C: /bin/bash /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/misc-functions.sh die_hooks F: open_wr S: deny P: /dev/null A: /dev/null R: /dev/null C: /bin/bash /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/misc-functions.sh die_hooks F: open_wr S: deny P: /dev/tty A: /dev/tty R: /dev/tty C: /bin/bash /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/ebuild-ipc exit 1 F: open_wr S: deny P: /dev/null A: /dev/null R: /dev/null C: /usr/bin/python3.8 /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/ebuild-ipc.py exit 1 * !!! instprep failed * ACCESS DENIED: open_wr: /dev/tty * ACCESS DENIED: open_wr: /dev/tty * ACCESS DENIED: open_wr: /dev/null /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/ebuild.sh: line 11: /dev/null: Permission denied * ACCESS DENIED: open_wr: /dev/tty * ACCESS DENIED: open_wr: /dev/null * --- ACCESS VIOLATION SUMMARY --- * LOG FILE: "/var/tmp/portage/sys-devel/automake-1.16.3-r1/temp/sandbox.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /dev/tty A: /dev/tty R: /dev/tty C: /bin/bash -rcfile /usr/share/sandbox/sandbox.bashrc -c /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/misc-functions.sh die_hooks F: open_wr S: deny P: /dev/tty A: /dev/tty R: /dev/tty C: /bin/bash /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/misc-functions.sh die_hooks F: open_wr S: deny P: /dev/null A: /dev/null R: /dev/null C: /bin/bash /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/misc-functions.sh die_hooks F: open_wr S: deny P: /dev/tty A: /dev/tty R: /dev/tty C: /bin/bash /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/ebuild-ipc exit 1 F: open_wr S: deny P: /dev/null A: /dev/null R: /dev/null C: /usr/bin/python3.8 /var/tmp/portage/._portage_reinstall_.um_l05vt/bin/ebuild-ipc.py exit 1 * >>> Failed to install sys-devel/automake-1.16.3-r1, Log file:
[gentoo-user] GTK Graphical Problems
Hi, At the weekend I updated my system and after reboot some of my apps have lots of black black squares/rectangles all over the place, covering all of the app window and making email difficult to write. Initially I thought this was a Wayland problem as using Wayfire but switched to X11 desktop and still had same issue. Trying all my apps this looks to be a GTK related issues as happening with claws-mail (worst), gkrellm, gcolor2, Bluefish etc. QT/EFL apps seem to be fine (qtfm, keepass). Firefox-bin works just fine, oddly. Anyone else seen this. I see a thread talking about GTK slots but not sure if this is related. I've rebuilt all gtk related packages which has not helped. John
Re: [gentoo-user] app-misc/ca-certificates
On June 2, 2021 1:51:06 AM UTC, Grant Taylor wrote: >On 6/1/21 3:38 PM, Michael Orlitzky wrote: >> *Any* CA can just generate a new key and sign the corresponding >> certificate. > >This is where what can /technically/ be done diverges from what is >/allowed/ to be done. > >CAs adhering to the CA/B Forum's requirements on CAA records mean that >they aren't allowed to issue a certificate for a domain that doesn't >list them in the CAA record. > >If a CA violates the CAA record requirement, then the CA has bigger >issues and will be subject to distrusting in mass. > >Certificate Transparency logs make it a lot easier to identify if such >shenanigans are done. -- I think that the CA/B Forum is also >requiring >C.T. Logs. > >Also, CAs /should/ *NOT* be generating keys. The keys should be >generated by the malicious party trying to pull the shenanigans that >you're talking about. > >> All browsers will treat their fake certificate corresponding to the >> fake key on their fake web server as completely legitimate. The >"real" >> original key that you generated has no special technical properties >> that distinguish it. > >Not /all/ browsers. I know people that have run browser extensions to >validate the TLS certificate that they receive against records >published >via DANE in DNS, which is protected by DNSSEC. So it's effectively >impossible for a rogue CA and malicious actor to violate that chain of >trust in a way that can't be detected and acted on. From my understanding its all based on trust and faith unless I take steps from my side. That doesnt seem very safe. Tech should be based on tech. Not faith and trust on the other party. Marinus pEpkey.asc Description: application/pgp-keys
Re: [gentoo-user] app-misc/ca-certificates
On Wednesday, June 2, 2021 12:28:49 AM CEST Fannys wrote: > On June 1, 2021 4:45:45 AM UTC, "J. Roeleveld" wrote: > >On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote: > >> On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote > >> > >> > 125 config files in /etc/ssl/certs needs update. > >> > > >> > For certificates I would expect the old and invalid ones to be > > > >replaced > > > >> > by newer ones without user intervention. > >> > > >> Looking through them is "interesting". There seem to be a lot of > >> > >> /etc/ssl/certs/.0 files, where "?" is either a random number > > > >or > > > >> a lower case letter. These all seem to be symlinks to > >> /etc/ssl/certs/.pem. Each of those files is in turn a > >> symlink to /usr/share/ca-certificates/mozilla/.crt. How > > > >much > > > >> do we trust China? There are a couple of certificates in there named > >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt and > >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt. Any > >> other suspicious regimes in there? > > > >I've always wondered about the amount of CAs that are auto-trusted on > >any > >system. Including several from countries with serious human rights > >issues. > > > >I could do with a tool where I can easily select which CAs to trust > >based on > >country. > > > >-- > >Joost > > Is there actually any tool that can let me pick my certificates? > If i go and start deleting randomly certificates from regimes i dont like > will there be any "breaking change"? I suppose firefox uses its own > certificate store though. If the CA is removed from your system/app/..., any key signed by that CA will be seen as "untrusted" (treated as if self-signed) and you need to go through the usual hoops to allow that certificate to be used. -- Joost
Re: [gentoo-user] app-misc/ca-certificates
On Wednesday, June 2, 2021 3:51:06 AM CEST Grant Taylor wrote: > On 6/1/21 3:38 PM, Michael Orlitzky wrote: > > All browsers will treat their fake certificate corresponding to the > > fake key on their fake web server as completely legitimate. The "real" > > original key that you generated has no special technical properties > > that distinguish it. > > Not /all/ browsers. I know people that have run browser extensions to > validate the TLS certificate that they receive against records published > via DANE in DNS, which is protected by DNSSEC. So it's effectively > impossible for a rogue CA and malicious actor to violate that chain of > trust in a way that can't be detected and acted on. Do you know which extensions add this?
