Re: [gentoo-user] sysrescuecd gone rogue
On June 4, 2019 1:10:13 PM UTC, Mick wrote: >I just downloaded my preferred medium of choice for installing Gentoo >and >discovered sysrescuecd now runs Linux Arch instead of Gentoo and to >make >things worse it is running systemd instead of openrc. :-( > >A quick look in the forums did not reveal the reasons for this >strategic >change. Regardless, have you used the Arch based sysrescuecd to >install >Gentoo and are there are any gotchas I should be aware of? > >Would I be better off to use a Gentoo Live ISO to install with? I >don't think >I have used one of these for more than 10 years ... or more! O_O I tried the latest sysresccd to reinstall my laptop after having to replace the SSD. (It died without warning after 5.5 years). I ended up using the gentoo install ISO for the install as sysresccd caused me too many issues. Was too much in a hurry to waste much time in trying to figure it all out. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Re: sysrescuecd gone rogue
On June 4, 2019 5:59:49 PM UTC, Neil Bothwick wrote: >On Tue, 4 Jun 2019 16:38:14 +0300, Nikos Chantziaras wrote: > >> > Regardless, have you used the Arch based sysrescuecd to install >> > Gentoo and are there are any gotchas I should be aware of? >> >> You can use anything. I did use the Gentoo-based sysrescuecd once to >> install Gentoo, and I also used an Ubuntu live DVD too. It doesn't >> matter. If it's Linux and boots, nothing changes. > >One thing to watch out for: if you are installing a UEFI system, you >need a live CD that boots using UEFI and not CSM. The gentoo live dvd can boot into UEFI mode. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Re: sysrescuecd gone rogue
On Wed, Jun 5, 2019 at 3:26 PM J. Roeleveld wrote: > > On June 4, 2019 5:59:49 PM UTC, Neil Bothwick wrote: > >On Tue, 4 Jun 2019 16:38:14 +0300, Nikos Chantziaras wrote: > > > >> > Regardless, have you used the Arch based sysrescuecd to install > >> > Gentoo and are there are any gotchas I should be aware of? > >> > >> You can use anything. I did use the Gentoo-based sysrescuecd once to > >> install Gentoo, and I also used an Ubuntu live DVD too. It doesn't > >> matter. If it's Linux and boots, nothing changes. > > > >One thing to watch out for: if you are installing a UEFI system, you > >need a live CD that boots using UEFI and not CSM. > > The gentoo live dvd can boot into UEFI mode. > Personally I just use an Ubuntu image these days - it is trivial to get that working on anything, and it is also pretty easy to get it working with ZFS (easier than with most alternatives at least). I use zfs on most of my root filesystems. In any case, really any solution should work. I'm all for Gentoo-based ones but the Gentoo install process is pretty generic and doesn't really need anything more sophisticated than tar+bzip+curl/wget+chroot, and then whatever you need to partition and format your filesystems. So, I find that my choice of rescue CD tends to be driven more by practical concerns (what boots on the system I'm using, convenient tools, package repository, etc). -- Rich
Re: [gentoo-user] sysrescuecd gone rogue
One thing I noticed with sysrescuecd switching from Gentoo to Arch was no more gcc, meaning you can't build any additional software. But then the use of squashfs always was an annoyance. Tom
[gentoo-user] What is the best way to clean up the world file?
What is the best way to clean up the world file? I have inherited a system where someone did individual emerges to update packages when there was a single package that had a problem. So, now all the packages that emerge wanted to update have been added to the world file. I'd like to clean up world file so that it's back to just the original packages and allow emerge to manage the dependencies. More specifically, I'd like the standard emerge --depclean to remove no-longer-needed dependencies after removing the things that depended on them. I can derive a list of the extra dependencies from the /var/log/emerge.log file by looking for clusters of individual installs really close to each other.
Re: [gentoo-user] What is the best way to clean up the world file?
Grant Taylor wrote: > What is the best way to clean up the world file? > > I have inherited a system where someone did individual emerges to > update packages when there was a single package that had a problem. > So, now all the packages that emerge wanted to update have been added > to the world file. > > I'd like to clean up world file so that it's back to just the original > packages and allow emerge to manage the dependencies. More > specifically, I'd like the standard emerge --depclean to remove > no-longer-needed dependencies after removing the things that depended > on them. > > I can derive a list of the extra dependencies from the > /var/log/emerge.log file by looking for clusters of individual > installs really close to each other. > > I would start by removing anything that has libs in it. Generally, those should be pulled in as deps. After that, I'd go through the list and remove anything that you don't directly use. Example, leave Firefox since it is a web browser you use directly, Libreoffice is another example. Other examples may be Smplayer, VLC, digiKam and other similar programs. There used to be a script that does this fairly well but not sure if it still works or even exists. As you remove items, run emerge -a --depclean to see what would be removed. Look for anything you want to keep and add those as needed. It can take time to complete this sort of task if your world file is a real mess. Ah, it just hit me. root@fireball / # regenworld -h This script regenerates the portage world file by checking the portage logfile for all actions that you've done in the past. It ignores any arguments except --help. It is recommended that you make a backup of your existing world file (/var/lib/portage/world) before using this tool. root@fireball / # I might add, I put the option -1 in my make.conf for emerge defaults so that anytime I emerge something, it doesn't get added to the world file. If I want to add something to the world file, I use --select y to override the -1 in make.conf. It's so easy to forget to add -1 and make a mess of the world file, I decided to set it so I don't have to remember. You may want to consider this. Dale :-) :-)
Re: [gentoo-user] What is the best way to clean up the world file?
On 6/5/19 9:18 PM, Dale wrote: I would start by removing anything that has libs in it. Generally, those should be pulled in as deps. After that, I'd go through the list and remove anything that you don't directly use. ACK Can I just edit /var/lib/portage/world? Or do I need to do something else? Ah, it just hit me. root@fireball / # regenworld -h This script regenerates the portage world file by checking the portage logfile for all actions that you've done in the past. It ignores any arguments except --help. It is recommended that you make a backup of your existing world file (/var/lib/portage/world) before using this tool. root@fireball / # I'll check that out. I might add, I put the option -1 in my make.conf for emerge defaults so that anytime I emerge something, it doesn't get added to the world file. If I want to add something to the world file, I use --select y to override the -1 in make.conf. It's so easy to forget to add -1 and make a mess of the world file, I decided to set it so I don't have to remember. You may want to consider this. I'll consider that.
Re: [gentoo-user] What is the best way to clean up the world file?
Grant Taylor wrote: > On 6/5/19 9:18 PM, Dale wrote: >> I would start by removing anything that has libs in it. Generally, >> those should be pulled in as deps. After that, I'd go through the >> list and remove anything that you don't directly use. > > ACK > > Can I just edit /var/lib/portage/world? Or do I need to do something > else? It's a plain text file and I've edited it in the past with no problems. I've done that cleanup before and it can take some time to accomplish depending on how bad it is. I went through this when I first started using Gentoo and didn't know any better. I'd do small chunks and keep a versioned back up file just in case. I've also used the script once. It does fairly well. It may miss a couple here and there and may have a few false positives as well. Still it can do some heavy lifting for you. I'd copy the world file to a safe place and try the script. I'd try it once with the old world file in place and once without a world file at all. Then see which one works best. If that fails, do it manually. Good luck. I hope one or the other works. Dale :-) :-)
Aw: Re: Re: [gentoo-user] Updating portage, continued
The handbook is great information, but unfortunately, it uses concepts - specific gentoo concepts - that many readers doesn't know. They are then often cross-referenced to other pages, which likewise define things based on expected internal understanding of the mechanisms, goals, and potential scenarios. I have "read" the handbook - multiple times. But not really understood what it was saying - and I have decades of development experience. Consider slots. I'm sure I've read that slots are used to allow multiple ... versions? configurations? of the same package to be installed. It was gradually dawning on me, that it's the developer who specifies the slot. Now, I can't figure out what use case that benefits, but the ability to have slots react to realities at a particular installation see to me to make a lot of sense. So, there must be something basic that I don't understand. I think cases like my simple case would help new comers and I'm hoping to make a blog describing it, once I fully understand the implications. > Gesendet: Mittwoch, 05. Juni 2019 um 00:31 Uhr > Von: "Neil Bothwick" > An: gentoo-user@lists.gentoo.org > Betreff: Re: Re: [gentoo-user] Updating portage, continued > > On Tue, 4 Jun 2019 21:56:14 +0200, n952...@web.de wrote: > > > Apparently, rddtool got installed with harmless, default values, which, > > however, are not sufficient for monitorix. So, now I can accept the > > changes, and re-emerge rddtool - or probably, emerging monitorix will > > arrange for that. > > It will, portage lnows that monitorix needs rrdtool with the extra USE > flags and will take care of it, now you have given it permission. > > > Then, if someday, I get a nasty message that there's a keyword > > conflict, I'll have to sacrifice either the new package or monitorix ... > > > > In the meantime, I'll install this package and that, and some of them > > may be dependent on rrdtool. In that case, unless they explicitly > > disallow that unmasked version, they'll use the same, possibly > > experimental, version. When the day comes that I have to back the > > unmasked version of rrdtool out, then all other dependent packages will > > get the standard, default version again. > > You aren't changing the version, this has nothing to do with keyword > masking. You will get the same version of rrdtool, but with extra > features compiled in - that's what USE flags do. > > > I'm catching on, bit by bit ;-) > > It can take a while, but you would probably find it useful to read the > rest of the Gentoo Handbook. Many people read it to install and boot > their Gentoo system, but that is only the first part. The rest contains > useful information on running and maintaining a Gentoo system. > > > -- > Neil Bothwick > > A pessimist is an optimist who's given it some thought. >
Re: Re: Re: [gentoo-user] Updating portage, continued
> Consider slots. I'm sure I've read that slots are used to allow multiple > ... versions? configurations? of the same package to be installed. It was > gradually dawning on me, that it's the developer who specifies the slot. > Now, I can't figure out what use case that benefits, but the ability to > have slots react to realities at a particular installation see to me to > make a lot of sense. So, there must be something basic that I don't > understand. > Multiple versions. Some software only works with a specific version of a dependency, so to ensure wide coverage of dependencies, multiple versions of the same software is required. Eg, some software may only work with python version 2.7 and other software may only work with python 3.6. If both versions of python are still being software maintained, an author may decide its not their top priority to re-write their software that's based on 2.7 to work with 3.6.
