Re: [gentoo-user] Python:2.7 and removing it early
el 2020-05-04 a las 21:56 antlists escribió: > Another app that's 2.7 only is the current version of lilypond. The new > dev version I think can run without python2, but certainly building the > stable version demands it. I *think* if you get the pre-compiled binary > the current version can run (crippled) without python2. re lilypond, please see bug 720422: https://bugs.gentoo.org/720422 there's an ebuild for lilypond-2.21.1, that builds with python 3.7 (and with guile 2.2). --
Re: [gentoo-user] Python:2.7 and removing it early
On 04/05/2020 20:57, Dale wrote: Alessandro Barbieri wrote: At least gimp-help scribus nut fbpanel are Python2 only, didn't check stuff from overlays That makes sense. I can see where some can work with old and new python but some appeared to be still stuck on the old 2.7. Guess I'll have to wait since I use those. Maybe they will be updated soon. Another app that's 2.7 only is the current version of lilypond. The new dev version I think can run without python2, but certainly building the stable version demands it. I *think* if you get the pre-compiled binary the current version can run (crippled) without python2. Cheers, Wol
Re: [gentoo-user] AMD Radeon R7 370 (Pitcairn) causing the bootup to hang
On Mon, May 04, 2020 at 08:53:18PM +1000, Adam Carter wrote: > What CONFIG_FB options are enabled? I dont have CONFIG_FB_EFI set to try > removing that. I can't disable FB_EFI as I want to use the E.F.I.\ framebuffer as my terminal. Nonetheless, I have just discovered I am a useless article of the highest degree; `dmesg` revealed the firmware should have been in /lib/firmware/amdgpu, as opposed to /lib/firmware/radeon. I should have figured this out myself sooner, although the entry for Southern Islands cards at [1] should also probably be updated, considering it is focusing entirely on the AMDGPU driver. Adam and Peter: Cheers for the help, and I apologise for wasting your time. [1] https://wiki.gentoo.org/wiki/AMDGPU#Incorporating_firmware -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] Python:2.7 and removing it early
Alessandro Barbieri wrote: > At least > gimp-help > scribus > nut > fbpanel > are Python2 only, didn't check stuff from overlays > That makes sense. I can see where some can work with old and new python but some appeared to be still stuck on the old 2.7. Guess I'll have to wait since I use those. Maybe they will be updated soon. Thanks much. Dale :-) :-)
Re: [gentoo-user] Python:2.7 and removing it early
At least gimp-help scribus nut fbpanel are Python2 only, didn't check stuff from overlays Il Lun 4 Mag 2020, 18:31 Dale ha scritto: > Howdy, > > As some know, python 2.7 is leaving the building. I'm wanting to try to > clean it out a bit now, a little at a time if needed. I found some > commands on -dev that shows what still depends on python 2.7. Thing is, > I think it is listing packages that *may* use 2.7 but can or is set to > use a newer version. In other words, I'm getting false positives. > Another command returns nothing and I think that command shows what > requires *only* python 2.7 and no newer version. Thing is, when I do a > emerge -ac python:2.7, it spits out a list of packages that says they > need it. It's confusing to say the least. I think I'm on information > overload or something. > > What I don't want to do, add targets to make.conf that may change > defaults later on. In other words, I don't want to add the target line > and then later on forget it is there and it bite me when say 3.6 is > leaving the building. I think if I can get it to where I can remove > python 2.7's package, it will leave it buried. How to get there tho?? > > I don't want to attach a ton of info that may not be relevant. I'm > going to share this tho. If anyone needs more info, let me know and > I'll post it. > > > root@fireball / # emerge -ca python:2.7 > > Calculating dependencies... done! > dev-lang/python-2.7.18 pulled in by: > app-doc/gimp-help-2.8.2 requires >=dev-lang/python-2.7.5-r2:2.7 > app-office/scribus-1.5.5-r1 requires >=dev-lang/python-2.7.5-r2:2.7 > app-portage/gemato-14.3 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-lang/spidermonkey-1.8.5-r7 requires > >=dev-lang/python-2.7.5-r2:2.7[threads] > dev-lang/spidermonkey-60.5.2_p0-r4 requires > >=dev-lang/python-2.7.5-r2:2.7[ncurses,sqlite,ssl,threads] > dev-libs/boost-1.72.0-r1 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-libs/libxml2-2.9.9-r3 requires >=dev-lang/python-2.7.5-r2:2.7[xml] > dev-python/PyQt5-5.14.2 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/PyQt5-sip-4.19.22 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/PySocks-1.7.1 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/backports-1.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/backports-lzma-0.0.13 requires > >=dev-lang/python-2.7.5-r2:2.7 > dev-python/bz2file-0.98 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/certifi-2019.11.28 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/cffi-1.14.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/chardet-3.0.4 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/cryptography-2.8-r1 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/cython-0.29.15 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/dbus-python-1.2.16 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/docutils-0.16 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/enum34-1.1.6-r1 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/idna-2.8 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/ipaddress-1.0.23 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/lxml-4.5.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/mako-1.1.2 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/markupsafe-1.1.1 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/numpy-1.16.5-r1 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/olefile-0.46 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pathlib2-2.3.5 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pbr-4.2.0-r1 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/pillow-6.2.2 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/ply-3.11 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pyblake2-1.1.2 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pycairo-1.18.2 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/pyclipper-1.1.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pycparser-2.20 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pycryptodome-3.9.4 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/pygments-2.5.2 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pygobject-2.28.6-r55 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pygobject-3.34.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pygtk-2.24.0-r5 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pyopengl-3.1.0 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pyopenssl-19.1.0 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)] > dev-python/python-gammu-2.11 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pyyaml-5.3.1 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/requests-2.23.0 requires > >=dev-lang/python-2.7.5-r2:2.7[threads(+)]
Re: [gentoo-user] Getting rid of unwanted languages (Was: Re: gimp help not available, even with USE doc)
On Mon, May 4, 2020, at 20:11, Michael Jones wrote: > I can't find any documentation on the use of "LANG" or "LANGUAGE" in > /etc/portage/make.conf. > > I'm looking here: https://wiki.gentoo.org/wiki//etc/portage/make.conf#LINGUAS > > Is there another source that describes these variables and how to use them? Please see: https://wiki.gentoo.org/wiki/Localization/Guide -- https://fturco.net/
Re: [gentoo-user] Getting rid of unwanted languages (Was: Re: gimp help not available, even with USE doc)
On Mon, May 4, 2020 at 10:31 AM Peter Humphrey wrote: > On Monday, 4 May 2020 15:08:12 BST Dr Rainer Woitok wrote: > > Here are mine for comparison: > > # grep -E '^(LANG|LC_|L10)' /etc/portage/make.conf > L10N="en-GB en" > LANG="en_GB.UTF-8" > LANGUAGE="en_GB.UTF-8" > > I can't find any documentation on the use of "LANG" or "LANGUAGE" in /etc/portage/make.conf. I'm looking here: https://wiki.gentoo.org/wiki//etc/portage/make.conf#LINGUAS Is there another source that describes these variables and how to use them?
[gentoo-user] Python:2.7 and removing it early
Howdy, As some know, python 2.7 is leaving the building. I'm wanting to try to clean it out a bit now, a little at a time if needed. I found some commands on -dev that shows what still depends on python 2.7. Thing is, I think it is listing packages that *may* use 2.7 but can or is set to use a newer version. In other words, I'm getting false positives. Another command returns nothing and I think that command shows what requires *only* python 2.7 and no newer version. Thing is, when I do a emerge -ac python:2.7, it spits out a list of packages that says they need it. It's confusing to say the least. I think I'm on information overload or something. What I don't want to do, add targets to make.conf that may change defaults later on. In other words, I don't want to add the target line and then later on forget it is there and it bite me when say 3.6 is leaving the building. I think if I can get it to where I can remove python 2.7's package, it will leave it buried. How to get there tho?? I don't want to attach a ton of info that may not be relevant. I'm going to share this tho. If anyone needs more info, let me know and I'll post it. root@fireball / # emerge -ca python:2.7 Calculating dependencies... done! dev-lang/python-2.7.18 pulled in by: app-doc/gimp-help-2.8.2 requires >=dev-lang/python-2.7.5-r2:2.7 app-office/scribus-1.5.5-r1 requires >=dev-lang/python-2.7.5-r2:2.7 app-portage/gemato-14.3 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-lang/spidermonkey-1.8.5-r7 requires >=dev-lang/python-2.7.5-r2:2.7[threads] dev-lang/spidermonkey-60.5.2_p0-r4 requires >=dev-lang/python-2.7.5-r2:2.7[ncurses,sqlite,ssl,threads] dev-libs/boost-1.72.0-r1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-libs/libxml2-2.9.9-r3 requires >=dev-lang/python-2.7.5-r2:2.7[xml] dev-python/PyQt5-5.14.2 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/PyQt5-sip-4.19.22 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/PySocks-1.7.1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/backports-1.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/backports-lzma-0.0.13 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/bz2file-0.98 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/certifi-2019.11.28 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/cffi-1.14.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/chardet-3.0.4 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/cryptography-2.8-r1 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/cython-0.29.15 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/dbus-python-1.2.16 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/docutils-0.16 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/enum34-1.1.6-r1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/idna-2.8 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/ipaddress-1.0.23 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/lxml-4.5.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/mako-1.1.2 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/markupsafe-1.1.1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/numpy-1.16.5-r1 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/olefile-0.46 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pathlib2-2.3.5 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pbr-4.2.0-r1 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/pillow-6.2.2 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/ply-3.11 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pyblake2-1.1.2 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pycairo-1.18.2 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/pyclipper-1.1.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pycparser-2.20 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pycryptodome-3.9.4 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/pygments-2.5.2 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pygobject-2.28.6-r55 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pygobject-3.34.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pygtk-2.24.0-r5 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pyopengl-3.1.0 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pyopenssl-19.1.0 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/python-gammu-2.11 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/pyyaml-5.3.1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/requests-2.23.0 requires >=dev-lang/python-2.7.5-r2:2.7[threads(+)] dev-python/scandir-1.10.0-r1 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/setuptools-44.1.0 requires >=dev-lang/python-2.7.5-r2:2.7[xml(+)] dev-python/setuptools-git-1.2 requires >=dev-lang/python-2.7.5-r2:2.7 dev-python/setuptools_scm-3.5.0 requires >=dev-lang/python-2.7.5-r2:2.7
Re: [gentoo-user] Getting rid of unwanted languages (Was: Re: gimp help not available, even with USE doc)
On Monday, 4 May 2020 15:08:12 BST Dr Rainer Woitok wrote: Here are mine for comparison: # grep -E '^(LANG|LC_|L10)' /etc/portage/make.conf L10N="en-GB en" LANG="en_GB.UTF-8" LANGUAGE="en_GB.UTF-8" # env | grep -E '^(LANG|LC_|L10)' LANG=en_GB.utf8 # locale -a C C.utf8 en_GB en_GB.iso88591 en_GB.iso885915 en_GB.utf8 POSIX # localedef --list-archive C.utf8 en_GB en_GB.iso88591 en_GB.iso885915 en_GB.utf8 ># grep -E '^(LANG|LC_|L10)' /etc/portage/make.conf >L10N="en-GB" >LANG="en_GB" >LC_MESSAGES="C" ># env | grep -E '^(LANG|LC_|L10)' >LANG=en_GB.utf8 >LANGUAGE=en_GB:en_US:en >LC_ADDRESS=en_GB.UTF-8 >LC_COLLATE=C >LC_IDENTIFICATION=en_GB.UTF-8 >LC_MEASUREMENT=en_GB.UTF-8 >LC_MONETARY=en_GB.UTF-8 >LC_NAME=en_GB.UTF-8 >LC_NUMERIC=en_GB.UTF-8 >LC_PAPER=en_GB.UTF-8 >LC_TELEPHONE=en_GB.UTF-8 >LC_TIME=en_GB.UTF-8 ># locale -a >C >C.utf8 >POSIX >en_GB.utf8 ># localedef --list-archive >C.utf8 >en_GB.utf8 What do you have in your kernel config, under File Systems / Native Language Support? I only have a few selected: the ones I might use. (This may be a red herring.) -- Regards, Peter.
Re: [gentoo-user] Getting rid of unwanted languages (Was: Re: gimp help not available, even with USE doc)
Michael, On Thursday, 2020-04-30 16:43:06 +0100, you wrote: > ... > https://wiki.gentoo.org/wiki/Localization/Guide#L10N > > Meanwhile, I think the equivalent to debian's localepurge corresponds to a > dual step process in Gentoo. First update your locale as per above page, > then > run 'env-update && source /etc/profile', followed by 'localegen'. Then if > you > have also setup additional localisations in L10N, you need to run emerge with > option --newuse, or --changeduse to take account per package or global > changes > in the L10N USE settings. Doesn't seem to work: # grep -E '^(LANG|LC_|L10)' /etc/portage/make.conf L10N="en-GB" LANG="en_GB" LC_MESSAGES="C" # env | grep -E '^(LANG|LC_|L10)' LANG=en_GB.utf8 LANGUAGE=en_GB:en_US:en LC_ADDRESS=en_GB.UTF-8 LC_COLLATE=C LC_IDENTIFICATION=en_GB.UTF-8 LC_MEASUREMENT=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_NAME=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_PAPER=en_GB.UTF-8 LC_TELEPHONE=en_GB.UTF-8 LC_TIME=en_GB.UTF-8 # locale -a C C.utf8 POSIX en_GB.utf8 # localedef --list-archive C.utf8 en_GB.utf8 # emerge --ask --changed-deps --deep --newuse --update \ --verbose-conflicts --with-bdeps=y @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild rR ~] dev-libs/libjcat-0.1.1 Would you like to merge these packages? [Yes/No] no Quitting. Package "dev-libs/libjcat" does in fact have a "man" USE flag, and it provides a single manual page, "/usr/share/man/man1/jcat-tool.1.bz2". I don't know for sure though whether my adding 'LANG="en_GB"' to "/etc/ portage/make.conf" and doing all the magic in the Gentoo Locaization Guide caused Portage's desire to re-emerge that package or something totally different. But there are other packages installed with the "man" USE flag, which didn't even flinch. In particular there is package "sys-apps/shadow" which among other things provides the "passwd" command and which doesn't honour the "man" USE flag at all, but is quite polyglot: # cd /usr/share/man # find . -type f -name 'passwd*' ./ru/man1/passwd.1.bz2 ./man1/passwd.1.bz2 ./sv/man1/passwd.1.bz2 ./man3/passwd2des.3 ./ja/man1/passwd.1.bz2 ./it/man1/passwd.1.bz2 ./fr/man1/passwd.1.bz2 ./hu/man1/passwd.1.bz2 ./de/man1/passwd.1.bz2 ./tr/man1/passwd.1.bz2 ./zh_CN/man1/passwd.1.bz2 ./man5/passwd.5.bz2 # So the question how to get rid of all these unnecessary languages is still open. Sincerely, Rainer
Re: [gentoo-user] AMD Radeon R7 370 (Pitcairn) causing the bootup to hang
On Monday, 4 May 2020 01:21:09 BST Ashley Dixon wrote: > Any help with this would be appreciated. I'm moving away from NVIDIA due to > the requirement of proprietary drivers to get any decent performance, > however now it feels as though the AMD drivers, although open-source, > consist of too many bugs (such as hanging the boot-up process for some > reason or another) to be of any actual use. Whilst I'm aware that is > obviously not the case due to the popularity of their cards, I am > bewildered at how difficult this seems. I have a Radeon Pro WX 5100, which uses a Polaris chipset. I don't know whether it's Polaris10, ..11 or ..12 so I have all three installed. Together with linux-firmware 20200421 and a corresponding savedconfig file. I know it's not the same as yours, but there must be some similarities. Referring to the Wiki you cite, I don't have AMDGPU support for SI or CIK parts. DRM_AMDGPU_USERPTR=y. Under Display Engine Configuration, only the first option shown in the Wiki is present in my kernel config (5.4.28), but it has an option DSC support, which is Y. HSA kernel driver is Y, not M. I don't have any PCI sound device entries since my on-board chipset failed. It's important to set DRM_AMDGPU=y, not =m, so that the necessary drivers are all present at boot time. Or you could include them in an initramfs. Do you have CONFIG_FB_EFI=y and CONFIG_FB_SIMPLE=y? Your problem may be in handing over the console to the frame buffer - I think I remember having difficulty here as well. CONFIG_FB_RADEON is not set here. Contrary to the Wiki, I don't have Laptop Hybrid Graphics set, because this isn't a laptop and I don't want any of the switcheroo it would bring in. Then again, the Wiki may just want it for debugging. /etc/environment is empty here. I hope that helps, even if only to eliminate some possibilities. -- Regards, Peter.
Re: [gentoo-user] AMD Radeon R7 370 (Pitcairn) causing the bootup to hang
On Mon, May 4, 2020 at 10:21 AM Ashley Dixon wrote: > Hi gentoo-user, > > I'm attempting to configure a mid-range video card: the Radeon R7 370. > Running > on the Pitcairn chipset and a member of the Southern Islands family, > I am > surprised at the complexity of setting up the Radeon driver in comparison > to its > NVIDIA counterpart. > > I followed [1] carefully. Initially opting to compile AMDGPU into the > kernel, I > emerged linux-firmware with the following files. All of the relevant > files were > added to the kernel's CONFIG_EXTRA_FIRMWARE string, using /lib/firmware > as the > base directory. > > radeon/pitcairn_smc.bin > radeon/pitcairn_ce.bin > radeon/pitcairn_mc.bin > radeon/pitcairn_me.bin > radeon/pitcairn_pfp.bin > radeon/pitcairn_k_smc.bin > radeon/pitcairn_rlc.bin > radeon/TAHITI_uvd.bin > radeon/TAHITI_vce.bin > Did it load ok? dmesg | grep -i drm.*firm You should see; [drm] Found UVD firmware Version etc [drm] Found VCE firmware Version etc > Unfortunately, upon booting, the kernel hangs with the following message. > This > seems to be rather common, with a similar complaint being discussed > at [2]. > > fb0: switching to amdgpudrmfb from EFI VGA > Here's what i get (R9 380) # dmesg | grep -i fb0 [1.302701] fbcon: amdgpudrmfb (fb0) is primary device [1.474076] amdgpu :01:00.0: fb0: amdgpudrmfb frame buffer device What CONFIG_FB options are enabled? I dont have CONFIG_FB_EFI set to try removing that. > As this all occurs pre-OpenRC, I am incapable of creating an S.S.H.\ > connection > to the machine from my laptop. When booting the kernel with the > `nomodesetting` > parameter, the X server reports the following after a successful > kernel boot > (created when executing `startx`): [timestamps omitted] > > (EE) Failed to load module "fbdev" (module does not exist, 0) > (II) LoadModule: "vesa" > (WW) Warning, couldn't open module vesa > (EE) Failed to load module "vesa" (module does not exist, 0) > (II) RADEON: Driver for ATI/AMD Radeon chipsets: > ATI Radeon Mobility X600 (M24), ATI FireMV 2400, > ATI Radeon Mobility X300 (M24), ATI FireGL M24 GL, > > [...] > > ARUBA, TAHITI, PITCAIRN, VERDE, OLAND, HAINAN, BONAIRE, > KABINI, > MULLINS, KAVERI, HAWAII > (II) modesetting: Driver for Modesetting Kernel Drivers: kms > (--) using VT number 7 > > (II) [KMS] drm report modesetting isn't supported. > (EE) open /dev/dri/card0: No such file or directory > (WW) Falling back to old probe method for modesetting > (EE) open /dev/dri/card0: No such file or directory > I'd say that's the key. What CONFIG_DRM options are enabled?
Re: [gentoo-user] which linux RAID setup to choose?
On 4/5/20 3:50 pm, hitachi303 wrote: > Am 04.05.2020 um 02:46 schrieb Rich Freeman: >> On Sun, May 3, 2020 at 6:50 PM hitachi303 >> wrote: >> ... > So you are right. This is the way they do it. I used the term raid to > broadly. > But still they have problems with limitations. Size of room, what air > conditioning can handle and stuff like this. > > Anyway I only wanted to point out that there are different approaches > in the industries and saving the data at any price is not always > necessary. > I would suggest that once you go past a few drives there are better ways. I had two 4 disk, bcache fronted raid 10's on two PC'cs with critical data backed up between them. When an ssd bcache failed in one, and two backing stores in the other almost simultaneously I nearly had to resort to offline backups to restore the data ... downtime was still a major pain. I now have a 5 x cheap arm systems and a small x86 master with 7 disks across them - response time is good, power use seems less (being much cooler, quieter) than running two over the top older PC's. The reliability/recovery time (at least when I tested by manually failing drives and causing power outages) is much better. I am using moosefs, but lizardfs looks similar and both can offer erasure coding which gives more storage space still with recovery if you have enough disks. Downside is maintaining more systems, more complex networking and the like - Its been a few months now, and I wont be going back to raid for my main storage. BillK pEpkey.asc Description: application/pgp-keys
Re: [gentoo-user] which linux RAID setup to choose?
Am 04.05.2020 um 02:46 schrieb Rich Freeman: On Sun, May 3, 2020 at 6:50 PM hitachi303 wrote: The only person I know who is running a really huge raid ( I guess 2000+ drives) is comfortable with some spare drives. His raid did fail an can fail. Data will be lost. Everything important has to be stored at a secondary location. But they are using the raid to store data for some days or weeks when a server is calculating stuff. If the raid fails they have to restart the program for the calculation. So, if you have thousands of drives, you really shouldn't be using a conventional RAID solution. Now, if you're just using RAID to refer to any technology that stores data redundantly that is one thing. However, if you wanted to stick 2000 drives into a single host using something like mdadm/zfs, or heaven forbid a bazillion LSI HBAs with some kind of hacked-up solution for PCIe port replication plus SATA bus multipliers/etc, you're probably doing it wrong. (Really even with mdadm/zfs you probably still need some kind of terribly non-optimal solution for attaching all those drives to a single host.) At that scale you really should be using a distributed filesystem. Or you could use some application-level solution that accomplishes the same thing on top of a bunch of more modest hosts running zfs/etc (the Backblaze solution at least in the past). The most mainstream FOSS solution at this scale is Ceph. It achieves redundancy at the host level. That is, if you have it set up to tolerate two failures then you can take two random hosts in the cluster and smash their motherboards with a hammer in the middle of operation, and the cluster will keep on working and quickly restore its redundancy. Each host can have multiple drives, and losing any or all of the drives within a single host counts as a single failure. You can even do clever stuff like tell it which hosts are attached to which circuit breakers and then you could lose all the hosts on a single power circuit at once and it would be fine. This also has the benefit of covering you when one of your flakey drives causes weird bus issues that affect other drives, or one host crashes, and so on. The redundancy is entirely at the host level so you're protected against a much larger number of failure modes. This sort of solution also performs much faster as data requests are not CPU/NIC/HBA limited for any particular host. The software is obviously more complex, but the hardware can be simpler since if you want to expand storage you just buy more servers and plug them into the LAN, versus trying to figure out how to cram an extra dozen hard drives into a single host with all kinds of port multiplier games. You can also do maintenance and just reboot an entire host while the cluster stays online as long as you aren't messing with them all at once. I've gone in this general direction because I was tired of having to try to deal with massive cases, being limited to motherboards with 6 SATA ports, adding LSI HBAs that require an 8x slot and often conflicts with using an NVMe, and so on. So you are right. This is the way they do it. I used the term raid to broadly. But still they have problems with limitations. Size of room, what air conditioning can handle and stuff like this. Anyway I only wanted to point out that there are different approaches in the industries and saving the data at any price is not always necessary.
Re: [gentoo-user] which linux RAID setup to choose?
Am 04.05.2020 um 02:29 schrieb Caveman Al Toraboran: Facebook used to store data which is sometimes accessed on raids. Since they use energy they stored data which is nearly never accessed on blue ray disks. I don't know if they still do. Reading is very slow if a mechanical arm first needs to fetch a specific blue ray out of hundreds and put in a disk reader but it is very energy efficient. interesting. A video from 2014 https://www.facebook.com/Engineering/videos/10152128660097200/
