Re: [gentoo-user] Service not started at specified runlevel
I found the solution while writing this message. Still, I don't know why it works. Here goes the steps I followed (so that anyone searching for a solution in those terms can find it): > Try running 'strace' on ' rc-service auditd start'. See if that helps pin > down the problem. I did that, but couldn't detect anything wrong in the trace log (though I must say, it's the 1st time I used strace...), comparing to dbus, they do mostly the same system calls, obviously the messages written and memory addresses are different, both warn about the PID file not existing yet, and both work. But auditd is not started at boot despite having been set to start at the default runlevel, and rc-status does not detect it. I think the warning messages don't really matter (for this question, the fact is that OpenRC should be more patient), they're the same and appear for many working services. Now, rc-status is a link to openrc. Consulting the documentation and thinking of links, wondering what was being done differently for these services, I noticed I hadn't patched /etc/init.d/auditd with the usual shebang line '#!/usr/bin/openrc-run' instead of the /sbin one. I didn't patch long ago because I didn't see the purpose of changing it when /sbin is a link to /usr/bin in Arch Linux. Solution: $ rc-status -s |grep audit >/dev/null ; echo $? # not working 1 # sed -e 's|\#\!/sbin/openrc-run|/usr/bin/openrc-run|' \ -i /etc/init.d/auditd $ rc-status -s |grep audit >/dev/null ; echo $? # ok now! 0 Still, with this patch, the link works for /sbin/auditd (I didn't replace it on purpose). Why doesn't the link work in the shebang line? And why does it only not work for rc-status and at boot, but starting the service manually works normally? Thanks for the advice, it guided me to the solution eventually, but I'm still curious and OpenRC is still buggy. Why? João Miguel
[gentoo-user] Service not started at specified runlevel
Hello,
I am not using Gentoo, but if I ask this on the Arch Linux mailing lists
I may get flamed, get no response, or both. I'm using OpenRC version
0.16.4, along with the audit init script from Gentoo (I'm attaching it
anyway for future reference). Note: I added the depend() function
(trying various dependencies) hoping it would have an effect on the
service being started at the specified runlevel (it didn't).
Here's my problem:
# ls /etc/runlevels/default/auditd
/etc/runlevels/default/auditd
# rc-service auditd start ; echo $?
auditd | * Starting auditd ...
auditd | * start-stop-daemon: fopen `/var/run/auditd.pid': No such
file or directory
auditd | * Detaching to start `/sbin/auditd' ...
[ ok ]
auditd | * Loading audit rules from /etc/audit/audit.rules
0
# rc-status -s | grep audit ; echo $?
1
I have no idea of why it complains that file does not exist when running
/sbin/auditd manually creates it right away. auditd works normally when
started with the init script, but although I did 'rc-update add auditd
default', it simply does not start when that runlevel is reached. dhcpcd
and a few other services complain of the pid file not existing too and
start at their runlevels. I think the warning is unrelated, openrc is
likely checking for the PID files' existance too soon.
Also, I'm using rc_parallel="YES", but have tried with "NO" and get the
same result (i.e. no evidence of auditd even existing).
I don't get it, I've created my own init script for other services, and
those show up on rc-status, if I add them to some runlevel, no matter
whether they fail, throw warnings, or start normally, they appear both
at boot and I can check later in /var/log/rc.log. The only abnormal
service is auditd. What is going on? Did I do something wrong?
Thank you in advance,
João Miguel
#!/sbin/openrc-run
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
extra_started_commands='reload reload_auditd reload_rules'
description='Linux Auditing System'
description_reload='Reload daemon configuration and rules'
description_reload_rules='Reload daemon rules'
description_reload_auditd='Reload daemon configuration'
name='auditd'
pidfile='/var/run/auditd.pid'
command='/sbin/auditd'
depend()
{
# expl. dhcpcd:
#provide net
#need localmount
#use logger network
#after bootmisc modules
#before dns
:
}
start_auditd() {
# Env handling taken from the upstream init script
if [ -z "$AUDITD_LANG" -o "$AUDITD_LANG" = "none" -o "$AUDITD_LANG" =
"NONE" ]; then
unset LANG LC_TIME LC_ALL LC_MESSAGES LC_NUMERIC LC_MONETARY
LC_COLLATE
else
LANG="$AUDITD_LANG"
LC_TIME="$AUDITD_LANG"
LC_ALL="$AUDITD_LANG"
LC_MESSAGES="$AUDITD_LANG"
LC_NUMERIC="$AUDITD_LANG"
LC_MONETARY="$AUDITD_LANG"
LC_COLLATE="$AUDITD_LANG"
export LANG LC_TIME LC_ALL LC_MESSAGES LC_NUMERIC LC_MONETARY
LC_COLLATE
fi
unset HOME MAIL USER USERNAME
ebegin "Starting ${name}"
start-stop-daemon \
--start --quiet --pidfile ${pidfile} \
--exec ${command} -- ${EXTRAOPTIONS}
local ret=$?
eend $ret
return $ret
}
stop_auditd() {
ebegin "Stopping ${name}"
start-stop-daemon --stop --quiet --pidfile ${pidfile}
local ret=$?
eend $ret
return $ret
}
loadfile() {
local rules="$1"
if [ -n "${rules}" -a -f "${rules}" ]; then
einfo "Loading audit rules from ${rules}"
/sbin/auditctl -R "${rules}" >/dev/null
return $?
else
return 0
fi
}
start() {
start_auditd
local ret=$?
if [ $ret -eq 0 -a "${RC_CMD}" != "restart" ]; then
loadfile "${RULEFILE_STARTUP}"
fi
return $ret
}
reload_rules() {
loadfile "${RULEFILE_STARTUP}"
}
reload_auditd() {
ebegin "Reloading ${SVCNAME}"
start-stop-daemon --signal HUP \
--exec "${command}" --pidfile "${pidfile}"
eend $?
}
reload() {
reload_auditd
reload_rules
}
stop() {
[ "${RC_CMD}" != "restart" ] && loadfile "${RULEFILE_STOP_PRE}"
stop_auditd
local ret=$?
[ "${RC_CMD}" != "restart" ] && loadfile "${RULEFILE_STOP_POST}"
return $ret
}
Re: [gentoo-user] Can I suppress the bleep when shutting down?
> 'modprobe -r pcspkr' should remove the offending beep. >> No, no, no! I don't want to disable my loudspeaker! For example, I get >> beeps through my ssh connection with my ISP telling me that new mail has >> arrived. He just wants to disable it _on shutdown_, not always. João Miguel
Re: [gentoo-user] Boot Media Admin CD
> Hello, > > On the download pages I found this interesting choice for AMD64:: > Boot Media Admin CD:: > https://www.gentoo.org/downloads/ > > Anyone know what an .admin cd. is? Anyone tested it yet? Hmm I hadn't seen it, but it seems pretty similar to the minimal installation CD, except it has a different logo. In fact, it calls itself a «minimal installation CD», boots in exactly the same way (boot prompt, keymap choice, loading tons of modules, etc.) So I'm guessing it has a few more things than the standard ISO, maybe some things that were deemed unnecessary for the minimal install, but that may be useful, I don't know, if you mess up your bootloader, or maybe it has some statically compiled binaries that you can copy and use on your main system if something is broken... But that's just a guess. The easiest way to know the difference may be to mount the ISOs, the SquashFSs inside, and compare the files... If you want to try it, you can do: $ qemu-system-x86_64 -m 1G -hda admincd.iso -enable-kvm Thanks for the question. Now I'm curious too :-D João Miguel
Re: [gentoo-user] Root device as UUID not properly detected
Nevermind the last message. I'll put this problem aside until I find the time to solve it on my own. > > > I never used an initrd when building my own USB sticks. > > I don't know, I always used an initrd. Though I must say, that is the > > phase of starting the PC I understand the worst. > On the machines where I use an initrd, I write my own scripts as I find the > creators (genkernel, dracut) to not be intelligent enough. It doesn't sound as hard as I thought. I'm tired of fighting genkernel. I know the problem is initrd, it's where it fails. Since there is no mkinitcpio package, I'll try those scripts. I will follow https://wiki.gentoo.org/wiki/Early_Userspace_Mounting. If something goes wrong (when I actually try), I'll make a new thread. Or maybe I will just try and copy the initrd and kernel image from the Gentoo recovery pen... Anyway, I'll post here when I figure it out. João Miguel
Re: [gentoo-user] Root device as UUID not properly detected
On Wed, Oct 07, 2015 at 12:17:51PM +0200, J. Roeleveld wrote:
> > > > > 2. USB port is not supported by kernel
> > > > I'm not sure what you mean. Is there any option I should enable for
> > > > genkernel? I read on the Wiki page that
> > > It works with Arch, are you using the same kernel options now with Gentoo?
> > Yeah, I tried many more here actually, with Arch I only need APPEND root=...
> > (no rootfstype, ro, rw, rootdelay, etc.).
> What about kernel config?
I was not sure about this, but
https://wiki.archlinux.org/index.php/Kernel_parameters says:
There are three ways to pass options to the kernel and thus control its
behaviour:
1. When building the kernel. See Kernel Compilation for details.
2. When starting the kernel (usually, when invoked from a boot loader).
3. At runtime (through the files in /proc and /sys). See sysctl for details.
So I'm using 2.
> > > > > 3. You don't use root_delay as boot option
> > > > If that's what I think it is, I tell syslinux to wait 5 seconds.
> > (turns out it's not what I thought it was, though I did try root_delay, it
> > is actually rootdelay...)
> > > How do you tell it that?
> > Here's my syslinux.cfg with more comments:
> > PROMPT 1
> > TIMEOUT 50 # <-- here
> That timeout is for the prompt, eg. how long the bootloader waits.
Yes, but I do tell it to wait (and as I said, I didn't know what rootdelay
was).
> It will not have any effect for the drivers in the kernel to finish detecting
> the USB devices.
> > APPEND rootdelay=5 root=UUID="6fc386ff-8342-42a2-be02-51a6eccf8430"
> > rootfstype=ext4
No, but this --^^^-- should.
> Did you test with the PARTUUID value ("9c...") instead of the other one?
>
> Also, I always ended up setting the rootdelay to 10 or higher. (It's in
> seconds, not minutes)
New append line:
APPEND rootdelay=15 root=PARTUUID="9c4f6479-9dd7-4a8f-86f2-f1320cc15aa5"
rootfstype=ext4
Again, I see no difference using rootdelay. With PARTUUID though, I get "Could
not find the root device in ." right away, rather than "Could not find the root
device in UUID=...". With PARTUUID, I can't boot it anywhere without manually
writing the UUID (not PARTUUID) or device file. Though on my system, the
following works:
# mount PARTUUID="9c4f6479-9dd7-4a8f-86f2-f1320cc15aa5" /mnt/pen
So now I'm even more confused. Everything about this pen works, as does
everything in the PCs I tried. Syslinux also works. It's somewhere after
loading the modules, in the initrd.
Thinking of it now, I remember the PC that never finds the root device
requires intel microcode early, which is loaded along with the initrd.
Because of this problem I need to turn many PCs on and off a few times
in a row, and I noticed that the pendrive blinks at least on BIOS, when
syslinux is finding initrd and the kernel, and when the machine finds
the root device. Now, what I noticed is that in the VM, it blinks right
away (as it finds root right away); in many PCs it takes a while to
blink, only blinking after the 1st attempt on mounting to newroot has
been done; and in some others it never blinks.
> > > I never used an initrd when building my own USB sticks.
> > I don't know, I always used an initrd. Though I must say, that is the
> > phase of starting the PC I understand the worst.
> On the machines where I use an initrd, I write my own scripts as I find the
> creators (genkernel, dracut) to not be intelligent enough.
The thing is, I'm less intelligent than those creators. I'm not very
familiar with the way that early boot phase works, much less with
writing scripts to make it work. Unless you have an idea of how I can
use the scripts to solve this problem. In Arch I use mkinitcpio. I'm
aware it is available for Gentoo as well, nonetheless using genkernel is
killing two birds with one stone, it should be a simpler solution, so
I'd like to go with that one. If it works for a Gentoo recovery drive,
why shouldn't it work for this one?
> > > I was talking about:
> > > rootdelay= [KNL] Delay (in seconds) to pause before
> > > attempting to
> > > mount the root filesystem
> > > (See the file "kernel-parameters.txt" in the kernel Documentation)
> > (I'm guessing I'm not supposed to include this in the boot loader config...)
> The "rootdelay=..." part needs to be added to the boot loader config.
Ah, then I'm glad I did. Although it seems to do nothing really...
Sorry for the large response. I probably forgot something, took a while
amidst writing and testing.
João Miguel
Re: [gentoo-user] Root device as UUID not properly detected
How do I know if any of these happen? > Possible causes: > 1. USB stick doesn't work as boot device Well, it did with Arch, the boot partition has the boot, legacy_boot and esp flags. Plus if anything was to be problematic, I'd assume it would be BIOS or syslinux detection of the drive bootable device, not mounting. > > 2. USB port is not supported by kernel I'm not sure what you mean. Is there any option I should enable for genkernel? I read on the Wiki page that > > 3. You don't use root_delay as boot option If that's what I think it is, I tell syslinux to wait 5 seconds. It does work. In every computer. It's when it starts loading modules and all, reaching the point where initrd needs to mount the root device that it gives an error. I don't know how to tell it to wait there though. And as I said, even if I did, it wouldn't work on all computers, on some initrd cant figure it out at all. > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. No problem, thanks for the response. I'm just baffled with this error. João Miguel
Re: [gentoo-user] Root device as UUID not properly detected
> > > Possible causes: > > > 1. USB stick doesn't work as boot device > Ok, so scratch that one. Okay, done. > > > 2. USB port is not supported by kernel > > > > I'm not sure what you mean. Is there any option I should enable for > > genkernel? I read on the Wiki page that > > It works with Arch, are you using the same kernel options now with Gentoo? Yeah, I tried many more here actually, with Arch I only need APPEND root=... (no rootfstype, ro, rw, rootdelay, etc.). > > > 3. You don't use root_delay as boot option > > If that's what I think it is, I tell syslinux to wait 5 seconds. (turns out it's not what I thought it was, though I did try root_delay, it is actually rootdelay...) > How do you tell it that? Here's my syslinux.cfg with more comments: PROMPT 1 TIMEOUT 50 # <-- here DEFAULT gentoo LABEL gentoo LINUX ../kernel-genkernel-x86-4.0.5-gentoo INITRD ../initramfs-genkernel-x86-4.0.5-gentoo APPEND rootdelay=5 root=UUID="6fc386ff-8342-42a2-be02-51a6eccf8430" rootfstype=ext4 # ^^--- I added this just now because you said so, though in the last message I had root_delay # Neither of those has any effect (conditions 2 and 3 I told you about remain as they were) # (as I thought this has nthing to do with the bootloader) # pen (normalmente /dev/sdb4): UUID="6fc386ff-8342-42a2-be02-51a6eccf8430" TYPE="ext4" PARTLABEL="Root Gentoo GNU/Linux" PARTUUID="9c4f6479-9dd7-4a8f-86f2-f1320cc15aa5" > I never used an initrd when building my own USB sticks. I don't know, I always used an initrd. Though I must say, that is the phase of starting the PC I understand the worst. > I was talking about: > rootdelay= [KNL] Delay (in seconds) to pause before attempting to > mount the root filesystem > > (See the file "kernel-parameters.txt" in the kernel Documentation) (I'm guessing I'm not supposed to include this in the boot loader config...) > That's a default signature... :) Ah, so that's why it showed with a couple of dashes above it :) All the best, João Miguel
[gentoo-user] Root device as UUID not properly detected
Hello all, I have decided to make a pen drive with Gentoo Linux installed, to have a permanent pocket installation I can use in any computer as if it were my own. The Gentoo Wiki guided me very well through it. The problem I'm having only appears when I try to boot the pen drive physically. That is, if I use a VM as such: $ qemu-system-i386 -hda /dev/sdb -enable-kvm -m 2G I have no error messages displayed. However, if I try to boot it from a real PC, I get an error message alike "Could not find the root block device in UUID=...". Now what is weird is this: in some PCs, if I click Enter to try and use the same device, the system boots normally, or if I drop to the shell, I can do blkid and see the root partition (usually sdb4 or sdc4). But in at least one PC, the root device is not detected. The same message appears even if I try for minutes. If I manually enter the UUID or partition, it doesn't work either. It shows "Could not find the root block device in ." (like in this question https://forums.gentoo.org/viewtopic-t-971416.html) The command I used to make the kernel and initram was # genkernel --install --disklabel all as I need basic support for any hardware. I also found https://forums.gentoo.org/viewtopic-t-701116-start-0.html, I expect the --disklabel option to help but the results are the same. I use both UUIDs in /etc/fstab and /boot/syslinux/syslinux.cfg (tried setting real_root and rootfstype besides root, no difference). What sense does this problem make?! The BIOS sees the pen, syslinux boots it using the UUID, why does the system suddenly forget where the pen is? Why does it have different behaviours in different computers, and no problem as a VM? Is this a problem with the initrd, or with mdev? I had a pen like this with Arch Linux and it ran just fine, maybe it was because it used udev instead? I hope you can help me, it's the 1st time I try Gentoo and it was going so well! Thank you in advance, João Miguel
Re: [gentoo-user] Root device as UUID not properly detected
> Did you try other USB sticks, which you know work in other machines, > in that one machine ? Otherwise, it mb something awry in that machine. Yes I did. As I said, I had such a USB stick with Arch Linux installed, and it worked there just fine. In fact, I tried just now (to make sure, though with a recovery drive, uses isolinux), and it's ok. Note there are really 3 levels of "working": 1 - works flawlessly - only VM for this pen 2 - initrd doesn't recognize the disk on the 1st attempt to mount root, works after waiting a few seconds and trying again (not waiting enough gives an error again) 3 - initrd doesn't recognize the disk ever (I went up to 5 mins, sounds more than enough) That PC is in 3. But any other disk I tried so far works. And I never had this error before, with any sort of pen, including the Gentoo recovery/install pen which supposedly uses genkernel as I do here, but somehow initrd always works with it (case 1). The fact that 2 does happen for every other PC says there is actually something awry, but I think it's with the initrd. The thing is that BIOS knows the pen is there, syslinux also detects it right away and knows where the root partition is with UUID, and still the initrd can't figure it out right away? Best regards, João Miguel
