Re: [gentoo-user] Re: ...recreating exactly the same applications on a new harddisc?
On Saturday, 4 April 2020 22:26:16 BST Neil Bothwick wrote: > On Sat, 4 Apr 2020 10:59:31 -0700, Ian Zimmerman wrote: > > > Is it possible to recreate exactlu the same pool of > > > applications/programs/libraries etc..., which my current > > > system have - in one go? > > > > You don't say if you want exactly the same _versions_ of everything. > > > > If you don't need that, wouldn't just transferring the world file be > > enough? > > You may need to copy world_sets as well, if you have any portage sets > installed. I'd also copy much of /etc and /etc/conf.d as well, especially /etc/portage. -- Regards, Peter.
Re: [gentoo-user] Question about x11-drivers/xf86-input-mouse and x11-drivers/xf86-input-keyboard
Neil Bothwick wrote: > On Sat, 4 Apr 2020 22:11:59 +0200, Alarig Le Lay wrote: > >> The news item from 2020-04-03 says “future removal of the legacy X11 >> input drivers x11-drivers/xf86-input-mouse and >> x11-drivers/xf86-input-keyboard“ > [snip] > >> However, emerge --depclean doesn’t try to remove them. The INPUT_DEVICES >> is commented out in make.conf but emerege --info does contain the >> deprecated drivers: >> alarig@pikachu ~ % grep INPUT_DEVICES /etc/portage/make.conf >> #INPUT_DEVICES="evdev synaptics" >> alarig@pikachu ~ % emerge --info | grep -Po >> '\KINPUT_DEVICES="([[:lower:]](\s?))+"' INPUT_DEVICES="libinput >> keyboard mouse" >> >> Which is the concatenation of INPUT_DEVICES="libinput" from >> profiles/default/linux/make.defaults and INPUT_DEVICES="keyboard mouse" >> from profiles/base/make.defaults. >> >> So, I think that the INPUT_DEVICES variable pushed by the base profile >> should be updated. > Isn't the key that the news item says "future removal". Devs have been > criticised in the past by documenting these changes too late, sometimes > after they have been implemented. This time they seem to be giving us > fair warning and time to get our systems in order. My results are similar > to yours so I expect that the deprecated drivers will be depcleaned when > the future becomes the present. > > I saw the post on -dev and checked my system. Somehow, those have already been depcleaned and the new drivers installed. I don't recall doing it myself. Of course, I have a old clicky type keyboard and a two button rodent with a wheel. It does have that pretty red light it "sees" movement with. Other than that, nothing fancy here. OP, if it helps any, I have these installed. root@fireball / # equery list *libinput* * Searching for *libinput* ... [IP-] [ ] dev-libs/libinput-1.15.2:0/10 [IP-] [ ] x11-drivers/xf86-input-libinput-0.29.0:0 root@fireball / # equery list *udev* * Searching for *udev* ... [IP-] [ ] dev-libs/libgudev-233-r1:0/0 [IP-] [ ] sys-fs/eudev-3.2.9:0 [IP-] [ ] sys-fs/udev-init-scripts-33:0 [IP-] [ ] virtual/libudev-232-r3:0/1 [IP-] [ ] virtual/udev-217:0 root@fireball / # Dale :-) :-)
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
John Covici wrote: > On Sat, 04 Apr 2020 14:33:21 -0400, > Dale wrote: >> Mark Knecht wrote: >>> Your world file should do that for the Gentoo stuff, with limitations. >>> It assumes you have nothing on the system that was created outside of >>> normal portage/emerge. It would probably duplicate the latest kernel >>> tree but wouldn't build it, and wouldn't copy old kernels that aren't >>> in portage if you still have them on the system. It isn't going to get >>> virtual environment, be they python or things like virtualbox if you >>> use those. >>> >>> I suspect you'll get a 'working' machine (I've done it) but you will >>> still have a lot of stuff to transfer by hand or from backups which >>> you really should do anyway. >>> >>> HTH, >>> Mark >>> >> I recently tried this in a chroot starting with a stage3 tarball. At >> first, I tried unpacking the tarball, copying over /etc and the world >> file. I also copied over the binaries and tried using -k. It was a >> disaster. I ran into hard blacks that I never was able to get around >> not to mention emerge complaining about USE flags and such. Then I >> tried unpacking a tarball and just updating the tarball itself with no >> changes on my part, not even the profile, it to ran into hard blocks >> just not as many of them. >> >> In the 2nd attempt, I think something was off in the tarball itself. >> When you unpack a tarball and try to sync and update it and it fails, >> something is wrong somewhere. It's not covered in the install handbook >> either. In theory, one should be able to unpack a tarball, copy over >> /etc and the world file and do a emerge -e world. If one copies over >> the binaries from the old system, one could add a -k to speed up the >> process, for most if not all packages. Thing is, theory meets real >> world real fast and it gets ugly. After multiple attempts, I ended up >> coping my original OS over and that worked better and MUCH faster. >> >> Way back in the day, I would boot a rescue disk of some type, mount both >> drives and then copy everything over, excluding /home if it is on a >> separate drive or any others that shouldn't be transferred. Once that >> is done, chroot in and install grub, the old original one not grub2. >> Once that is done, shutdown and remove old drive, plug new drive into >> old port and then power up, crossing fingers and toes. It worked first >> time generally. I have NOT done that with grub2. It may work the same, >> it may not. Grub2 is a bit of a beast. >> >> Theory, should work. In my real world experience, it does not. Coping >> tends to work if you do it all right. >> >> Just my thoughts. > I did something like this a few months ago, I first got the tarball, > did an immediate update, copied a lot of /etc, particularly > /etc/portage, but not some things like package.use, because I wanted > to let it redetect them, and did parts of the world file at a time, > not all at once, because I had some crud in the world file which I > wanted to be sure I got rid of. Took a couple of weeks, but did work > and then I had a better system than I had before. > Since I keep a clean world file, it wouldn't matter for me. I have -1 as a default emerge option in make.conf which means I have to intentionally add a package to the world file, either by hand or with --select y as a option on the command line. Even if I got the tarball to work, I'd still end up with the same system I got on my main install. It wouldn't matter any. What really got me tho, being unable to get a bare stage3 tarball to update without running into hard blocks. I thought that to be really strange. Still, based on past experience, copying the system over is the fastest. No compiling or anything, just copying it over. Dale :-) :-)
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On 4/4/20 11:34 AM, tu...@posteo.de wrote: Hi, Hi, I am currently preparing a new harddisc as home for my new Gentoo system. Is it possible to recreate exactlu the same pool of applications/programs/libraries etc..., which my current system have - in one go? Baring cosmic influences, I would expect so. That is: Copy from the current system into the chroot environment, fire up emerge, go to bed and tommorow morning the new system ready...? Does this exists and is it reasonable to do it this way? Thanks for any hint in advance! I think that any given system is the product of it's various components. Change any of those components, and you change the product. I see the list of components as being at least: · world file · portage config (/etc/portage) · USEs · accepted keywords · accepted licenses · portage files (/usr/portage) · this significantly influences the version of packages that get installed, which is quite important · kernel · version · config Copying these things across should get you a quite similar system. I suspect you would be down to how different packages are configured. But the world file is only one of many parts that make up the system. I didn't include distfiles because theoretically, you can re-download files. However, I've run into cases where I wasn't able to download something and had to transfer (part of) distfiles too. If you're going to the trouble to keep a system this similar, why not simply copy the system from one drive / machine to another? -- Grant. . . . unix || die
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On Sat, 04 Apr 2020 14:33:21 -0400, Dale wrote: > > Mark Knecht wrote: > > Your world file should do that for the Gentoo stuff, with limitations. > > It assumes you have nothing on the system that was created outside of > > normal portage/emerge. It would probably duplicate the latest kernel > > tree but wouldn't build it, and wouldn't copy old kernels that aren't > > in portage if you still have them on the system. It isn't going to get > > virtual environment, be they python or things like virtualbox if you > > use those. > > > > I suspect you'll get a 'working' machine (I've done it) but you will > > still have a lot of stuff to transfer by hand or from backups which > > you really should do anyway. > > > > HTH, > > Mark > > > > I recently tried this in a chroot starting with a stage3 tarball. At > first, I tried unpacking the tarball, copying over /etc and the world > file. I also copied over the binaries and tried using -k. It was a > disaster. I ran into hard blacks that I never was able to get around > not to mention emerge complaining about USE flags and such. Then I > tried unpacking a tarball and just updating the tarball itself with no > changes on my part, not even the profile, it to ran into hard blocks > just not as many of them. > > In the 2nd attempt, I think something was off in the tarball itself. > When you unpack a tarball and try to sync and update it and it fails, > something is wrong somewhere. It's not covered in the install handbook > either. In theory, one should be able to unpack a tarball, copy over > /etc and the world file and do a emerge -e world. If one copies over > the binaries from the old system, one could add a -k to speed up the > process, for most if not all packages. Thing is, theory meets real > world real fast and it gets ugly. After multiple attempts, I ended up > coping my original OS over and that worked better and MUCH faster. > > Way back in the day, I would boot a rescue disk of some type, mount both > drives and then copy everything over, excluding /home if it is on a > separate drive or any others that shouldn't be transferred. Once that > is done, chroot in and install grub, the old original one not grub2. > Once that is done, shutdown and remove old drive, plug new drive into > old port and then power up, crossing fingers and toes. It worked first > time generally. I have NOT done that with grub2. It may work the same, > it may not. Grub2 is a bit of a beast. > > Theory, should work. In my real world experience, it does not. Coping > tends to work if you do it all right. > > Just my thoughts. I did something like this a few months ago, I first got the tarball, did an immediate update, copied a lot of /etc, particularly /etc/portage, but not some things like package.use, because I wanted to let it redetect them, and did parts of the world file at a time, not all at once, because I had some crud in the world file which I wanted to be sure I got rid of. Took a couple of weeks, but did work and then I had a better system than I had before. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: [gentoo-user] Question about x11-drivers/xf86-input-mouse and x11-drivers/xf86-input-keyboard
On Sat, 4 Apr 2020 22:11:59 +0200, Alarig Le Lay wrote: > The news item from 2020-04-03 says “future removal of the legacy X11 > input drivers x11-drivers/xf86-input-mouse and > x11-drivers/xf86-input-keyboard“ [snip] > However, emerge --depclean doesn’t try to remove them. The INPUT_DEVICES > is commented out in make.conf but emerege --info does contain the > deprecated drivers: > alarig@pikachu ~ % grep INPUT_DEVICES /etc/portage/make.conf > #INPUT_DEVICES="evdev synaptics" > alarig@pikachu ~ % emerge --info | grep -Po > '\KINPUT_DEVICES="([[:lower:]](\s?))+"' INPUT_DEVICES="libinput > keyboard mouse" > > Which is the concatenation of INPUT_DEVICES="libinput" from > profiles/default/linux/make.defaults and INPUT_DEVICES="keyboard mouse" > from profiles/base/make.defaults. > > So, I think that the INPUT_DEVICES variable pushed by the base profile > should be updated. Isn't the key that the news item says "future removal". Devs have been criticised in the past by documenting these changes too late, sometimes after they have been implemented. This time they seem to be giving us fair warning and time to get our systems in order. My results are similar to yours so I expect that the deprecated drivers will be depcleaned when the future becomes the present. -- Neil Bothwick "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook pgpKashmjPnXz.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: ...recreating exactly the same applications on a new harddisc?
On Sat, 4 Apr 2020 10:59:31 -0700, Ian Zimmerman wrote: > > Is it possible to recreate exactlu the same pool of > > applications/programs/libraries etc..., which my current > > system have - in one go? > > You don't say if you want exactly the same _versions_ of everything. > > If you don't need that, wouldn't just transferring the world file be > enough? You may need to copy world_sets as well, if you have any portage sets installed. -- Neil Bothwick He who laughs last thinks slowest!
[gentoo-user] Question about x11-drivers/xf86-input-mouse and x11-drivers/xf86-input-keyboard
Hi,
The news item from 2020-04-03 says “future removal of the legacy X11
input drivers x11-drivers/xf86-input-mouse and
x11-drivers/xf86-input-keyboard“
Those as installed on my system:
alarig@pikachu ~ % eix x11-drivers/xf86-input-mouse
[I] x11-drivers/xf86-input-mouse
Available versions: 1.9.3
Installed versions: 1.9.3(21:13:04 06/03/20)
Homepage:https://www.x.org/wiki/
https://gitlab.freedesktop.org/xorg/driver/xf86-input-mouse
Description: X.Org driver for mouse input devices
alarig@pikachu ~ % eix x11-drivers/xf86-input-keyboard
[I] x11-drivers/xf86-input-keyboard
Available versions: 1.9.0
Installed versions: 1.9.0(21:12:06 06/03/20)
Homepage:https://www.x.org/wiki/
https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard
Description: Keyboard input driver
As is libinput:
alarig@pikachu ~ % eix xf86-input-libinput
[I] x11-drivers/xf86-input-libinput
Available versions: 0.29.0 {KERNEL="linux"}
Installed versions: 0.29.0(21:12:37 06/03/20)(KERNEL="linux")
Homepage:https://www.x.org/wiki/
https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput
Description: X.org input driver based on libinput
And this last one is in use:
alarig@pikachu ~ % grep 'Using input driver' /var/log/Xorg.0.log
[20.374] (II) Using input driver 'libinput' for 'Power Button'
[20.398] (II) Using input driver 'libinput' for 'Video Bus'
[20.411] (II) Using input driver 'libinput' for 'Sleep Button'
[20.424] (II) Using input driver 'libinput' for 'AT Translated Set 2
keyboard'
[20.436] (II) Using input driver 'libinput' for 'SynPS/2 Synaptics TouchPad'
[20.457] (II) Using input driver 'libinput' for 'TPPS/2 IBM TrackPoint'
[20.481] (II) Using input driver 'libinput' for 'ThinkPad Extra Buttons'
However, emerge --depclean doesn’t try to remove them. The INPUT_DEVICES
is commented out in make.conf but emerege --info does contain the
deprecated drivers:
alarig@pikachu ~ % grep INPUT_DEVICES /etc/portage/make.conf
#INPUT_DEVICES="evdev synaptics"
alarig@pikachu ~ % emerge --info | grep -Po
'\KINPUT_DEVICES="([[:lower:]](\s?))+"'
INPUT_DEVICES="libinput keyboard mouse"
Which is the concatenation of INPUT_DEVICES="libinput" from
profiles/default/linux/make.defaults and INPUT_DEVICES="keyboard mouse"
from profiles/base/make.defaults.
So, I think that the INPUT_DEVICES variable pushed by the base profile
should be updated.
Regards,
--
Alarig
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On 04/04 12:30, Mark Knecht wrote: > On Sat, Apr 4, 2020 at 12:05 PM wrote: > > > > On 04/04 07:25, Ashley Dixon wrote: > > > On Sat, Apr 04, 2020 at 07:34:59PM +0200, tu...@posteo.de wrote: > > > > Hi, > > > > > > > > I am currently preparing a new harddisc as home for my new Gentoo > > > > system. > > > > > > > > Is it possible to recreate exactlu the same pool of > > > > applications/programs/libraries etc..., which my current > > > > system have - in one go? > > > > > > > > That is: Copy from the current system into > > > > the chroot environment, fire up emerge, go to bed and > > > > tommorow morning the new system ready...? > > > > > > > > Does this exists and is it reasonable to do > > > > it this way? > > > > > > > > Thanks for any hint in advance! > > > > Stay healthy! > > > > Cheers, > > > > Meino > > > > > > Do you also want to copy configuration and data files, attaining a total > > > replica ? If so, copying the world file is a start, but then you'll > have a > > > plethora of /etc and /var files through which to sift. > > > > > > Perhaps a little more detailed context to your problem would allow for > more > > > accurate/helpful recommendations ? I.e., are you looking for > near-complete > > > duplication, or just a collection of familiar packages which happens to > be on > > > similar hardware ? > > > > > > -- > > > > > > Ashley Dixon > > > suugaku.co.uk > > > > > > 2A9A 4117 > > > DA96 D18A > > > 8A7B B0D2 > > > A30E BF25 > > > F290 A8AA > > > > > > > Hi Ashley, > > > > ok...here it comes...the story of "System 9 outer space" : > > > > My current system has two drawbacks: The harddisc has become way to small > and I don't > > want more than one harddisc in my PC. > > My old PC is 12 years old...and it is - in relation to software of today > > (especially blender) - much too slow and the main memory is also not > > of sufficient size. > > > > Expanding of the old system is -- in respect to its age -- economically > wise > > not the correct decision...I think. > > > > So I bought the parts of a new PC (again AMD), build a new PC, inserts > > the harddisc of the old PC and booted the system. which works fine. > > > > Now I have an old system on the harddisc whith some legacy structure > > (I think), which I want to replace with """the same system""" -- > > freshly rebuild in a way that I can fire up one command before I go to > > bed only to recognize next morning, that I forget to become root > > beforehand... ;) > > > > Jokes aside: > > I want to try to recompile every Gentoo related stuff in the new system, > > which was present in the old system (application-wise, and not > > necessarily version-wise). > > > > This gives me the chance to use a new set of cpuflags given by > cpuid2cpuflags, too. > > (by the way: This command show far less flags than diplayed via the > > command 'lscpu'is cpuid2cpuflags uptodate?) > > > > For the configuration I will move a lot of stuff from the current > > system to the new system. That's ok... > > > > For the "partition and boot" scheme (not the correct words...sorry no > > native speaker ahead;) ) I thought of this: > > > > One hardisc (3T) with the complete system including 256 GB root. The > > harddisc has a GPT and has a grub bootloader also. This makes this > > harddisc bootable as "standalone solution". > > > > Additonally there is a M.2 NvME SSD > > It is a mirror of the root partion with all directories, to which are > often > > written to (/var/tmp, /tmp,...) mounted on tmpfs. > > > > The plan is to update (emerge ... ) the system with in a way, that > > less as possible writes hits the SSD (for example by mounting certain > > parts of the filesystem on tmpfs) and use the root on harddisc as > > backup. > > > > The "real backup" will be a image copy of the harddisc to another > > identical harddisc which I will create on a regular basis. > > > > This way I always have a bootable system. The best backup is > > worthless, if I don't have a system to read it > > > > One thing: > > Would it possible to boot grub from harddisc, which in turn has > > entries in the menu to boot either from harddisc or (as default) > > from SSD? I don't care about the 23.6573 ms it takes longer to > > read grub stage 1 and 2 from harddisc instead off the SSD... ;) > > > > Feeling still a bit paranoid when it comes to SSDs. I know, its > > supersticous...but... ;) > > > > Is this somehow reasonable...or...? > > > > Cheers! > > Meino > > > > Possibly I'm still misunderstanding. However your description here is > helpful. > > Maybe you're approaching this the hard way? Why not build an absolutely > minimal Gentoo system on the new machine, using the M.2 or SDD in the new > machine, and then mount the old HDD in the chroot? Then you could just copy > up the world file and config stuff from the chroot into the new M.2 > environment and do small rebuilds until you get done? You could do that in > small chunks each night and you'd always have the chroot HDD
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On Sat, Apr 4, 2020 at 12:05 PM wrote: > > On 04/04 07:25, Ashley Dixon wrote: > > On Sat, Apr 04, 2020 at 07:34:59PM +0200, tu...@posteo.de wrote: > > > Hi, > > > > > > I am currently preparing a new harddisc as home for my new Gentoo > > > system. > > > > > > Is it possible to recreate exactlu the same pool of > > > applications/programs/libraries etc..., which my current > > > system have - in one go? > > > > > > That is: Copy from the current system into > > > the chroot environment, fire up emerge, go to bed and > > > tommorow morning the new system ready...? > > > > > > Does this exists and is it reasonable to do > > > it this way? > > > > > > Thanks for any hint in advance! > > > Stay healthy! > > > Cheers, > > > Meino > > > > Do you also want to copy configuration and data files, attaining a total > > replica ? If so, copying the world file is a start, but then you'll have a > > plethora of /etc and /var files through which to sift. > > > > Perhaps a little more detailed context to your problem would allow for more > > accurate/helpful recommendations ? I.e., are you looking for near-complete > > duplication, or just a collection of familiar packages which happens to be on > > similar hardware ? > > > > -- > > > > Ashley Dixon > > suugaku.co.uk > > > > 2A9A 4117 > > DA96 D18A > > 8A7B B0D2 > > A30E BF25 > > F290 A8AA > > > > Hi Ashley, > > ok...here it comes...the story of "System 9 outer space" : > > My current system has two drawbacks: The harddisc has become way to small and I don't > want more than one harddisc in my PC. > My old PC is 12 years old...and it is - in relation to software of today > (especially blender) - much too slow and the main memory is also not > of sufficient size. > > Expanding of the old system is -- in respect to its age -- economically wise > not the correct decision...I think. > > So I bought the parts of a new PC (again AMD), build a new PC, inserts > the harddisc of the old PC and booted the system. which works fine. > > Now I have an old system on the harddisc whith some legacy structure > (I think), which I want to replace with """the same system""" -- > freshly rebuild in a way that I can fire up one command before I go to > bed only to recognize next morning, that I forget to become root > beforehand... ;) > > Jokes aside: > I want to try to recompile every Gentoo related stuff in the new system, > which was present in the old system (application-wise, and not > necessarily version-wise). > > This gives me the chance to use a new set of cpuflags given by cpuid2cpuflags, too. > (by the way: This command show far less flags than diplayed via the > command 'lscpu'is cpuid2cpuflags uptodate?) > > For the configuration I will move a lot of stuff from the current > system to the new system. That's ok... > > For the "partition and boot" scheme (not the correct words...sorry no > native speaker ahead;) ) I thought of this: > > One hardisc (3T) with the complete system including 256 GB root. The > harddisc has a GPT and has a grub bootloader also. This makes this > harddisc bootable as "standalone solution". > > Additonally there is a M.2 NvME SSD > It is a mirror of the root partion with all directories, to which are often > written to (/var/tmp, /tmp,...) mounted on tmpfs. > > The plan is to update (emerge ... ) the system with in a way, that > less as possible writes hits the SSD (for example by mounting certain > parts of the filesystem on tmpfs) and use the root on harddisc as > backup. > > The "real backup" will be a image copy of the harddisc to another > identical harddisc which I will create on a regular basis. > > This way I always have a bootable system. The best backup is > worthless, if I don't have a system to read it > > One thing: > Would it possible to boot grub from harddisc, which in turn has > entries in the menu to boot either from harddisc or (as default) > from SSD? I don't care about the 23.6573 ms it takes longer to > read grub stage 1 and 2 from harddisc instead off the SSD... ;) > > Feeling still a bit paranoid when it comes to SSDs. I know, its > supersticous...but... ;) > > Is this somehow reasonable...or...? > > Cheers! > Meino > Possibly I'm still misunderstanding. However your description here is helpful. Maybe you're approaching this the hard way? Why not build an absolutely minimal Gentoo system on the new machine, using the M.2 or SDD in the new machine, and then mount the old HDD in the chroot? Then you could just copy up the world file and config stuff from the chroot into the new M.2 environment and do small rebuilds until you get done? You could do that in small chunks each night and you'd always have the chroot HDD available. While I understand the paranoia about the SDD failing it suggests lack of adequate backups. Any disk can fail on you. If the SDD failure is due to wear out then (short of infant mortality) that's sometime out in the future. You can certainly put the Gentoo work area on an HDD and save write
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On Sat, Apr 04, 2020 at 09:05:09PM +0200, tu...@posteo.de wrote:
> This gives me the chance to use a new set of cpuflags given by
> cpuid2cpuflags, too.
> (by the way: This command show far less flags than diplayed via the
> command 'lscpu'is cpuid2cpuflags uptodate?)
I assume it's up-to-date; the last commit was made in late September of last
year. While lscpu reads from /proc/cpuinfo and lists _all_ reported flags,
`cpuid2cpuflags` only regards ones which are applicable to the CPU_FLAGS
variable in Gentoo, so its no surprise that less flags are shown by the latter.
> For the "partition and boot" scheme (not the correct words...sorry no
> native speaker ahead;) ) I thought of this:
Don't worry, I understood you well. Aside from your marvellous usage of
ellipses ("..."), your communication in English is fine :)
> One thing:
> Would it possible to boot grub from harddisc, which in turn has
> entries in the menu to boot either from harddisc or (as default)
> from SSD? I don't care about the 23.6573 ms it takes longer to
> read grub stage 1 and 2 from harddisc instead off the SSD... ;)
`grub` is capable of showing entries from multiple partition tables/block
devices, if that's what you mean ? Just emerge sys-boot/grub with the `mount`
USE flag.
> Feeling still a bit paranoid when it comes to SSDs. I know, its
> supersticous...but... ;)
Yeah, I know what you mean there. Solid-state is the way things are going, but I
always keep backups/mirrors on hard disk and tape drives (but the latter is only
feasible for huge volumes of data).
I'll have a more detailed look upon your question tomorrow when I'm not quite as
tired, but what you're trying to do is certainly reasonable, and shouldn't be a
huge amount of work.
Thanks for an interesting problem :)
--
Ashley Dixon
suugaku.co.uk
2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA
signature.asc
Description: PGP signature
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On 04/04 07:25, Ashley Dixon wrote: > On Sat, Apr 04, 2020 at 07:34:59PM +0200, tu...@posteo.de wrote: > > Hi, > > > > I am currently preparing a new harddisc as home for my new Gentoo > > system. > > > > Is it possible to recreate exactlu the same pool of > > applications/programs/libraries etc..., which my current > > system have - in one go? > > > > That is: Copy from the current system into > > the chroot environment, fire up emerge, go to bed and > > tommorow morning the new system ready...? > > > > Does this exists and is it reasonable to do > > it this way? > > > > Thanks for any hint in advance! > > Stay healthy! > > Cheers, > > Meino > > Do you also want to copy configuration and data files, attaining a total > replica ? If so, copying the world file is a start, but then you'll have a > plethora of /etc and /var files through which to sift. > > Perhaps a little more detailed context to your problem would allow for more > accurate/helpful recommendations ? I.e., are you looking for near-complete > duplication, or just a collection of familiar packages which happens to be on > similar hardware ? > > -- > > Ashley Dixon > suugaku.co.uk > > 2A9A 4117 > DA96 D18A > 8A7B B0D2 > A30E BF25 > F290 A8AA > Hi Ashley, ok...here it comes...the story of "System 9 outer space" : My current system has two drawbacks: The harddisc has become way to small and I don't want more than one harddisc in my PC. My old PC is 12 years old...and it is - in relation to software of today (especially blender) - much too slow and the main memory is also not of sufficient size. Expanding of the old system is -- in respect to its age -- economically wise not the correct decision...I think. So I bought the parts of a new PC (again AMD), build a new PC, inserts the harddisc of the old PC and booted the system. which works fine. Now I have an old system on the harddisc whith some legacy structure (I think), which I want to replace with """the same system""" -- freshly rebuild in a way that I can fire up one command before I go to bed only to recognize next morning, that I forget to become root beforehand... ;) Jokes aside: I want to try to recompile every Gentoo related stuff in the new system, which was present in the old system (application-wise, and not necessarily version-wise). This gives me the chance to use a new set of cpuflags given by cpuid2cpuflags, too. (by the way: This command show far less flags than diplayed via the command 'lscpu'is cpuid2cpuflags uptodate?) For the configuration I will move a lot of stuff from the current system to the new system. That's ok... For the "partition and boot" scheme (not the correct words...sorry no native speaker ahead;) ) I thought of this: One hardisc (3T) with the complete system including 256 GB root. The harddisc has a GPT and has a grub bootloader also. This makes this harddisc bootable as "standalone solution". Additonally there is a M.2 NvME SSD It is a mirror of the root partion with all directories, to which are often written to (/var/tmp, /tmp,...) mounted on tmpfs. The plan is to update (emerge ... ) the system with in a way, that less as possible writes hits the SSD (for example by mounting certain parts of the filesystem on tmpfs) and use the root on harddisc as backup. The "real backup" will be a image copy of the harddisc to another identical harddisc which I will create on a regular basis. This way I always have a bootable system. The best backup is worthless, if I don't have a system to read it One thing: Would it possible to boot grub from harddisc, which in turn has entries in the menu to boot either from harddisc or (as default) from SSD? I don't care about the 23.6573 ms it takes longer to read grub stage 1 and 2 from harddisc instead off the SSD... ;) Feeling still a bit paranoid when it comes to SSDs. I know, its supersticous...but... ;) Is this somehow reasonable...or...? Cheers! Meino
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
Meino, I think as your question was posed, yes, copying the world file is enough to get the applications into the chroot built and working. Your command looks reasonable but I'll let someone who runs Gentoo these days make suggestions for improvement on that. (I no longer run Gentoo much. Just in a VM and I don't update it any more) As Ashley points out what you're going to wake up to in the morning (or whenever it finishes) is a chroot with all the apps and no special configuration. For instance, if you allow ssh logins to this machine then to get that in the chroot that requires changes to the config file for ssh which you'll still have to do. There are likely to be 20, 50, 100 little issues like that that you'll be dealing with for days. If your goal is to have a chroot which is functionally identical to your main system (with at least a new IP address and probably little or no X access) then you can go this direction. However if you're wanting to get to a newer/bigger/faster hard drive, or from a hard drive to an SSD or something, isn't the more tested (non-Gentoo) way to do this just to clone the drive using clonezilla or something like that? You boot a CD, tell it to clone the HDD to the SDD and wait for it to finish? Mark On Sat, Apr 4, 2020 at 11:24 AM wrote: > Hi Mark, > > thank you for answering my question! :) > > (only to check whether I have understood correctlu) > Stuff I build outside of emerge/portage should not be in the > world-file...correct? > > I will transfer the kernel related stuff from my current system to > the new root (currenly chrooted). > > Ah! By the way: Recompiling all the stuff works while being chrooted, > right? > The command to use is: > emerge --update --newuse --deep --quiet @world > > after syncing. > > > Correct? > > Cheers! > Meino > > > On 04/04 11:05, Mark Knecht wrote: > > Your world file should do that for the Gentoo stuff, with limitations. It > > assumes you have nothing on the system that was created outside of normal > > portage/emerge. It would probably duplicate the latest kernel tree but > > wouldn't build it, and wouldn't copy old kernels that aren't in portage > if > > you still have them on the system. It isn't going to get virtual > > environment, be they python or things like virtualbox if you use those. > > > > I suspect you'll get a 'working' machine (I've done it) but you will > still > > have a lot of stuff to transfer by hand or from backups which you really > > should do anyway. > > > > HTH, > > Mark > > > > On Sat, Apr 4, 2020 at 10:35 AM wrote: > > > > > Hi, > > > > > > I am currently preparing a new harddisc as home for my new Gentoo > > > system. > > > > > > Is it possible to recreate exactlu the same pool of > > > applications/programs/libraries etc..., which my current > > > system have - in one go? > > > > > > That is: Copy from the current system into > > > the chroot environment, fire up emerge, go to bed and > > > tommorow morning the new system ready...? > > > > > > Does this exists and is it reasonable to do > > > it this way? > > > > > > Thanks for any hint in advance! > > > Stay healthy! > > > Cheers, > > > Meino > > > > > > > > > > > > > > > >
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
Mark Knecht wrote: > Your world file should do that for the Gentoo stuff, with limitations. > It assumes you have nothing on the system that was created outside of > normal portage/emerge. It would probably duplicate the latest kernel > tree but wouldn't build it, and wouldn't copy old kernels that aren't > in portage if you still have them on the system. It isn't going to get > virtual environment, be they python or things like virtualbox if you > use those. > > I suspect you'll get a 'working' machine (I've done it) but you will > still have a lot of stuff to transfer by hand or from backups which > you really should do anyway. > > HTH, > Mark > I recently tried this in a chroot starting with a stage3 tarball. At first, I tried unpacking the tarball, copying over /etc and the world file. I also copied over the binaries and tried using -k. It was a disaster. I ran into hard blacks that I never was able to get around not to mention emerge complaining about USE flags and such. Then I tried unpacking a tarball and just updating the tarball itself with no changes on my part, not even the profile, it to ran into hard blocks just not as many of them. In the 2nd attempt, I think something was off in the tarball itself. When you unpack a tarball and try to sync and update it and it fails, something is wrong somewhere. It's not covered in the install handbook either. In theory, one should be able to unpack a tarball, copy over /etc and the world file and do a emerge -e world. If one copies over the binaries from the old system, one could add a -k to speed up the process, for most if not all packages. Thing is, theory meets real world real fast and it gets ugly. After multiple attempts, I ended up coping my original OS over and that worked better and MUCH faster. Way back in the day, I would boot a rescue disk of some type, mount both drives and then copy everything over, excluding /home if it is on a separate drive or any others that shouldn't be transferred. Once that is done, chroot in and install grub, the old original one not grub2. Once that is done, shutdown and remove old drive, plug new drive into old port and then power up, crossing fingers and toes. It worked first time generally. I have NOT done that with grub2. It may work the same, it may not. Grub2 is a bit of a beast. Theory, should work. In my real world experience, it does not. Coping tends to work if you do it all right. Just my thoughts. Dale :-) :-)
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On Sat, Apr 04, 2020 at 07:34:59PM +0200, tu...@posteo.de wrote: > Hi, > > I am currently preparing a new harddisc as home for my new Gentoo > system. > > Is it possible to recreate exactlu the same pool of > applications/programs/libraries etc..., which my current > system have - in one go? > > That is: Copy from the current system into > the chroot environment, fire up emerge, go to bed and > tommorow morning the new system ready...? > > Does this exists and is it reasonable to do > it this way? > > Thanks for any hint in advance! > Stay healthy! > Cheers, > Meino Do you also want to copy configuration and data files, attaining a total replica ? If so, copying the world file is a start, but then you'll have a plethora of /etc and /var files through which to sift. Perhaps a little more detailed context to your problem would allow for more accurate/helpful recommendations ? I.e., are you looking for near-complete duplication, or just a collection of familiar packages which happens to be on similar hardware ? -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
Hi Mark, thank you for answering my question! :) (only to check whether I have understood correctlu) Stuff I build outside of emerge/portage should not be in the world-file...correct? I will transfer the kernel related stuff from my current system to the new root (currenly chrooted). Ah! By the way: Recompiling all the stuff works while being chrooted, right? The command to use is: emerge --update --newuse --deep --quiet @world after syncing. Correct? Cheers! Meino On 04/04 11:05, Mark Knecht wrote: > Your world file should do that for the Gentoo stuff, with limitations. It > assumes you have nothing on the system that was created outside of normal > portage/emerge. It would probably duplicate the latest kernel tree but > wouldn't build it, and wouldn't copy old kernels that aren't in portage if > you still have them on the system. It isn't going to get virtual > environment, be they python or things like virtualbox if you use those. > > I suspect you'll get a 'working' machine (I've done it) but you will still > have a lot of stuff to transfer by hand or from backups which you really > should do anyway. > > HTH, > Mark > > On Sat, Apr 4, 2020 at 10:35 AM wrote: > > > Hi, > > > > I am currently preparing a new harddisc as home for my new Gentoo > > system. > > > > Is it possible to recreate exactlu the same pool of > > applications/programs/libraries etc..., which my current > > system have - in one go? > > > > That is: Copy from the current system into > > the chroot environment, fire up emerge, go to bed and > > tommorow morning the new system ready...? > > > > Does this exists and is it reasonable to do > > it this way? > > > > Thanks for any hint in advance! > > Stay healthy! > > Cheers, > > Meino > > > > > > > >
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
Your world file should do that for the Gentoo stuff, with limitations. It assumes you have nothing on the system that was created outside of normal portage/emerge. It would probably duplicate the latest kernel tree but wouldn't build it, and wouldn't copy old kernels that aren't in portage if you still have them on the system. It isn't going to get virtual environment, be they python or things like virtualbox if you use those. I suspect you'll get a 'working' machine (I've done it) but you will still have a lot of stuff to transfer by hand or from backups which you really should do anyway. HTH, Mark On Sat, Apr 4, 2020 at 10:35 AM wrote: > Hi, > > I am currently preparing a new harddisc as home for my new Gentoo > system. > > Is it possible to recreate exactlu the same pool of > applications/programs/libraries etc..., which my current > system have - in one go? > > That is: Copy from the current system into > the chroot environment, fire up emerge, go to bed and > tommorow morning the new system ready...? > > Does this exists and is it reasonable to do > it this way? > > Thanks for any hint in advance! > Stay healthy! > Cheers, > Meino > > > >
Re: [gentoo-user] Re: ...recreating exactly the same applications on a new harddisc?
On 04/04 10:59, Ian Zimmerman wrote: > On 2020-04-04 19:34, tu...@posteo.de wrote: > > > Is it possible to recreate exactlu the same pool of > > applications/programs/libraries etc..., which my current > > system have - in one go? > > You don't say if you want exactly the same _versions_ of everything. > > If you don't need that, wouldn't just transferring the world file be > enough? > > If you do, maybe you can pin the versions in the world file, though > I have never tried that. > > -- > Ian > Hi Ian, no, I dont' need the same versions... And interesting you have the same question as I: Wouldn't transferring the world file be enough? Is it? Cheers! Meino
[gentoo-user] Re: ...recreating exactly the same applications on a new harddisc?
On 2020-04-04 19:34, tu...@posteo.de wrote: > Is it possible to recreate exactlu the same pool of > applications/programs/libraries etc..., which my current > system have - in one go? You don't say if you want exactly the same _versions_ of everything. If you don't need that, wouldn't just transferring the world file be enough? If you do, maybe you can pin the versions in the world file, though I have never tried that. -- Ian
[gentoo-user] ...recreating exactly the same applications on a new harddisc?
Hi, I am currently preparing a new harddisc as home for my new Gentoo system. Is it possible to recreate exactlu the same pool of applications/programs/libraries etc..., which my current system have - in one go? That is: Copy from the current system into the chroot environment, fire up emerge, go to bed and tommorow morning the new system ready...? Does this exists and is it reasonable to do it this way? Thanks for any hint in advance! Stay healthy! Cheers, Meino
Re: [gentoo-user] aggregate logs into Elasticsearch
* Stefan G. Weichinger:
> Maybe I look into mongodb as well, for example I found this small
> howto: https://www.fluentd.org/guides/recipes/maillog-mongodb
That looks unnecessarily complicated to me. While you can of course move
data from an existing log file into MongoDB, I find configuring syslog
to use a MongoDB destination (in addition to your files or as a full
replacement) much easier.
See [1] section "Storing messages in a MongoDB database". I have also
done it with rsyslog, but that took a bit more work.
Here's a syslog-ng destination I use. Note that using uri() allows
passing parameters to modern MongoDB drivers which the older servers()
statement cannot cope with.
destination d_mongo {
mongodb(
uri("mongodb://user:pw@hostname:27017/syslog?authSource=admin=true")
collection("messages")
value-pairs(
scope("selected-macros" "nv-pairs")
pair("DATE", datetime("$UNIXTIME"))
pair("PID", int64("$PID"))
pair("SEQNUM", int64("$SEQNUM"))
exclude("HOST*")
exclude("LEGACY*")
exclude("SOURCE*")
exclude("TAGS")
)
);
};
Values are strings to begin with. This example excludes some values I am
not interested in, and performs type conversion on others, for example
mapping DATE to MongoDB's date/time data type (see ISODate) and PID to a
numeric value. Conversion can of course happen during analysis, but
since syslog-ng is smart enough to do it when writing data, I prefer
that.
[1]
https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.16/administration-guide/37#TOPIC-956524
-Ralph
Re: [gentoo-user] Re: SDD, what features to look for and what to avoid.
On Saturday, 4 April 2020 11:38:48 BST Alexandru N. Barloiu wrote: > On Sat, 2020-04-04 at 10:51 +0100, Peter Humphrey wrote: > Also, you don't need a fancy gui for nvme temperature. nvme smart-log > /dev/nvme0 will tell you the temperature from console. Thanks for the pointer. # nvme smart-log /dev/nvme0n1 Smart Log for NVME device:nvme0n1 namespace-id: critical_warning: 0 temperature : 49 C available_spare : 100% available_spare_threshold : 10% percentage_used : 31% [...] Interesting. -- Regards, Peter.
Re: [gentoo-user] Re: SDD, what features to look for and what to avoid.
On Sat, 2020-04-04 at 10:51 +0100, Peter Humphrey wrote: > On Friday, 3 April 2020 16:14:33 BST Frank Steinmetzger wrote: > > > Well, raw throughput is great ’n all, but in real-life you won’t > > notice much > > difference between a SATA and an NVME drive. > > Not so. The difference is dramatic. > > > The bottleneck quickly becomes > > the CPU again during boot or loading more complex applications > > (browser, > > office). The biggest improvement in those situation comes from the > > fast > > “seeking” and reading of many small files. HDDs are at a big > > disatvantage > > here due to their moving head and mechanical seeking. > > > > In fact I doubt you have many use cases for reading many gigabytes > > at a time > > over and over again every day without much CPU overhead, like video > > editing > > (loading previews in 4K or 8K), copying, archiving, checksumming > > and so on. > > > > Due to their immense speed, those NVMEs also tend to heat up quite > > a bit > > under load, eventually leading to throttling. So from a practical > > POV, and > > since you’re on a budget, I suggest cutting cost by staying with > > SATA. > > I can't say anything about temperature, because gkrellm can't see a > sensor of > it, but I certainly wouldn't go back to plain old SSDs. > sata was a major bottleneck. in most motherboards it was embeded in the southbridge WITH lan, sound, usb. When you saturate the sata controller, all others stop working, or lag terribly. That's why swap on sata systems only exacerbates the problem. nvme drives have been moved up in northbridge with cpu, memory and gpu. The bandwidth is superhuge now. Not only you get amazing speeds with one thread, but regardless of how much disk io you are doing, the computer is not lagging anymore. problem with heating is the way it is mounted. M2 drives sit too close to the motherboard, pciexpress drives are usually mounted on the bottom half of the case because of the way pciexpress ports are layed out. port one for gpu. last port from bottom, nvme. you could just put a fan on it. Also, you don't need a fancy gui for nvme temperature. nvme smart-log /dev/nvme0 will tell you the temperature from console. axl
Re: [gentoo-user] Re: SDD, what features to look for and what to avoid.
On Friday, 3 April 2020 16:14:33 BST Frank Steinmetzger wrote: > Well, raw throughput is great ’n all, but in real-life you won’t notice much > difference between a SATA and an NVME drive. Not so. The difference is dramatic. > The bottleneck quickly becomes > the CPU again during boot or loading more complex applications (browser, > office). The biggest improvement in those situation comes from the fast > “seeking” and reading of many small files. HDDs are at a big disatvantage > here due to their moving head and mechanical seeking. > > In fact I doubt you have many use cases for reading many gigabytes at a time > over and over again every day without much CPU overhead, like video editing > (loading previews in 4K or 8K), copying, archiving, checksumming and so on. > > Due to their immense speed, those NVMEs also tend to heat up quite a bit > under load, eventually leading to throttling. So from a practical POV, and > since you’re on a budget, I suggest cutting cost by staying with SATA. I can't say anything about temperature, because gkrellm can't see a sensor of it, but I certainly wouldn't go back to plain old SSDs. -- Regards, Peter.
Re: [gentoo-user] NVidia-driver, RTX 2060 SUPER. Blender and NO Optix...
Hello,
On Sat, 04 Apr 2020, tu...@posteo.de wrote:
>On 04/04 08:36, David Haller wrote:
[..]
>> Looking at the ebuild, it seems that it only installs libnvoptix when
>> multilib enabled is *and* if it's on amd64:
>>
>> x11-drivers/nvidia-drivers/nvidia-drivers-440.64.ebuild
>> if use kernel_linux && has_multilib_profile && [[ ${ABI} ==
>> "amd64" ]];
>a
>> then
>> NV_GLX_LIBRARIES+=(
>> "libnvidia-cbl.so.${NV_SOVER}"
>> "libnvidia-rtcore.so.${NV_SOVER}"
>> "libnvoptix.so.${NV_SOVER}"
>> )
>> fi
>>
>>
>> And that's the only occurrence of optix in the ebuild. In driver,
>> there's only a 64-bit libnvoptix.so.440.64 included, it's missing from
>> the ./32 subfolder, so I guess that optix stuff it's 64bit only.
>> But that dep on has_multilib_profile seems buggish to me. Test /
>> workaround: Just add 'multilib' to your package.use flags of
>> x11-drivers/nvidia-drivers (and _do not set_ e.g. abi_x86_32), just
>> switch on the 'multilib'. If that works and libnvoptix.so is then
>> installed and Blender works with it, I'd say it's a bug that those
>> libs should only be installed with multilib on. My guess is, that the
>> intent and/or right way would be to just omit that multilib dep. Apart
>> from other useflags that could be used. I.e. it should be:
>>
>>
>> if use kernel_linux && [[ ${ABI} == "amd64" ]];
>> then
>> NV_GLX_LIBRARIES+=(
>> "libnvidia-cbl.so.${NV_SOVER}"
>> "libnvidia-rtcore.so.${NV_SOVER}"
>> "libnvoptix.so.${NV_SOVER}"
>> )
>> fi
>>
[..]
>ooouuu...now things are becoming really weird...:
Not really ;)
>After reading your post (thanks for the indepth analysis!!!)m I set this:
>>=x11-drivers/nvidia-drivers-396.24-r2 X static-libs uvm compat driver acpi
>>multilib
>
>and got this:
>[I] x11-drivers/nvidia-drivers
> Available versions: (~)304.137-r1(0/304)^md[1]
> (~)340.107-r2(0/340)^md[1] 340.108(0/340)^mtd (~)375.82-r2(0/375)^md[1]
> (~)378.13-r5(0/378)^md[1] (~)381.22-r3(0/381)^md[1]
> (~)384.130-r1(0/384)^md[1] (~)387.34-r1(0/387)^md[1]
> (~)390.77-r1(0/390)^md[1] (~)390.87(0/390)^md[1] 390.132-r1(0/390)^mtd
> (~)390.132-r2(0/390)^mtd (~)396.24-r2(0/396)^md[1]
> (~)396.24.10-r1(0/396.24)^md[1] (~)396.45-r1(0/396)^md[1]
> (~)396.51-r1(0/396)^md[1] (~)396.51.02(0/396.51)^md[1] (~)396.54(0/396)^md[1]
> 430.64-r1(0/430)^mtd 435.21-r1(0/435)^mtd 440.64(0/440)^mtd {+X acpi compat
> +driver gtk3 +kms +libglvnd multilib pax_kernel static-libs +tools uvm
> wayland ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64"
> ABI_X86="32 64 x32" KERNEL="FreeBSD linux"}
> Installed versions: 440.64(0/440)^mtd(09:06:52 AM 04/04/2020)(X acpi
> compat driver kms libglvnd static-libs tools uvm -gtk3 -multilib -wayland
> ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64"
> ABI_X86="64 -32 -x32" KERNEL="linux -FreeBSD")
> Homepage:https://www.nvidia.com/
> Description: NVIDIA Accelerated Graphics Driver
>
>...multilib is ignored
Did you reemerge x11-drivers/nvidia-drivers? If so your profile might
have switched if off and then read on ;)
>...because I am on a 64bit-only system???
Possibly, I'm not firm about all that profile stuff. If you've
selected a no-multilib profile (e.g.
default/linux/amd64/17.1/no-multilib), I guess that -multilib might be
switched off by the profile, even overriding your useflag in
package.use[0].
In that case, try this (create dirs/files as neccessary):
/etc/portage/profile/package.use.force ===
x11-drivers/nvidia-drivers multilib
If that does not work, try:
/etc/portage/profile/package.use.mask ===
x11-drivers/nvidia-drivers -multilib
(it's a matter of how it's switched off via the profile, AFAIK).
BTW: you do not have to emerge the package to see the effect of those
edits, an 'emerge --pretend ...' will show you if the 'multilib' flag
will be honored or not.
>By the way: For testing purposes, I installed the nvidia-drivers as
>they are provided by nvidia and can activate Optix in blender then.
>I prefer the "Gentoo-way", though.
Yeah, I do too, even though I do mess with it quite a bit :)
>H...
>
>And: ABI_X86="64 -32 -x32" does not include "amd64" but only "64"...
ABI_X86 is a USE_EXPAND and so ABI_X86="64" expands to abi_x86_64 and
_that_ in effect sets the ABI multibuild environment variable to "amd64"
if you're building for x86_64 and not if building for e.g. x86_32 or
ppc or whatnot.
Dunno where that's documented though. Search 'ABI site:gentoo.org'?
HTH,
-dnh
[0] Which BTW makes no sense to me. Who does not set useflags in
[gentoo-user] Re: how do you monitor your pc?
I uncommented and adjusted this part of /etc/syslog.conf: # # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # daemon,mail,cron.*;\ *.notice/dev/tty8 In general, I try to keep root/admin things away from my X11 session. -- Ian
[gentoo-user] Re: Pocket sneaks back
On 2020-04-01 22:07, Frank Steinmetzger wrote: > When you are on the home screen (about:home), there is a cogwhell on > the top right, leading you to the relevant section in Firefox’ > settings. In there, you get a checkmark to disable pocket on the home > screen. I had done _that_ long ago. Of course. -- Ian
Re: [gentoo-user] Re: mail cannot send emails (trying to use it with smartd)
On Friday, 3 April 2020 20:48:12 BST Grant Taylor wrote: > On 4/2/20 10:47 PM, Caveman Al Toraboran wrote: > > wow, didn't know sendmail's syntax was so hard it needed a compiler > > > > :D thank you very much for your help. highly appreciated. > > I think that's an inaccurate statement. > > First, m4 is a macro package, not a compiler. > > Second, the macros are used to reduce the size of the macro config (mc) > file to something manageable instead of hundreds of lines that are easy > to cause a syntax mistake. > > Third, the macros made the mc file more semantics in nature instead of > Sendmail config file (cf) specific. Meaning that one line allows > changing values in multiple places that use the common information, like > the domain name(s). > > My home system has a 33 line mc file (including comments) that expands > to 1915 lines of cf file (including comments). > > Both the input and output is ASCII text. Humans can read both of them. > Humans that understand cf syntax can read both files. > > This is far from turning something into byte code. I have used sendmail in the past and found it a pain to get my head around some of its more esoteric set ups, for reasons Grant has already explained. I can't recall the details, but it involved convoluted relaying through some american ISP, tiered fall-backs in case of delivery failure, self-signed TLS certs and a number of local/external email accounts and multiple aliases. Once the pain of understanding its sytanx, setting it up and testing was done with, the system worked *exactly* as I wished, day in day out, without errors and without missing messages. For years. It was so reliable, I had to re- familiarise myself with its syntax whenever I wanted to change something in its behaviour. A nice problem to have, compared with so many poorly written applications today. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] aggregate logs into Elasticsearch
Am 03.04.20 um 17:57 schrieb Ralph Seichter: > * Stefan G. Weichinger: > >> My goal: >> >> collect logs of postfix, nginx into the docker-containers running ES, >> Kibana .. and learn my way from there. > > If you are not dead-set on Elasticsearch et al, I propose considering > MongoDB as an alternative. > > There are syslog Modules that allow logging into MongoDB directly. On > the DB side, collections (roughly equivalent to tables in relational > databases) can be limited by size or by age, meaning that removing older > data will happen automatically if you so wish. > > MongoDB also makes it easy to add data from sources with different data > makeup to shared collections, because there is no rigid table structure. > > For analysis, MongoDB includes its own Aggregation Framework[1], which > is a very powerful and versatile. While probably not relevant to your > needs right now, It even comes with built-in geolocation search > > [1] https://docs.mongodb.com/manual/core/aggregation-pipeline/ > > I think very highly of MongoDB and encourage you to look into it as a > possibility and as an interesing technical concept. Thanks for the feedback. I am not at all set on ES, it just was part of an article I read lately, and so I started with that docker-compose stack example. Yesterday I spent quite a while trying to pipe the journald entries into the fluentd container, quite complicated and messy in a way. Maybe I look into mongodb as well, for example I found this small howto: https://www.fluentd.org/guides/recipes/maillog-mongodb In the end I look for a solution to aggregate (systemd/journald) logs into one pile of data and to be able to analyze stuff there. All these solutions seem rather complicated and overly "academic" to me ... but that might be my newbie status in this area.
Re: [gentoo-user] NVidia-driver, RTX 2060 SUPER. Blender and NO Optix...
On Saturday, April 4, 2020 6:45:58 AM CEST tu...@posteo.de wrote:
> Hi,
>
> I have discussed this on www.blenderartists.org and they asked
> me to ask here to sort out, whether the problem is a Blender-thing,
> a Linux-thing or a GENTOO-thing.
>
> My setup is as follows:
> NVidia RTX 2060 SUPER
>
> NVidia-drivers:
> [I] x11-drivers/nvidia-drivers
> Available versions: (~)304.137-r1(0/304)^md[1]
> (~)340.107-r2(0/340)^md[1] 340.108(0/340)^mtd (~)375.82-r2(0/375)^md[1]
> (~)378.13-r5(0/378)^md[1] (~)381.22-r3(0/381)^md[1]
> (~)384.130-r1(0/384)^md[1] (~)387.34-r1(0/387)^md[1]
> (~)390.77-r1(0/390)^md[1] (~)390.87(0/390)^md[1] 390.132-r1(0/390)^mtd
> (~)390.132-r2(0/390)^mtd (~)396.24-r2(0/396)^md[1]
> (~)396.24.10-r1(0/396.24)^md[1] (~)396.45-r1(0/396)^md[1]
> (~)396.51-r1(0/396)^md[1] (~)396.51.02(0/396.51)^md[1]
> (~)396.54(0/396)^md[1] 430.64-r1(0/430)^mtd 435.21-r1(0/435)^mtd
> 440.64(0/440)^mtd {+X acpi compat +driver gtk3 +kms +libglvnd multilib
> pax_kernel static-libs +tools uvm wayland ABI_MIPS="n32 n64 o32"
> ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="FreeBSD
> linux"} Installed versions: 440.64(0/440)^mtd(03:03:25 AM 04/03/2020)(X
> driver kms libglvnd static-libs tools uvm -acpi -compat -gtk3 -multilib
> -wayland ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32
> -64" ABI_X86="64 -32 -x32" KERNEL="linux -FreeBSD") Homepage:
> https://www.nvidia.com/
> Description: NVIDIA Accelerated Graphics Driver
>
> Blender 2.82a (stable) and
> Blender 2.83 (deveoper build)
>
> The NVidia RTX-cards offer a new feature called "Optix" which blender
> can use to speed up rendering and denoising.
>
> When Blender is started one choose "Optix" from the user
> Preferences->System tab and then the Optix-enabled devices of the
> system in question are shown.
> There is a similiar tab, if you want to use CUDA instead.
>
> The CUDA tab shows my graphics card and everything behaves as
> exsoected. Choosing "Optix" instead says "No Optix enabled
> device".
>
> Which is not quite right, since the RTX-cards are Optix enabled.
>
> In the thread on blenderartists there were two libs (?) mentioned (on
> a Ubuntu system, where the Optix thingie works), which I cannot
> find on my system:
>
> + libnividia-compute
> + libnivia-gl
>
> . Does Gentoo installs a differently packaged nvidia-driver?
> What is the source of those libraries?
>
> If someone got Optix running with blender on a RTX-card under GENTOO
> I woyld be very happy for any help! :)
>
> Cheers and stay healthy!
> Meino
I think the second one might be a typo (libnvidia instead of libnivia).
I find the following libnvidia-gl* libraries on my system:
lrwxrwxrwx 1 root root 26 Mar 27 10:00 /usr/lib64/libnvidia-glcore.so ->
libnvidia-glcore.so.440.59
-rwxr-xr-x 1 root root 28661160 Mar 27 10:00 /usr/lib64/libnvidia-glcore.so.
440.59
lrwxrwxrwx 1 root root 24 Mar 27 10:00 /usr/lib64/libnvidia-glsi.so ->
libnvidia-glsi.so.440.59
-rwxr-xr-x 1 root root 687304 Mar 27 10:00 /usr/lib64/libnvidia-glsi.so.
440.59
lrwxrwxrwx 1 root root 29 Mar 27 10:00 /usr/lib64/libnvidia-glvkspirv.so
-> libnvidia-glvkspirv.so.440.59
-rwxr-xr-x 1 root root 4264 Mar 27 10:00 /usr/lib64/libnvidia-
glvkspirv.so.440.59
(Eg: libnvidia-glcore, libnvidia-glsi, libnvidia-glvkspirv)
but not "libnvidia-compute"
I do find "libnvidia-compiler"
Might it be part of one of the nvidia toolkits?
--
Joost
Re: [gentoo-user] NVidia-driver, RTX 2060 SUPER. Blender and NO Optix...
On 04/04 08:36, David Haller wrote:
> Hello,
>
> On Sat, 04 Apr 2020, Andrew Udvare wrote:
> >> On Apr 4, 2020, at 00:59, Dale wrote:
> >> tu...@posteo.de wrote:
> >>> I have discussed this on www.blenderartists.org and they asked
> >>> me to ask here to sort out, whether the problem is a Blender-thing,
> >>> a Linux-thing or a GENTOO-thing.
> >>>
> >>> My setup is as follows:
> >>> NVidia RTX 2060 SUPER
> >>>
> >>> NVidia-drivers:
> >>> [I] x11-drivers/nvidia-drivers
> >>> Available versions: (~)304.137-r1(0/304)^md[1]
> >>> (~)340.107-r2(0/340)^md[1] 340.108(0/340)^mtd (~)375.82-r2(0/375)^md[1]
> >>> (~)378.13-r5(0/378)^md[1] (~)381.22-r3(0/381)^md[1]
> >>> (~)384.130-r1(0/384)^md[1] (~)387.34-r1(0/387)^md[1]
> >>> (~)390.77-r1(0/390)^md[1] (~)390.87(0/390)^md[1] 390.132-r1(0/390)^mtd
> >>> (~)390.132-r2(0/390)^mtd (~)396.24-r2(0/396)^md[1]
> >>> (~)396.24.10-r1(0/396.24)^md[1] (~)396.45-r1(0/396)^md[1]
> >>> (~)396.51-r1(0/396)^md[1] (~)396.51.02(0/396.51)^md[1]
> >>> (~)396.54(0/396)^md[1] 430.64-r1(0/430)^mtd 435.21-r1(0/435)^mtd
> >>> 440.64(0/440)^mtd {+X acpi compat +driver gtk3 +kms +libglvnd multilib
> >>> pax_kernel static-libs +tools uvm wayland ABI_MIPS="n32 n64 o32"
> >>> ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32"
> >>> KERNEL="FreeBSD linux"}
> >>> Installed versions: 440.64(0/440)^mtd(03:03:25 AM 04/03/2020)(X
> >>> driver kms libglvnd static-libs tools uvm -acpi -compat -gtk3 -multilib
> >>> -wayland ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32
> >>> -64" ABI_X86="64 -32 -x32" KERNEL="linux -FreeBSD")
> >>> Homepage:https://www.nvidia.com/
> >>> Description: NVIDIA Accelerated Graphics Driver
> >>>
> >>> Blender 2.82a (stable) and
> >>> Blender 2.83 (deveoper build)
> >>>
> >>> The NVidia RTX-cards offer a new feature called "Optix" which blender
> >>> can use to speed up rendering and denoising.
> >>>
> >>> When Blender is started one choose "Optix" from the user
> >>> Preferences->System tab and then the Optix-enabled devices of the
> >>> system in question are shown.
> >>> There is a similiar tab, if you want to use CUDA instead.
> >>>
> >>> The CUDA tab shows my graphics card and everything behaves as
> >>> exsoected. Choosing "Optix" instead says "No Optix enabled
> >>> device".
> >>>
> >>> Which is not quite right, since the RTX-cards are Optix enabled.
> >
> >I suggest filing a bug about this regarding the nvidia-drivers
> >package. It's possible it's not installing the necessary files.
>
> Looking at the ebuild, it seems that it only installs libnvoptix when
> multilib enabled is *and* if it's on amd64:
>
> x11-drivers/nvidia-drivers/nvidia-drivers-440.64.ebuild
> if use kernel_linux && has_multilib_profile && [[ ${ABI} ==
> "amd64" ]];
a
> then
> NV_GLX_LIBRARIES+=(
> "libnvidia-cbl.so.${NV_SOVER}"
> "libnvidia-rtcore.so.${NV_SOVER}"
> "libnvoptix.so.${NV_SOVER}"
> )
> fi
>
>
> And that's the only occurrence of optix in the ebuild. In driver,
> there's only a 64-bit libnvoptix.so.440.64 included, it's missing from
> the ./32 subfolder, so I guess that optix stuff it's 64bit only.
> But that dep on has_multilib_profile seems buggish to me. Test /
> workaround: Just add 'multilib' to your package.use flags of
> x11-drivers/nvidia-drivers (and _do not set_ e.g. abi_x86_32), just
> switch on the 'multilib'. If that works and libnvoptix.so is then
> installed and Blender works with it, I'd say it's a bug that those
> libs should only be installed with multilib on. My guess is, that the
> intent and/or right way would be to just omit that multilib dep. Apart
> from other useflags that could be used. I.e. it should be:
>
>
> if use kernel_linux && [[ ${ABI} == "amd64" ]];
> then
> NV_GLX_LIBRARIES+=(
> "libnvidia-cbl.so.${NV_SOVER}"
> "libnvidia-rtcore.so.${NV_SOVER}"
> "libnvoptix.so.${NV_SOVER}"
> )
> fi
>
>
> HTH,
> -dnh
>
> --
> printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n");
> linux-2.2.16/drivers/char/msp3400.c
>
Hi,
ooouuu...now things are becoming really weird...:
After reading your post (thanks for the indepth analysis!!!)m I set this:
>=x11-drivers/nvidia-drivers-396.24-r2 X static-libs uvm compat driver acpi
>multilib
and got this:
[I] x11-drivers/nvidia-drivers
Available versions: (~)304.137-r1(0/304)^md[1] (~)340.107-r2(0/340)^md[1]
340.108(0/340)^mtd (~)375.82-r2(0/375)^md[1] (~)378.13-r5(0/378)^md[1]
(~)381.22-r3(0/381)^md[1] (~)384.130-r1(0/384)^md[1] (~)387.34-r1(0/387)^md[1]
(~)390.77-r1(0/390)^md[1]
Re: [gentoo-user] syslog-ng keeps restarting every few minutes
On Sat, Apr 04, 2020 at 10:28:04AM +0800, William Kenworthy wrote: > Syslog-ng is restarting every few minutes! I have been able to narrow it > down to a process named "supervise" as after killing it syslog-ng > settles down. Do you have app-admin/supervisor installed ? http://supervisord.org/ -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] NVidia-driver, RTX 2060 SUPER. Blender and NO Optix...
Hello,
On Sat, 04 Apr 2020, Andrew Udvare wrote:
>> On Apr 4, 2020, at 00:59, Dale wrote:
>> tu...@posteo.de wrote:
>>> I have discussed this on www.blenderartists.org and they asked
>>> me to ask here to sort out, whether the problem is a Blender-thing,
>>> a Linux-thing or a GENTOO-thing.
>>>
>>> My setup is as follows:
>>> NVidia RTX 2060 SUPER
>>>
>>> NVidia-drivers:
>>> [I] x11-drivers/nvidia-drivers
>>> Available versions: (~)304.137-r1(0/304)^md[1]
>>> (~)340.107-r2(0/340)^md[1] 340.108(0/340)^mtd (~)375.82-r2(0/375)^md[1]
>>> (~)378.13-r5(0/378)^md[1] (~)381.22-r3(0/381)^md[1]
>>> (~)384.130-r1(0/384)^md[1] (~)387.34-r1(0/387)^md[1]
>>> (~)390.77-r1(0/390)^md[1] (~)390.87(0/390)^md[1] 390.132-r1(0/390)^mtd
>>> (~)390.132-r2(0/390)^mtd (~)396.24-r2(0/396)^md[1]
>>> (~)396.24.10-r1(0/396.24)^md[1] (~)396.45-r1(0/396)^md[1]
>>> (~)396.51-r1(0/396)^md[1] (~)396.51.02(0/396.51)^md[1]
>>> (~)396.54(0/396)^md[1] 430.64-r1(0/430)^mtd 435.21-r1(0/435)^mtd
>>> 440.64(0/440)^mtd {+X acpi compat +driver gtk3 +kms +libglvnd multilib
>>> pax_kernel static-libs +tools uvm wayland ABI_MIPS="n32 n64 o32"
>>> ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="FreeBSD
>>> linux"}
>>> Installed versions: 440.64(0/440)^mtd(03:03:25 AM 04/03/2020)(X driver
>>> kms libglvnd static-libs tools uvm -acpi -compat -gtk3 -multilib -wayland
>>> ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64"
>>> ABI_X86="64 -32 -x32" KERNEL="linux -FreeBSD")
>>> Homepage:https://www.nvidia.com/
>>> Description: NVIDIA Accelerated Graphics Driver
>>>
>>> Blender 2.82a (stable) and
>>> Blender 2.83 (deveoper build)
>>>
>>> The NVidia RTX-cards offer a new feature called "Optix" which blender
>>> can use to speed up rendering and denoising.
>>>
>>> When Blender is started one choose "Optix" from the user
>>> Preferences->System tab and then the Optix-enabled devices of the
>>> system in question are shown.
>>> There is a similiar tab, if you want to use CUDA instead.
>>>
>>> The CUDA tab shows my graphics card and everything behaves as
>>> exsoected. Choosing "Optix" instead says "No Optix enabled
>>> device".
>>>
>>> Which is not quite right, since the RTX-cards are Optix enabled.
>
>I suggest filing a bug about this regarding the nvidia-drivers
>package. It's possible it's not installing the necessary files.
Looking at the ebuild, it seems that it only installs libnvoptix when
multilib enabled is *and* if it's on amd64:
x11-drivers/nvidia-drivers/nvidia-drivers-440.64.ebuild
if use kernel_linux && has_multilib_profile && [[ ${ABI} ==
"amd64" ]];
then
NV_GLX_LIBRARIES+=(
"libnvidia-cbl.so.${NV_SOVER}"
"libnvidia-rtcore.so.${NV_SOVER}"
"libnvoptix.so.${NV_SOVER}"
)
fi
And that's the only occurrence of optix in the ebuild. In driver,
there's only a 64-bit libnvoptix.so.440.64 included, it's missing from
the ./32 subfolder, so I guess that optix stuff it's 64bit only.
But that dep on has_multilib_profile seems buggish to me. Test /
workaround: Just add 'multilib' to your package.use flags of
x11-drivers/nvidia-drivers (and _do not set_ e.g. abi_x86_32), just
switch on the 'multilib'. If that works and libnvoptix.so is then
installed and Blender works with it, I'd say it's a bug that those
libs should only be installed with multilib on. My guess is, that the
intent and/or right way would be to just omit that multilib dep. Apart
from other useflags that could be used. I.e. it should be:
if use kernel_linux && [[ ${ABI} == "amd64" ]];
then
NV_GLX_LIBRARIES+=(
"libnvidia-cbl.so.${NV_SOVER}"
"libnvidia-rtcore.so.${NV_SOVER}"
"libnvoptix.so.${NV_SOVER}"
)
fi
HTH,
-dnh
--
printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n");
linux-2.2.16/drivers/char/msp3400.c
