Re: [gentoo-user] what pgm is rotating my /var/log/syslog, etc. files?

[Mick]

On Tuesday, 20 August 2019 01:05:37 BST n952162 wrote:
> I have two gentoo machines, my primary one and one I cloned off of that.
> 
> The original gentoo machine has lots of nice /var/log/syslog.1.gz, etc.
> files.
> 
> The clone has one big /var/log/syslog file.
> 
> I now have logrotate installed in both machines.  I see that the
> original has cronie installed and an /etc/cron.daily/logrotate file, but
> that corresponding  /etc/logrotate configuration file does not list any
> of the important  syslog, kern.log, etc files.
> 
> When I do as /etc/cron.daily/logrotate does:
> 
>sudo /usr/bin/logrotate -v /etc/logrotate.conf
> 
> I get debug output that shows it does only what /etc/logrotate.conf
> tells it to do.  And syslog, etc. are not touched.
> 
> Could it be that there's another facility that's doing that work?

Installed apps which are cognizant of logrotate install their config for 
rotation in /etc/logrotate.d/

The syslog-ng package installs this file by default:

~ # cat /etc/logrotate.d/syslog-ng
#
# Syslog-ng logrotate snippet for Gentoo Linux
# contributed by Michael Sterrett
#

/var/log/messages {
missingok
sharedscripts
postrotate
/etc/init.d/syslog-ng reload > /dev/null 2>&1 || true
endscript
}

which corresponds to the only log file created by syslog-ng as a default.  If 
you alter the configuration to capture/filter/record different syslog-ng 
outputs, then you'll have to add your own logrotate configuration, either in /
etc/logrotate.d/syslog-ng itself, or in additional files.

Are the two systems identical in terms of the syslog-ng config and *all* the 
logrotate config files?
 
-- 
Regards,

Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] what pgm is rotating my /var/log/syslog, etc. files?

[n952162]

I have two gentoo machines, my primary one and one I cloned off of that.

The original gentoo machine has lots of nice /var/log/syslog.1.gz, etc.
files.

The clone has one big /var/log/syslog file.

I now have logrotate installed in both machines.  I see that the
original has cronie installed and an /etc/cron.daily/logrotate file, but
that corresponding  /etc/logrotate configuration file does not list any
of the important  syslog, kern.log, etc files.

When I do as /etc/cron.daily/logrotate does:

  sudo /usr/bin/logrotate -v /etc/logrotate.conf

I get debug output that shows it does only what /etc/logrotate.conf
tells it to do.  And syslog, etc. are not touched.

Could it be that there's another facility that's doing that work?

Re: [gentoo-user] KDE machine -> Shutdown icons gone walkabout

[Jack]

On 2019.08.19 14:40, Mick wrote:

On Monday, 19 August 2019 19:21:02 BST Andrew Lowe wrote:
> Hi all,
>I recently, last week or so, did some updating of my KDE desktop
and
> when I went to select "Shutdown" off the menu bar thingy, no icons  
for
> "Logout", "Shutdown" & "Some Other Thing" appeared as they used to.  
I in
> turn had to open up a shell, su and then "shutdown -t now" to bring  
the
> machine down. Have I missed something somewhere as to why I no  
longer
> get the icons? Has something been broken down into smaller bits and  
I

> now have to emerge something else to get the icons back?
>
>Thoughts greatly appreciated,
>
>Andrew

Do you have consolekit or elogind installed and running?
--
Regards,

Mick

The problem is mentioned in the KDE/Troubleshooting article in the Wiki:
https://wiki.gentoo.org/wiki/KDE/Troubleshooting#Missing_shutdown.2Freboot.2Fsuspend.2Fhibernate_buttons_.28with_consolekit.29  
in case that might help.

Re: [gentoo-user] static addr in /etc/conf.d/net ignored, dhcp used. dhcpcd crashes when forced

[n952162]

You were right, thank you.  When I put net.enp2s0 back in, it came up on
reboot this time - the interface, that is.  I guess there was something
else wrong when I still had it in the defaul runlevel.  My faith in
openrc is restored :-)


On 08/19/19 22:35, n952162 wrote:

On 08/19/19 20:04, J. Roeleveld wrote:

On 19 August 2019 22:11:04 CEST, n952162  wrote:

My eth0/enp2s0 network adapter is configured so:

$ cat /etc/conf.d/net

config_enp2s0="192.168.179.20/24"

...

Why does dhcpcd think it can configure my interface and what's the
connection between /etc/conf.d/net and dhcpcd?

Do you have net.enp2s0 in your default runlevel?
If not, dhcp is used by default.

--
Joost


I had that and took it out in the hope that it wouldn't try to do
anything with the interface until instructed to do so.

What program is it that decides that it has to do something with the
interface if there are no instructions otherwise?  That is, the
default case?  udev?  I don't think so.  init?

I see in /etc/inittab:

  l3:3:wait:/sbin/openrc default

but surely openrc doesn't service network adapters itself?

I currently have:

00~>rc-status
Runlevel: default
 sysklogd [  started  ]
 sshd [  started  ]
 wpa_supplicant [  stopped  ]
 dhcpcd [  crashed  ]
 netmount [  started  ]
 virtualbox-guest-additions [  stopped  ]
 cronie [  started  ]
 acpid [  started  ]
 local [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
 dbus [  started  ]
 modules-load [  started  ]
Dynamic Runlevel: manual
 net.enp2s0 [  started  ]

I guess the answer to my question is probably that dhcpcd takes that
responsibility on for itself.  Is there an option to dhcpcd that says
- "just do as you're told"?

But then, what program is it that reads /etc/conf.d/net?  That program
gets to run when dhcpcd crashes?

Re: [gentoo-user] static addr in /etc/conf.d/net ignored, dhcp used. dhcpcd crashes when forced

[J. Roeleveld]

On 19 August 2019 22:11:04 CEST, n952162  wrote:
>My eth0/enp2s0 network adapter is configured so:
>
>$ cat /etc/conf.d/net
>
>config_enp2s0="192.168.179.20/24"
>
>but on boot, I get a bonjour address:
>
>enp2s0    Link encap:Ethernet  HWaddr 48:BA:4E:29:99:9E
>   inet addr:*169.254.71.117 * Bcast:169.254.255.255 
>Mask:255.255.0.0
>
>if I restart the service immediately after boot, nothing much happens,
>I
>still get the bonjour address.
>
>sudo rc-service net.enp2s0 restart
>
>Incidently, dhcpcd is still running at this point.
>
>But after a couple of tries:
>
>sudo rc-service net.enp2s0 restart
>
>and then I get my connection:
>
>$ ifconfig
>enp2s0    Link encap:Ethernet  HWaddr 48:BA:4E:29:99:9E
>   inet addr:*192.168.179.20* Bcast:192.168.179.255 
>Mask:255.255.255.0
>
>And:
>
>$ sudo rc-service dhcpcd status
>  * status: *crashed*
>
> From /var/log/syslog:
>
>
>[  260.895907] dhcpcd[6664]: segfault at 400a ip
>560edbf464bd sp 7ffe06bf4f10 error 4 in
>dhcpcd[560edbf23000+46000]*
>
>*
>
>Why does dhcpcd think it can configure my interface and what's the
>connection between /etc/conf.d/net and dhcpcd?

Do you have net.enp2s0 in your default runlevel?
If not, dhcp is used by default.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] static addr in /etc/conf.d/net ignored, dhcp used. dhcpcd crashes when forced

[n952162]

I just ran into this, from  https://wiki.gentoo.org/wiki/Dhcpcd


 /Static IP addresses/

   //

   /In case the network interface card should be configured with a
   //static IP address //,
   add their data to ///etc/dhcpcd.conf//.//^[1]
    //The
   following is an example of manually adding a static address, routes,
   and DNS by editing DHCPCD's configuration file using a text editor
   of choice: /

   //
   /FILE*|/etc/dhcpcd.conf|*//**/

   /static ip_address=192.168.0.10/24/


(haven't tried it yet, my system is busy right now).

So, what is /etc/conf.d/net for?  What programs read it?




On 08/19/19 20:11, n952162 wrote:


My eth0/enp2s0 network adapter is configured so:

$ cat /etc/conf.d/net

config_enp2s0="192.168.179.20/24"

but on boot, I get a bonjour address:

enp2s0    Link encap:Ethernet  HWaddr 48:BA:4E:29:99:9E
  inet addr:*169.254.71.117 * Bcast:169.254.255.255 
Mask:255.255.0.0

if I restart the service immediately after boot, nothing much happens,
I still get the bonjour address.

sudo rc-service net.enp2s0 restart

Incidently, dhcpcd is still running at this point.

But after a couple of tries:

sudo rc-service net.enp2s0 restart

and then I get my connection:

$ ifconfig
enp2s0    Link encap:Ethernet  HWaddr 48:BA:4E:29:99:9E
  inet addr:*192.168.179.20* Bcast:192.168.179.255 
Mask:255.255.255.0

And:

$ sudo rc-service dhcpcd status
 * status: *crashed*

From /var/log/syslog:

[  260.895907] dhcpcd[6664]: segfault at 400a ip
560edbf464bd sp 7ffe06bf4f10 error 4 in
dhcpcd[560edbf23000+46000]*

*

Why does dhcpcd think it can configure my interface and what's the
connection between /etc/conf.d/net and dhcpcd?

Re: [gentoo-user] A bit O/T: Running android apps in QEMU

[Petric Frank]

Hello,

not exactly. But in Android Studio (which uses Android SDK) is bundled an
emulator using qemu. Android Studio allows you to download an Android image
(Android 2.0 up to Android 9) compiled for x86 and run it.
This is mainly used for testing apps developed under Android Studio.
Maybe this could also be used standalone.

regards
  Petric

Am Montag, 19. August 2019, 20:36:01 CEST schrieb Mick:
> Increasingly more and more services I prefer to access online keep asking me
> to download and use some app to be able to enjoy the goodness of their
> offering in the future.  Invariably these are Android apps they think their
> customers will want to use.  I don't have an android phone, but have QEMU
> installed.  I was wondering if I can run some/any of these apps as VM
> guests within QEMU, on my amd64 Gentoo.
>
> I had a look at this wiki page, but I'm not sure if all this is required
> just to run some arm binary, when I don't need/want to compile software on
> ARM:
>
> https://wiki.gentoo.org/wiki/Embedded_Handbook/General/
> Compiling_with_qemu_user_chroot
>
> I assume if I follow the instructions on the page I should be able to
> install some Android image as a guest, then install the requisite app in
> the guest and run it?  Or is it more complicated than this and it won't run
> unless I install it in a real smart phone, I'm connected to a cell tower at
> the time and give them my phone number too?
>
> My understanding of emulating an altogether different CPU arch in QEMU is
> non- existent, I've always run x86 guest OS'/apps on x86 gentoo hosts.  Do
> you have any relevant experience you could share?

[gentoo-user] Re: A bit O/T: Running android apps in QEMU

[Nikos Chantziaras]

On 19/08/2019 21:36, Mick wrote:

I was wondering if I can run some/any of these apps as VM guests
within QEMU, on my amd64 Gentoo.


You can, although it seems very complicated to make it work. Projects 
like Anbox (https://github.com/anbox/anbox) exist for that reason. 
Unfortunately, Anbox is not in portage so you'll have to build from source.

Re: [gentoo-user] KDE machine -> Shutdown icons gone walkabout

[Mick]

On Monday, 19 August 2019 19:21:02 BST Andrew Lowe wrote:
> Hi all,
>   I recently, last week or so, did some updating of my KDE desktop 
and
> when I went to select "Shutdown" off the menu bar thingy, no icons for
> "Logout", "Shutdown" & "Some Other Thing" appeared as they used to. I in
> turn had to open up a shell, su and then "shutdown -t now" to bring the
> machine down. Have I missed something somewhere as to why I no longer
> get the icons? Has something been broken down into smaller bits and I
> now have to emerge something else to get the icons back?
> 
>   Thoughts greatly appreciated,
> 
>   Andrew

Do you have consolekit or elogind installed and running?
-- 
Regards,

Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] A bit O/T: Running android apps in QEMU

[Mick]

Increasingly more and more services I prefer to access online keep asking me 
to download and use some app to be able to enjoy the goodness of their 
offering in the future.  Invariably these are Android apps they think their 
customers will want to use.  I don't have an android phone, but have QEMU 
installed.  I was wondering if I can run some/any of these apps as VM guests 
within QEMU, on my amd64 Gentoo.

I had a look at this wiki page, but I'm not sure if all this is required just 
to run some arm binary, when I don't need/want to compile software on ARM:

https://wiki.gentoo.org/wiki/Embedded_Handbook/General/
Compiling_with_qemu_user_chroot

I assume if I follow the instructions on the page I should be able to install 
some Android image as a guest, then install the requisite app in the guest and 
run it?  Or is it more complicated than this and it won't run unless I install 
it in a real smart phone, I'm connected to a cell tower at the time and give 
them my phone number too?

My understanding of emulating an altogether different CPU arch in QEMU is non-
existent, I've always run x86 guest OS'/apps on x86 gentoo hosts.  Do you have 
any relevant experience you could share?

-- 
Regards,

Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] KDE machine -> Shutdown icons gone walkabout

[Andrew Lowe]

Hi all,
	I recently, last week or so, did some updating of my KDE desktop and 
when I went to select "Shutdown" off the menu bar thingy, no icons for 
"Logout", "Shutdown" & "Some Other Thing" appeared as they used to. I in 
turn had to open up a shell, su and then "shutdown -t now" to bring the 
machine down. Have I missed something somewhere as to why I no longer 
get the icons? Has something been broken down into smaller bits and I 
now have to emerge something else to get the icons back?


Thoughts greatly appreciated,

Andrew

[gentoo-user] static addr in /etc/conf.d/net ignored, dhcp used. dhcpcd crashes when forced

[n952162]

My eth0/enp2s0 network adapter is configured so:

   $ cat /etc/conf.d/net

   config_enp2s0="192.168.179.20/24"

but on boot, I get a bonjour address:

   enp2s0    Link encap:Ethernet  HWaddr 48:BA:4E:29:99:9E
  inet addr:*169.254.71.117 * Bcast:169.254.255.255 
   Mask:255.255.0.0

if I restart the service immediately after boot, nothing much happens, I
still get the bonjour address.

   sudo rc-service net.enp2s0 restart

Incidently, dhcpcd is still running at this point.

But after a couple of tries:

   sudo rc-service net.enp2s0 restart

and then I get my connection:

   $ ifconfig
   enp2s0    Link encap:Ethernet  HWaddr 48:BA:4E:29:99:9E
  inet addr:*192.168.179.20* Bcast:192.168.179.255 
   Mask:255.255.255.0

And:

   $ sudo rc-service dhcpcd status
 * status: *crashed*

From /var/log/syslog:


   [  260.895907] dhcpcd[6664]: segfault at 400a ip
   560edbf464bd sp 7ffe06bf4f10 error 4 in
   dhcpcd[560edbf23000+46000]*

   *

Why does dhcpcd think it can configure my interface and what's the
connection between /etc/conf.d/net and dhcpcd?

Re: [gentoo-user] switch from gnome/systemd to xfce/openrc borked my system

[Rich Freeman]

On Mon, Aug 19, 2019 at 10:42 AM Raffaele Belardi
 wrote:
>
> Rich Freeman wrote:
> > Next time you do something like this, keep in mind that Gnome and xfce
> > can co-exist on the same system, and so can openrc and systemd.
>
> Good point, I did not know, in particular for the init systems I thought it 
> was exactly
> the opposite.
>

The only area of incompatibility I'm aware of are the
sysvinit-compatibility links.  Both sysvinit and systemd provide
implementations of common utilities like poweroff, halt, reboot,
telinit, and so on.  There is also init itself.

The versions that come with sysvinit are compatible with both sysvinit
and systemd.  If you don't have sysvinit then systemd can supply
these.  Systemd itself doesn't require these utilities but they are
useful both for compatibility and convenience.  (ie "systemctl
poweroff" works fine, as does sending the command via dbus, but
scripts or sysadmins might prefer to be able to just run "poweroff").
The versions of these supplied by systemd are not compatible with
sysvinit.

A USE flag toggles whether systemd installs these utilities.  If it
does then it blocks sysvinit.  So, you just have to switch that USE
flag to install the two in parallel.  If you don't have systemd
install "init" then you do need to have a kernel command line to
launch systemd directly as init.

Offhand I think that is really the only conflict between the two.
Systemd doesn't use anything but those compatibility utils from
sysvinit but it doesn't mind them being around, and nothing in
sysvinit/openrc should even notice that systemd is installed.

As long as you set the USE flag appropriately you can dual-boot
between the two very easily.  The only gotcha is keeping all your
configs up-to-date as openrc and systemd store things in different
places.  When you install systemd it takes a snapshot of many of your
openrc settings but that is a one-time operation.  Some of those
settings are hard to change if systemd isn't running as PID 1 - I
think the wiki has instructions for how to do this.

--
Rich

Re: [gentoo-user] switch from gnome/systemd to xfce/openrc borked my system

[Raffaele Belardi]

Rich Freeman wrote:

Next time you do something like this, keep in mind that Gnome and xfce
can co-exist on the same system, and so can openrc and systemd.


Good point, I did not know, in particular for the init systems I thought it was exactly 
the opposite.



At this point you're probably just going to want to troubleshoot what
you are left with, though you could consider reverting back to your
old config and starting over if you have backups/etc.


Backups? I'm a software developer, I can't afford spending time making backups 
(just kidding).
At this point of the boot process the system did very few things, the problem should be 
relatively easy to trace so I refuse to give up. Long nights ahead.



I imagine that not many people move from systemd to openrc, since the
latter is basically the default on Gentoo already.  If I were going to
migrate a working system between the two I would probably do it
stepwise:


Ha, this is the HOWTO I was looking for yesterday! Oh well, it'll be for next 
time.


Now, on a new install or a host I didn't care so much about uptime for
I'd probably do it your way, and just revert to a backup.  In a


Not really production environment but I have to fix it before the other users (the kids) 
come back from vacation or my reputation will quickly sink!


raffaele

Re: [gentoo-user] Re: switch from gnome/systemd to xfce/openrc borked my system

[Raffaele Belardi]

Daniel Frey wrote:

On 8/19/19 5:24 AM, Raffaele Belardi wrote:



Make sure you are using a kernel set up for openrc.


Good catch, although I'm not sure where to find that info in the available kernel log. 
I'll look better, I need to stop it from scrolling.




Did you update grub and remove the init= line that starts systemd?


Yes.

One of the last things printed in the kernel log is "random: crng init done". The random 
service is part (possibly the last service) of the boot runlevel which is entered after 
the sysinit runlevel. So apparently a lot of openrc stuff has already started 
successfully. Instead, nothing from the default runlevel is output. I'll re-check those 
services.




Hmm, is it possible that it's waiting for entropy? Try moving the mouse like a madman for 
20 seconds or so.


I read on the internet about the crng delay issue. I don't think this is the case because 
it hangs after it has finished the random rc script, but I'll give it a try.


raffaele

Re: [gentoo-user] Re: switch from gnome/systemd to xfce/openrc borked my system

[Peter Humphrey]

On Monday, 19 August 2019 13:24:05 BST Raffaele Belardi wrote:
> Mick wrote:
> > On Monday, 19 August 2019 07:41:20 BST Raffaele Belardi wrote:
> > 
> > You have 3 drives attached while you're trying to boot.  The kernel seems
> > to come to a stop after /dev/sdc.  It may need some driver for this
> > device/fs. I'd start by unplugging any drives which do not contain the
> > system you're trying to boot, then go through a step by step process of
> > installing/setting up openrc, DM and boot loader.
> 
> sdc is an external USB drive, I'll try to unplug that.
> 
> > The DM is not necessary to boot your system, but while you chrooted into
> > it
> > you might as well install and set up sddm as a DM - there are others but
> > be
> > careful they do not try to bring in 2/3 of Gnome and its dependencies too.
> 
> I'll do but first I want to see a working terminal, too much stuff to debug
> otherwise.
> > Re-install GRUB or whichever boot manager you use and make sure it points
> > to the correct kernel.  If you're on an UEFI system and you boot directly
> > using the kernel EFI stub, re-run efibootmgr to specify the kernel UEFI
> > will boot with, but first run fsck.vfat on the EFI partition just in case
> > this fs was messed up too.
> 
> It's grub2, non-UEFI. I don't normally reinstall it when I update the
> kernel, I only run grub-mkconfig. I did the same this time.
> 
> > Make sure you are using a kernel set up for openrc.
> 
> Good catch, although I'm not sure where to find that info in the available
> kernel log. I'll look better, I need to stop it from scrolling.

It may be possible to hit CTRL-s to pause the scrolling, then CTRL-q to resume 
it.

> > In /etc/rc.conf set up a log file and temporarily enable logging.  If any
> > openrc scripts fail and can't boot, you will able to look at the logs when
> > you chroot back into it - using less/cat/plain text editor.  ;-)
> 
> Good idea.
> 
> > I hope the above should allow you to boot, or at least arrive at some
> > meaningful failure message to resolve.
> 
> One of the last things printed in the kernel log is "random: crng init
> done". The random service is part (possibly the last service) of the boot
> runlevel which is entered after the sysinit runlevel. So apparently a lot
> of openrc stuff has already started successfully. Instead, nothing from the
> default runlevel is output. I'll re-check those services.
> 
> raffaele


-- 
Regards,
Peter.

Re: [gentoo-user] Re: switch from gnome/systemd to xfce/openrc borked my system

[Daniel Frey]

On 8/19/19 5:24 AM, Raffaele Belardi wrote:



Make sure you are using a kernel set up for openrc.


Good catch, although I'm not sure where to find that info in the 
available kernel log. I'll look better, I need to stop it from scrolling.




Did you update grub and remove the init= line that starts systemd?


In /etc/rc.conf set up a log file and temporarily enable logging.  If any
openrc scripts fail and can't boot, you will able to look at the logs 
when you

chroot back into it - using less/cat/plain text editor.  ;-)


Good idea.


I hope the above should allow you to boot, or at least arrive at some
meaningful failure message to resolve.



One of the last things printed in the kernel log is "random: crng init 
done". The random service is part (possibly the last service) of the 
boot runlevel which is entered after the sysinit runlevel. So apparently 
a lot of openrc stuff has already started successfully. Instead, nothing 
from the default runlevel is output. I'll re-check those services.




Hmm, is it possible that it's waiting for entropy? Try moving the mouse 
like a madman for 20 seconds or so.


Dan

Re: [gentoo-user] switch from gnome/systemd to xfce/openrc borked my system

[Rich Freeman]

On Mon, Aug 19, 2019 at 2:29 AM Raffaele Belardi
 wrote:
>
> Yesterday I tried to switch my ~amd64 box from Gnome/systemd to Xfce/openrc. 
> I followed
> the wiki [1], [2] to install Xfce from a Gnome terminal:
>
> - switch profile from 17.1/desktop/gnome/systemd to 17.1/desktop
> - emerge xfce4-meta and some xfce4 applications/panels/extras
> - unmerged systemd and emerged OpenRC
> - emerge -uDvN world to account for the different profile flags

Next time you do something like this, keep in mind that Gnome and xfce
can co-exist on the same system, and so can openrc and systemd.

At this point you're probably just going to want to troubleshoot what
you are left with, though you could consider reverting back to your
old config and starting over if you have backups/etc.

I imagine that not many people move from systemd to openrc, since the
latter is basically the default on Gentoo already.  If I were going to
migrate a working system between the two I would probably do it
stepwise:

1.  Rebuild the kernel with support for both systemd and openrc.  Boot
that (under systemd) and confirm it is working.
2.  Install xfce and get that working fine (under systemd).  That
really has no tie-in to the service manager but if you have this
working it is one less thing to mess with and it simplifies your
system.
3.  Install openrc and reboot under systemd just to make sure
everything is still working fine.  I forget what the defaults are but
you might need to tweak your systemd USE flags so that it uses the
sysvinit versions of halt/reboot/poweroff/telinit and so on.  It works
just fine with its own version of these tools or with sysvinit.
4.  Make sure you have your openrc configured the way you want it (I
don't think it has any issues with using rc-update and so on while
systemd is running, but I haven't tried that).
5.  Switch your kernel command line to boot with openrc, and make a
note of what it said before.  If it boots fine you're now running
openrc and just have to clean up the stuff you don't want.  If it
doesn't boot you just have to edit your command line and you're back
up and running with systemd until you sort it out.
6.  Switch your profile, do the -uDvN to rebuild anything impacted,
and depclean the stuff you don't need.  Reboot to test.

By doing it this way you will be just making one change at a time with
a reboot in-between so that you know what broke if something breaks.
The way you did it is potentially more time-efficient, but if
something breaks you are going to be hunting to figure out what it
was.  Since all the packages you're changing are capable of
co-existing there is no reason to switch cold turkey.

Now, on a new install or a host I didn't care so much about uptime for
I'd probably do it your way, and just revert to a backup.  In a
production environment where reboots are a concern I'd be working out
the procedure on a test host.

Oh, yeah, and step 0 is to make a backup...  :)

-- 
Rich

Re: [EXTERNAL] Re: [gentoo-user] multipath.conf : learning how to use

[Stefan G. Weichinger]

On 8/16/19 7:42 PM, Laurence Perkins wrote:

> Note that, in my experience at least, binary distros also tend to
> break hard if you leave them without updates for a year or more and
> then try to bring them current.  And they're usually harder to fix
> when they do. So make sure that whatever you put in is kept up to
> date.
> 
> The stable branch of a good binary distro has a big advantage
> there, especially with a snapshottable filesystem, because the
> updates can be handed off to a trained monkey, leaving the experts
> free for the important stuff.  But it's not a magic bullet.  If you
> don't write good documentation and keep the system up to date
> you'll end up in the exact same position a few years down the road
> no matter what distro you use.

I agree ... there'll be unattended updates automatically and I am
monitoring and using that server on a regular base anyway.

The goal now is to get a well-known state with less maintenance
complexity.

I am currently booking my tickets there ;-)

Re: [gentoo-user] switch from gnome/systemd to xfce/openrc borked my system

[Raffaele Belardi]

David Haller wrote:

Hello,

On Mon, 19 Aug 2019, Raffaele Belardi wrote:
[..]

During the emerge I had to hard reset the system [3] which obviously did not
boot so I found a PCLinuxOS live cd from 2014 and managed to chroot into the
partially updated system. I resumed the emerge successfully, unmerged gnome
and dependencies (this almost took more than building Xfce...), rebuilt the
kernel with the init system set to OpenRC (make && make install),


Did you also install the modules? (make modules_install)
Did you update the initrd?


No modules here, everything built in. Also no initrd.


Why not use 'genkernel'? The default-config should work in your case,
but you might look at the config anyway (/etc/genkernel.conf), e.g. at
the BOOTLOADER variable. Then 'cd' to your kernel-sources-dir and run
'genkernel --kerneldir=. all'.


I've always compiled the kernel directly so I am not familiar with genkernel. But I'll 
look again into my kernel's config and make sure it is the right kernel that's being loaded.


raffaele

Re: [gentoo-user] Re: switch from gnome/systemd to xfce/openrc borked my system

[Raffaele Belardi]

Mick wrote:

On Monday, 19 August 2019 07:41:20 BST Raffaele Belardi wrote:

You have 3 drives attached while you're trying to boot.  The kernel seems to
come to a stop after /dev/sdc.  It may need some driver for this device/fs.
I'd start by unplugging any drives which do not contain the system you're
trying to boot, then go through a step by step process of installing/setting
up openrc, DM and boot loader.


sdc is an external USB drive, I'll try to unplug that.


The DM is not necessary to boot your system, but while you chrooted into it
you might as well install and set up sddm as a DM - there are others but be
careful they do not try to bring in 2/3 of Gnome and its dependencies too.


I'll do but first I want to see a working terminal, too much stuff to debug 
otherwise.


Re-install GRUB or whichever boot manager you use and make sure it points to
the correct kernel.  If you're on an UEFI system and you boot directly using
the kernel EFI stub, re-run efibootmgr to specify the kernel UEFI will boot
with, but first run fsck.vfat on the EFI partition just in case this fs was
messed up too.


It's grub2, non-UEFI. I don't normally reinstall it when I update the kernel, I only run 
grub-mkconfig. I did the same this time.



Make sure you are using a kernel set up for openrc.


Good catch, although I'm not sure where to find that info in the available kernel log. 
I'll look better, I need to stop it from scrolling.



In /etc/rc.conf set up a log file and temporarily enable logging.  If any
openrc scripts fail and can't boot, you will able to look at the logs when you
chroot back into it - using less/cat/plain text editor.  ;-)


Good idea.


I hope the above should allow you to boot, or at least arrive at some
meaningful failure message to resolve.



One of the last things printed in the kernel log is "random: crng init done". The random 
service is part (possibly the last service) of the boot runlevel which is entered after 
the sysinit runlevel. So apparently a lot of openrc stuff has already started 
successfully. Instead, nothing from the default runlevel is output. I'll re-check those 
services.


raffaele

Re: [gentoo-user] switch from gnome/systemd to xfce/openrc borked my system

[David Haller]

Hello,

On Mon, 19 Aug 2019, Raffaele Belardi wrote:
[..]
>During the emerge I had to hard reset the system [3] which obviously did not
>boot so I found a PCLinuxOS live cd from 2014 and managed to chroot into the
>partially updated system. I resumed the emerge successfully, unmerged gnome
>and dependencies (this almost took more than building Xfce...), rebuilt the
>kernel with the init system set to OpenRC (make && make install),

Did you also install the modules? (make modules_install)
Did you update the initrd?

Why not use 'genkernel'? The default-config should work in your case,
but you might look at the config anyway (/etc/genkernel.conf), e.g. at
the BOOTLOADER variable. Then 'cd' to your kernel-sources-dir and run
'genkernel --kerneldir=. all'.

HTH,
-dnh

-- 
You know, I found myself right where I left me...

Re: [gentoo-user] Re: switch from gnome/systemd to xfce/openrc borked my system

[Mick]

On Monday, 19 August 2019 07:41:20 BST Raffaele Belardi wrote:
> Raffaele Belardi wrote:
> > One thing I notice from the boot log is that the root FS requires
> > recovery. My live CDs did not let me because they are too old  so I'll
> > try to find a more up to date live CD.
> Looking better at the kernel log, for sda1 (the root partition) it says:
> "Recovery complete" so I don't think a new live CD will help. I'm really
> out of ideas.
> 
> raffaele

You have 3 drives attached while you're trying to boot.  The kernel seems to 
come to a stop after /dev/sdc.  It may need some driver for this device/fs.  
I'd start by unplugging any drives which do not contain the system you're 
trying to boot, then go through a step by step process of installing/setting 
up openrc, DM and boot loader.

The DM is not necessary to boot your system, but while you chrooted into it 
you might as well install and set up sddm as a DM - there are others but be 
careful they do not try to bring in 2/3 of Gnome and its dependencies too.

Re-install GRUB or whichever boot manager you use and make sure it points to 
the correct kernel.  If you're on an UEFI system and you boot directly using 
the kernel EFI stub, re-run efibootmgr to specify the kernel UEFI will boot 
with, but first run fsck.vfat on the EFI partition just in case this fs was 
messed up too.

Make sure you are using a kernel set up for openrc.

In /etc/rc.conf set up a log file and temporarily enable logging.  If any 
openrc scripts fail and can't boot, you will able to look at the logs when you 
chroot back into it - using less/cat/plain text editor.  ;-)

I hope the above should allow you to boot, or at least arrive at some 
meaningful failure message to resolve.
-- 
Regards,

Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: switch from gnome/systemd to xfce/openrc borked my system

[Raffaele Belardi]

Raffaele Belardi wrote:


One thing I notice from the boot log is that the root FS requires recovery. My live CDs 
did not let me because they are too old  so I'll try to find a more up to date live CD.




Looking better at the kernel log, for sda1 (the root partition) it says: "Recovery 
complete" so I don't think a new live CD will help. I'm really out of ideas.


raffaele