Re: [gentoo-user] Unwelcomed non-native language support
Am 28.05.2015 um 17:35 schrieb gevisz: In my everyday work at the computer, I read and type at three or even four different languages. However, I do want to have all program menues and system messages only in English. So, when I found out that it can be achieved by setting -nls USE flag at my make.conf file, I did it, recompiled the system and for a few weeks enjoyed the full control of my Gentoo system. (As far as I can remember the gettext package was successfully depcleaned from my Gentoo system just after that.) However, after those few weeks (and some system updates), I have noticed that my system started to translate some system messages into one of the languages I use but which is not my native language. Moreover, running $ equery depends gettext I get about two fullscreens of packages that supposedly depend on gettext. Nevertheless, in all of them the -nls USE flag is either unset or absent. I have tried to depclean the gettext package from my system once again but portage just ignored my $ emerge --depclean gettext command. I think that it is some kind of a bug in the portage tree: when I set -nls USE flag globally, I do expect that the system messages will appear in English only and will not be translated in any other language, but the system understands that as I would have asked for a non-native language support. Of course, this is not my main problem in this life, but every time I get the system messages translated into my non-native language, I feel as I get a reminder that I do not have a full control of my Gentoo system. So, my questions are: 1. Is it a bug? 2. How can I get rid of those unwelcomed translations in the right way. 1. if a package hard depends on gettext, you can fiddle around with useflags as much as you want, it won't change. Not a bug. Just the way it is. 2. environment variables. Set them. LANG, LANGUAGE and of course LC_ALL
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 2:11 PM, cov...@ccs.covici.com wrote: Also, as Rich said, if you wait it's possible that systemd (and/or dracut) will drop you into a rescue shell anyway. Unfortunately, thanks to very slow hardware in the wild, the timeout has been increased to three minutes, and I believe those are *per hardware unit*. So if you have five disks, in theory it could take fifteen minutes to get you to a rescue shell. Thanks much. Does the rescue target try to mount all the disks? Also, I would still like to get in touch with the dracut devs -- although I may never make that particular mistake again, but maybe other things will happen. As I said in my previous mail: emergency mounts the root filesystem read-only; rescue mounts all the filesystems read/write. If dracut cannot mount the root filesystem, it *WILL* drop you to a shell, but it will take some time while all the timeouts expire. This could be *several* minutes depending on hardware. The dracut mailing list is in [1]. Regards. [1] http://vger.kernel.org/vger-lists.html#initramfs -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 5:32 PM, Canek Peláez Valdés can...@gmail.com wrote: As I said, I did the following tests: 1. Adding emergency to the kernel command line, with a valid root=. 2. Adding rescue to the kernel command line, with a valid root=. 2. Leaving root= invalid without adding neither emergency nor rescue. If root= is valid, with emergency systemd drops you to a shell with your root filesystem mounted read-only. With rescue, systemd drops you to a shell with all your filesystems mounted read-write. If root= is invalid, it doesn't matter if you use emergency, rescue, or neither, *dracut* drops you to a shell, still inside the initramfs obviously. It takes a while; I didn't took the time, but I think it was 3 minutes. Inside this shell, you can use systemd normally, and if you manage to mount the root filesystem, I'm sure you could continue the normal boot process. You'll have to pivot root manually, though. That was basically my understanding of how dracut behaved. I think we're just having a communication gap or something, because you seem to be disagreeing with me when I'm basically trying to describe the behavior you just listed above. -- Rich
Re: [gentoo-user] problems debugging a systemd problem
Canek Peláez Valdés can...@gmail.com wrote: On Thu, May 28, 2015 at 1:36 PM, Rich Freeman ri...@gentoo.org wrote: On Thu, May 28, 2015 at 2:11 PM, Canek Peláez Valdés can...@gmail.com wrote: Actually, it does work (see attached screenshot). I set my root= kernel command line parameter wrong on purpose, and systemd (inside dracut) dropped me inside a rescue shell. Interesting. Perhaps it just enables shell access. There is a separate option that configures whether dracut drops to a shell at all, or if it just hangs on failure. The latter might be desirable for security purposes in some cases. Are you sure that you don't get a shell if you don't pass emergency on the command line, but still have an invalid root=? I wasn't sure, I did a couple of tests more. I comment them below. Usually when somebody wants a rescue shell, they want it in their root filesystem, and not in their initramfs before it has pivoted. That is why dracut has options like rd.break. But that doesn't help you at all when the problem is exactly that you cannot mount your root filesystem. With the rescue shell of systemd (inside dracut), you can analyze the problem, or perhaps even mount your root filesystem and continue the boot process; the initramfs should have all the necessary tools to do that. rd.break DOES give you a shell before root is mounted, if you tell it to. rd.shell tells dracut to give you a shell if something fails rd.break forces a shell at the specified point, whether something fails or not. The official docs do not list emergency as a valid dracut option. Obviously systemd uses it, but again the fact that you had to mangle your root= option sugests that systemd within dracut ignores it if it can mount your root. No, if you set emergency or rescue, systemd will go to emergency.target and rescue.target, respectively. If the problem were with systemd/services/etc in the actual root filesystem (once the actual distro has started booting), then putting emergency on the command line should get you a rescue shell. Again, what if the problem is before *that*? Then you tell dracut to drop to a shell. I wasn't aware that the emergency option actually made a difference, though I'm still not 100% sure that was what did it. I'm now pretty sure it DOESN'T make a difference when the problem is before you can mount root. The same generally applies to openrc - if the initramfs isn't mounting your root filesystem, then passing instructions to openrc won't do anything since in that case openrc isn't even running. But in this case, systemd *is* inside the initramfs: # ls usr/lib/systemd/ network systemd-cgroups-agent systemd-journald systemd-shutdown systemd-vconsole-setup system systemd-fsck systemd-modules-load systemd-sysctl system-generators systemd systemd-hibernate-resume systemd-reply-password systemd-udevd That's my initramfs. With dracut, systemd *is* the initramfs init system. Sure, and that is how mine works as well. But, obviously systemd in dracut is configured to ignore that parameter when root= is valid, No, it doesn't ignore it, even if root= is valid. otherwise you'd get a shell every time. I'd have to check the docs, but I suspect that the behavior is configurable, and systemd within the initramfs is configured differently. If nothing else they could just make the rescue target launch the default target/etc. As I said, I did the following tests: 1. Adding emergency to the kernel command line, with a valid root=. 2. Adding rescue to the kernel command line, with a valid root=. 2. Leaving root= invalid without adding neither emergency nor rescue. If root= is valid, with emergency systemd drops you to a shell with your root filesystem mounted read-only. With rescue, systemd drops you to a shell with all your filesystems mounted read-write. If root= is invalid, it doesn't matter if you use emergency, rescue, or neither, *dracut* drops you to a shell, still inside the initramfs obviously. It takes a while; I didn't took the time, but I think it was 3 minutes. Inside this shell, you can use systemd normally, and if you manage to mount the root filesystem, I'm sure you could continue the normal boot process. You'll have to pivot root manually, though. Hope that makes it clear. How do you pivot route manually? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 5:55 PM, cov...@ccs.covici.com wrote: How do you pivot route manually? With dracut I'm pretty sure that as long as you mount root under /sysroot you can just type exit and it will take care of the rest. I suspect it will even remount it for you if you don't use the same options as it finds in /sysroot/etc/fstab. -- Rich
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 1:36 PM, Rich Freeman ri...@gentoo.org wrote: On Thu, May 28, 2015 at 2:11 PM, Canek Peláez Valdés can...@gmail.com wrote: Actually, it does work (see attached screenshot). I set my root= kernel command line parameter wrong on purpose, and systemd (inside dracut) dropped me inside a rescue shell. Interesting. Perhaps it just enables shell access. There is a separate option that configures whether dracut drops to a shell at all, or if it just hangs on failure. The latter might be desirable for security purposes in some cases. Are you sure that you don't get a shell if you don't pass emergency on the command line, but still have an invalid root=? I wasn't sure, I did a couple of tests more. I comment them below. Usually when somebody wants a rescue shell, they want it in their root filesystem, and not in their initramfs before it has pivoted. That is why dracut has options like rd.break. But that doesn't help you at all when the problem is exactly that you cannot mount your root filesystem. With the rescue shell of systemd (inside dracut), you can analyze the problem, or perhaps even mount your root filesystem and continue the boot process; the initramfs should have all the necessary tools to do that. rd.break DOES give you a shell before root is mounted, if you tell it to. rd.shell tells dracut to give you a shell if something fails rd.break forces a shell at the specified point, whether something fails or not. The official docs do not list emergency as a valid dracut option. Obviously systemd uses it, but again the fact that you had to mangle your root= option sugests that systemd within dracut ignores it if it can mount your root. No, if you set emergency or rescue, systemd will go to emergency.target and rescue.target, respectively. If the problem were with systemd/services/etc in the actual root filesystem (once the actual distro has started booting), then putting emergency on the command line should get you a rescue shell. Again, what if the problem is before *that*? Then you tell dracut to drop to a shell. I wasn't aware that the emergency option actually made a difference, though I'm still not 100% sure that was what did it. I'm now pretty sure it DOESN'T make a difference when the problem is before you can mount root. The same generally applies to openrc - if the initramfs isn't mounting your root filesystem, then passing instructions to openrc won't do anything since in that case openrc isn't even running. But in this case, systemd *is* inside the initramfs: # ls usr/lib/systemd/ network systemd-cgroups-agent systemd-journald systemd-shutdown systemd-vconsole-setup system systemd-fsck systemd-modules-load systemd-sysctl system-generators systemd systemd-hibernate-resume systemd-reply-password systemd-udevd That's my initramfs. With dracut, systemd *is* the initramfs init system. Sure, and that is how mine works as well. But, obviously systemd in dracut is configured to ignore that parameter when root= is valid, No, it doesn't ignore it, even if root= is valid. otherwise you'd get a shell every time. I'd have to check the docs, but I suspect that the behavior is configurable, and systemd within the initramfs is configured differently. If nothing else they could just make the rescue target launch the default target/etc. As I said, I did the following tests: 1. Adding emergency to the kernel command line, with a valid root=. 2. Adding rescue to the kernel command line, with a valid root=. 2. Leaving root= invalid without adding neither emergency nor rescue. If root= is valid, with emergency systemd drops you to a shell with your root filesystem mounted read-only. With rescue, systemd drops you to a shell with all your filesystems mounted read-write. If root= is invalid, it doesn't matter if you use emergency, rescue, or neither, *dracut* drops you to a shell, still inside the initramfs obviously. It takes a while; I didn't took the time, but I think it was 3 minutes. Inside this shell, you can use systemd normally, and if you manage to mount the root filesystem, I'm sure you could continue the normal boot process. You'll have to pivot root manually, though. Hope that makes it clear. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 5:23 PM, Rich Freeman ri...@gentoo.org wrote: On Thu, May 28, 2015 at 5:32 PM, Canek Peláez Valdés can...@gmail.com wrote: As I said, I did the following tests: 1. Adding emergency to the kernel command line, with a valid root=. 2. Adding rescue to the kernel command line, with a valid root=. 2. Leaving root= invalid without adding neither emergency nor rescue. If root= is valid, with emergency systemd drops you to a shell with your root filesystem mounted read-only. With rescue, systemd drops you to a shell with all your filesystems mounted read-write. If root= is invalid, it doesn't matter if you use emergency, rescue, or neither, *dracut* drops you to a shell, still inside the initramfs obviously. It takes a while; I didn't took the time, but I think it was 3 minutes. Inside this shell, you can use systemd normally, and if you manage to mount the root filesystem, I'm sure you could continue the normal boot process. You'll have to pivot root manually, though. That was basically my understanding of how dracut behaved. I think we're just having a communication gap or something, because you seem to be disagreeing with me when I'm basically trying to describe the behavior you just listed above. It's possible; I was wrong about emergency doing anything when root= is invalid, but I did not understood the above behavior from your previous mails. Anyway, if dracut cannot mount the root filesystem, it will drop you into a shell with a functional systemd. Eventually. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 4:55 PM, cov...@ccs.covici.com wrote: Canek Peláez Valdés can...@gmail.com wrote: [...] As I said, I did the following tests: 1. Adding emergency to the kernel command line, with a valid root=. 2. Adding rescue to the kernel command line, with a valid root=. 2. Leaving root= invalid without adding neither emergency nor rescue. If root= is valid, with emergency systemd drops you to a shell with your root filesystem mounted read-only. With rescue, systemd drops you to a shell with all your filesystems mounted read-write. If root= is invalid, it doesn't matter if you use emergency, rescue, or neither, *dracut* drops you to a shell, still inside the initramfs obviously. It takes a while; I didn't took the time, but I think it was 3 minutes. Inside this shell, you can use systemd normally, and if you manage to mount the root filesystem, I'm sure you could continue the normal boot process. You'll have to pivot root manually, though. Hope that makes it clear. How do you pivot route manually? Basically, with pivot_root(8) [1]. Be aware that systemd does some things before and after pivot_root'ing; in particular, it switches from the instance running inside the initramfs to an instance running in the real filesystem. I'm not sure how it does it, but the switching code is relatively simple [2]. Regards. [1] http://linux.die.net/man/8/pivot_root [2] http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/switch-root.c -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 2:11 PM, Canek Peláez Valdés can...@gmail.com wrote: Actually, it does work (see attached screenshot). I set my root= kernel command line parameter wrong on purpose, and systemd (inside dracut) dropped me inside a rescue shell. Interesting. Perhaps it just enables shell access. There is a separate option that configures whether dracut drops to a shell at all, or if it just hangs on failure. The latter might be desirable for security purposes in some cases. Are you sure that you don't get a shell if you don't pass emergency on the command line, but still have an invalid root=? Usually when somebody wants a rescue shell, they want it in their root filesystem, and not in their initramfs before it has pivoted. That is why dracut has options like rd.break. But that doesn't help you at all when the problem is exactly that you cannot mount your root filesystem. With the rescue shell of systemd (inside dracut), you can analyze the problem, or perhaps even mount your root filesystem and continue the boot process; the initramfs should have all the necessary tools to do that. rd.break DOES give you a shell before root is mounted, if you tell it to. rd.shell tells dracut to give you a shell if something fails rd.break forces a shell at the specified point, whether something fails or not. The official docs do not list emergency as a valid dracut option. Obviously systemd uses it, but again the fact that you had to mangle your root= option sugests that systemd within dracut ignores it if it can mount your root. If the problem were with systemd/services/etc in the actual root filesystem (once the actual distro has started booting), then putting emergency on the command line should get you a rescue shell. Again, what if the problem is before *that*? Then you tell dracut to drop to a shell. I wasn't aware that the emergency option actually made a difference, though I'm still not 100% sure that was what did it. The same generally applies to openrc - if the initramfs isn't mounting your root filesystem, then passing instructions to openrc won't do anything since in that case openrc isn't even running. But in this case, systemd *is* inside the initramfs: # ls usr/lib/systemd/ network systemd-cgroups-agent systemd-journaldsystemd-shutdown systemd-vconsole-setup system systemd-fsck systemd-modules-loadsystemd-sysctl system-generators systemd systemd-hibernate-resume systemd-reply-password systemd-udevd That's my initramfs. With dracut, systemd *is* the initramfs init system. Sure, and that is how mine works as well. But, obviously systemd in dracut is configured to ignore that parameter when root= is valid, otherwise you'd get a shell every time. I'd have to check the docs, but I suspect that the behavior is configurable, and systemd within the initramfs is configured differently. If nothing else they could just make the rescue target launch the default target/etc. -- Rich
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 11:57 AM, Canek Peláez Valdés can...@gmail.com wrote: Others have already answered, but I will add that if you put emergency anywhere in the kernel command line, then systemd will boot to the rescue target; that's why I suggested to do it in my first answer. I'm pretty sure that won't work for an initramfs - they're almost certainly designed to ignore that instruction. Usually when somebody wants a rescue shell, they want it in their root filesystem, and not in their initramfs before it has pivoted. That is why dracut has options like rd.break. If the problem were with systemd/services/etc in the actual root filesystem (once the actual distro has started booting), then putting emergency on the command line should get you a rescue shell. The same generally applies to openrc - if the initramfs isn't mounting your root filesystem, then passing instructions to openrc won't do anything since in that case openrc isn't even running. -- Rich
Re: [gentoo-user] problems debugging a systemd problem
Canek Peláez Valdés can...@gmail.com wrote: On Thu, May 28, 2015 at 3:30 AM, cov...@ccs.covici.com wrote: Stefan G. Weichinger li...@xunil.at wrote: On 28.05.2015 09:39, cov...@ccs.covici.com wrote: No, the journal is gone, it was only in /run which is on a tmpfs file system. I can boot from a cd all day long, but it would not help one bit. Hm, I think it could help for sure as you could chroot in and do something. For example build a new kernel or initrd or ... You removed openrc? Otherwise boot via openrc and (try to) fix stuff. You could even reinstall openrc from within chroot ... just to get bootin again etc etc I still have openrc, but Dracut won't work with it, at least maybe because I have systemd use flag enabled. Also, in retrospect, that would not have solved my specific problems, because it was related to an rd.lv command which is specific to dracut. But thanks for your suggestion. I wonder what the rescue target is -- I have never seen that before -- maybe I could configure it so I could boot into a shell and fix things and it would be sort of like a little system of its own. Others have already answered, but I will add that if you put emergency anywhere in the kernel command line, then systemd will boot to the rescue target; that's why I suggested to do it in my first answer. Also, as Rich said, if you wait it's possible that systemd (and/or dracut) will drop you into a rescue shell anyway. Unfortunately, thanks to very slow hardware in the wild, the timeout has been increased to three minutes, and I believe those are *per hardware unit*. So if you have five disks, in theory it could take fifteen minutes to get you to a rescue shell. Thanks much. Does the rescue target try to mount all the disks? Also, I would still like to get in touch with the dracut devs -- although I may never make that particular mistake again, but maybe other things will happen. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Re: plugin-containers missing libraries
On Thursday, May 28, 2015 6:01:22 PM Adam Carter wrote: How do you tell that the library is loaded by firefox? Load a page with a plugin then run htop, you may see a few plugin-container child processes for firefox, note it's pid and then run (as root): cat /proc/pid/maps | grep libxul.so You'll see something like this: 7ff264f9b000-7ff269e4b000 r-xp 08:06 8736977 /usr/lib64/firefox/libxul.so 7ff269e4b000-7ff26a04a000 ---p 04eb 08:06 8736977 /usr/lib64/firefox/libxul.so 7ff26a04a000-7ff26a4ef000 r--p 04eaf000 08:06 8736977 /usr/lib64/firefox/libxul.so 7ff26a4ef000-7ff26a56e000 rw-p 05354000 08:06 8736977 /usr/lib64/firefox/libxul.so f How would it know to load libraries for other binaries? When firefox starts the plugin-container process it may just set the LD_LIBRARY_PATH environment variable for it, just like the script from the binary packages do, or it may do something more complicated. You'll have to look at the code to find out. -- Fernando Rodriguez signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Unwelcomed non-native language support
On Thu, May 28, 2015 at 6:41 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 28.05.2015 um 17:35 schrieb gevisz: In my everyday work at the computer, I read and type at three or even four different languages. However, I do want to have all program menues and system messages only in English. So, when I found out that it can be achieved by setting -nls USE flag at my make.conf file, I did it, recompiled the system and for a few weeks enjoyed the full control of my Gentoo system. (As far as I can remember the gettext package was successfully depcleaned from my Gentoo system just after that.) However, after those few weeks (and some system updates), I have noticed that my system started to translate some system messages into one of the languages I use but which is not my native language. Moreover, running $ equery depends gettext I get about two fullscreens of packages that supposedly depend on gettext. Nevertheless, in all of them the -nls USE flag is either unset or absent. I have tried to depclean the gettext package from my system once again but portage just ignored my $ emerge --depclean gettext command. I think that it is some kind of a bug in the portage tree: when I set -nls USE flag globally, I do expect that the system messages will appear in English only and will not be translated in any other language, but the system understands that as I would have asked for a non-native language support. Of course, this is not my main problem in this life, but every time I get the system messages translated into my non-native language, I feel as I get a reminder that I do not have a full control of my Gentoo system. So, my questions are: 1. Is it a bug? 2. How can I get rid of those unwelcomed translations in the right way. 1. if a package hard depends on gettext, you can fiddle around with useflags as much as you want, it won't change. Not a bug. Just the way it is. Sometimes it is a bug and the ebuild doesn't need gettext unconditionally. It takes some expertise to figure that out, however. 2. environment variables. Set them. LANG, LANGUAGE and of course LC_ALL I would suggest setting LANG=foo_BAR.UTF-8 and LC_MESSAGES=en_US.UTF-8. Where foo and BAR are your native language and locale.
Re: [gentoo-user] General weirdness - a tale of woe.
On Thu, May 28, 2015 at 1:03 PM, Peter Humphrey pe...@prh.myzen.co.uk wrote: On Thursday 28 May 2015 15:36:04 I wrote: On Thursday 28 May 2015 08:44:27 Rich Freeman wrote: With an approach like yours, mdadm will attempt to create md1 by looking ONLY at sda1 and sdb1, and if that pair forms a valid array it is started, and if not it is not. If you add a new drive to your system or for whatever reason the kernel/udev rules change a little or some race condition changes a little then your devices might get different names, and the array will not be assembled. Hmm. I wonder if that's what's happening to me. Perhaps I'd better adopt UUIDs then, once I work out what mine are. Thanks for the advice. I've found blkid, which tells me the UUIDs of my various devices, thus: # blkid /dev/md7 /dev/md7: UUID=ycGMf9-hEP2-tjT4-AtkJ-n8RI-pZ44-RqvlEY TYPE=LVM2_member Just keep in mind that the UUID that goes into mdadm.conf might not be the same UUID returned by blkid. I'm honestly not certain either way. You can get the mdadm ID from mdadm --detail --scan. Two odd things: 1. /dev/md7 is the physical volume in which logical volumes are defined, so I'm surprised to see TYPE=LVM2_member. I'm pretty sure this is fine. It recognizes it as an LVM pv, so that makes it an LVM2 member. 2. There is no entry corresponding to /dev/md7 under /dev/disk/by-uuid, though /dev/md1 and /dev/md5 do have entries there [1]. udev may be configured to not create uuid symlinks for LVM pvs (since you wouldn't directly mount them anyway). The others contain filesystems and do get symlinks. What should I be doing about this? I'd probably just edit your mdadm.conf to be more liberal with scanning, and add the arrays output by mdadm --detail --scan to your config file. That alone may make your problems go away, and it should be pretty harmless. I assume that the ../../dm-N links refer to the LVs - there are 15 of them. md7 is conspicuous by its absence. This seems like a problem to me, and it may account for /dev/md7 sometimes not being started at boot time. LVM is just a wrapper around DM, so that is normal. Nothing about what you've written here concerns me. -- Rich
Re: [gentoo-user] problems debugging a systemd problem
Canek Peláez Valdés can...@gmail.com wrote: On Thu, May 28, 2015 at 2:11 PM, cov...@ccs.covici.com wrote: Also, as Rich said, if you wait it's possible that systemd (and/or dracut) will drop you into a rescue shell anyway. Unfortunately, thanks to very slow hardware in the wild, the timeout has been increased to three minutes, and I believe those are *per hardware unit*. So if you have five disks, in theory it could take fifteen minutes to get you to a rescue shell. Thanks much. Does the rescue target try to mount all the disks? Also, I would still like to get in touch with the dracut devs -- although I may never make that particular mistake again, but maybe other things will happen. As I said in my previous mail: emergency mounts the root filesystem read-only; rescue mounts all the filesystems read/write. If dracut cannot mount the root filesystem, it *WILL* drop you to a shell, but it will take some time while all the timeouts expire. This could be *several* minutes depending on hardware. The dracut mailing list is in [1]. Regards. OK, thanks much. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] General weirdness - a tale of woe.
On Thursday 28 May 2015 19:51:24 Rich Freeman wrote: On Thu, May 28, 2015 at 1:03 PM, Peter Humphrey pe...@prh.myzen.co.uk wrote: I've found blkid, which tells me the UUIDs of my various devices, thus: # blkid /dev/md7 /dev/md7: UUID=ycGMf9-hEP2-tjT4-AtkJ-n8RI-pZ44-RqvlEY TYPE=LVM2_member Just keep in mind that the UUID that goes into mdadm.conf might not be the same UUID returned by blkid. I'm honestly not certain either way. You can get the mdadm ID from mdadm --detail --scan. Good grief! When is a UUID not a UUID? Or, how can one device have more than one UUID? Two odd things: 1. /dev/md7 is the physical volume in which logical volumes are defined, so I'm surprised to see TYPE=LVM2_member. I'm pretty sure this is fine. It recognizes it as an LVM pv, so that makes it an LVM2 member. If you say so. It still smells a bit to me. 2. There is no entry corresponding to /dev/md7 under /dev/disk/by-uuid, though /dev/md1 and /dev/md5 do have entries there [1]. udev may be configured to not create uuid symlinks for LVM pvs (since you wouldn't directly mount them anyway). The others contain filesystems and do get symlinks. What should I be doing about this? I'd probably just edit your mdadm.conf to be more liberal with scanning, and add the arrays output by mdadm --detail --scan to your config file. That alone may make your problems go away, and it should be pretty harmless. OK, so this is what I have at present. I haven't booted with it yet to test it - I'll do that in the morning: DEVICE /dev/sd[abcde][123456789] ARRAY /dev/md1 UUID=ea156c7f:183ca28e:c44c77eb:7ee19756 ARRAY /dev/md5 UUID=e7640378:966a5b3a:c44c77eb:7ee19756 ARRAY /dev/md7 UUID=c2d056c4:9118021f:ad73c633:b38fa97c Nothing about what you've written here concerns me. Well, let us be thankful for small mercies :-) -- Rgds Peter
Re: [gentoo-user] Unwelcomed non-native language support
On Fri, 29 May 2015 00:41:08 +0200 Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 28.05.2015 um 17:35 schrieb gevisz: In my everyday work at the computer, I read and type at three or even four different languages. However, I do want to have all program menues and system messages only in English. So, when I found out that it can be achieved by setting -nls USE flag at my make.conf file, I did it, recompiled the system and for a few weeks enjoyed the full control of my Gentoo system. (As far as I can remember the gettext package was successfully depcleaned from my Gentoo system just after that.) However, after those few weeks (and some system updates), I have noticed that my system started to translate some system messages into one of the languages I use but which is not my native language. Moreover, running $ equery depends gettext I get about two fullscreens of packages that supposedly depend on gettext. Nevertheless, in all of them the -nls USE flag is either unset or absent. I have tried to depclean the gettext package from my system once again but portage just ignored my $ emerge --depclean gettext command. I think that it is some kind of a bug in the portage tree: when I set -nls USE flag globally, I do expect that the system messages will appear in English only and will not be translated in any other language, but the system understands that as I would have asked for a non-native language support. Of course, this is not my main problem in this life, but every time I get the system messages translated into my non-native language, I feel as I get a reminder that I do not have a full control of my Gentoo system. So, my questions are: 1. Is it a bug? 2. How can I get rid of those unwelcomed translations in the right way. 1. If a package hard depends on gettext, you can fiddle around with useflags as much as you want, it won't change. Not a bug. Just the way it is. If a package hard depend on gettext, it is a bug, IMHO. 2. Environment variables. Set them. LANG, LANGUAGE and of course LC_ALL $ echo $LANG en_US.UTF-8 $ echo $LANGUAGE %%% This environment variable is not set $ echo $LC_ALL %%% This environment variable is not set Why the system suddenly decided that my native language is one of the easten-europien ones, then? And a month or two ago, all the system messages was in English with exactly the same evironment variables setting. (And packages did not hard-depend on gettext.) Strange.
Re: [gentoo-user] Unwelcomed non-native language support
On Thu, 28 May 2015 20:07:55 -0400 Mike Gilbert flop...@gentoo.org wrote: On Thu, May 28, 2015 at 6:41 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 28.05.2015 um 17:35 schrieb gevisz: In my everyday work at the computer, I read and type at three or even four different languages. However, I do want to have all program menues and system messages only in English. So, when I found out that it can be achieved by setting -nls USE flag at my make.conf file, I did it, recompiled the system and for a few weeks enjoyed the full control of my Gentoo system. (As far as I can remember the gettext package was successfully depcleaned from my Gentoo system just after that.) However, after those few weeks (and some system updates), I have noticed that my system started to translate some system messages into one of the languages I use but which is not my native language. Moreover, running $ equery depends gettext I get about two fullscreens of packages that supposedly depend on gettext. Nevertheless, in all of them the -nls USE flag is either unset or absent. I have tried to depclean the gettext package from my system once again but portage just ignored my $ emerge --depclean gettext command. I think that it is some kind of a bug in the portage tree: when I set -nls USE flag globally, I do expect that the system messages will appear in English only and will not be translated in any other language, but the system understands that as I would have asked for a non-native language support. Of course, this is not my main problem in this life, but every time I get the system messages translated into my non-native language, I feel as I get a reminder that I do not have a full control of my Gentoo system. So, my questions are: 1. Is it a bug? 2. How can I get rid of those unwelcomed translations in the right way. 1. if a package hard depends on gettext, you can fiddle around with useflags as much as you want, it won't change. Not a bug. Just the way it is. Sometimes it is a bug and the ebuild doesn't need gettext unconditionally. It takes some expertise to figure that out, however. I also think so. 2. environment variables. Set them. LANG, LANGUAGE and of course LC_ALL I would suggest setting LANG=foo_BAR.UTF-8 and LC_MESSAGES=en_US.UTF-8. Where foo and BAR are your native language and locale. I have # set LC_MESSAGES=en_US.UTF-8 but it have not changed anything. Or shall I change it in some config files and reboot the system?
Re: [gentoo-user] problems debugging a systemd problem
Am 2015-05-28 um 08:15 schrieb cov...@ccs.covici.com: Thanks for your quick reply, but I do have rd.shell=1, but it did not drop to a shell,it just hung, so I could not do journalctl or anything -- the nearest break point was pre-initqueue which was maybe too early and the next one is pre-mount which it never got to. Unfortunately, I was in a position where I could not use an older kernel, because the older ones didn't have the configs to read gui type partitions-- I always keep several kernels around normally, but this was one of those transitional times when I was stuck. So do I need emergency aswell as rd.shell andis there any way to get a shell when the system appearsto be in some kind of a loop, like calling setl over andover again? http://freedesktop.org/wiki/Software/systemd/Debugging/ ? Do you try to boot into rescue.target? Why not use a live-cd, boot, mount, chroot and get on there? You can read the journal of your failing installation via the journalctl-binary of your booted live-system (I assume fedora live-media boots with systemd ... dunno ad hoc which one to use)
Re: [gentoo-user] Blocking certain sites the easy way ?
On Thu, 28 May 2015 06:36:35 +0100, Mick wrote: It may none of the above, but FF and any addons checking what the latest version is of themselves, as well as the Google search on the default hope page doing a DNS query or some such. I thought all Google search pages were based on hope? ;-) SCNR! -- Neil Bothwick Suicide is the most sincere form of self-criticism. pgpO3S4_A57_B.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: plugin-containers missing libraries
On Thu, 28 May 2015 18:02:24 +1000, Adam Carter wrote: It might help if you said which firefox and thunderbird packages you have installed. The non -bin ones (is that what you were asking?) Exactly, all the confusion over whether the firefox executable is a script or not come down to this, as does the location of libraries as they are bundled with the -bin package. -- Neil Bothwick Capt'n! The spellchecker kinna take this abuse! pgplfKnpl8sRz.pgp Description: OpenPGP digital signature
Re: [gentoo-user] problems debugging a systemd problem
Stefan G. Weichinger li...@xunil.at wrote: Am 2015-05-28 um 08:15 schrieb cov...@ccs.covici.com: Thanks for your quick reply, but I do have rd.shell=1, but it did not drop to a shell,it just hung, so I could not do journalctl or anything -- the nearest break point was pre-initqueue which was maybe too early and the next one is pre-mount which it never got to. Unfortunately, I was in a position where I could not use an older kernel, because the older ones didn't have the configs to read gui type partitions-- I always keep several kernels around normally, but this was one of those transitional times when I was stuck. So do I need emergency aswell as rd.shell andis there any way to get a shell when the system appearsto be in some kind of a loop, like calling setl over andover again? http://freedesktop.org/wiki/Software/systemd/Debugging/ ? Do you try to boot into rescue.target? Why not use a live-cd, boot, mount, chroot and get on there? You can read the journal of your failing installation via the journalctl-binary of your booted live-system (I assume fedora live-media boots with systemd ... dunno ad hoc which one to use) No, the journal is gone, it was only in /run which is on a tmpfs file system. I can boot from a cd all day long, but it would not help one bit. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] problems debugging a systemd problem
On 28.05.2015 09:39, cov...@ccs.covici.com wrote: No, the journal is gone, it was only in /run which is on a tmpfs file system. I can boot from a cd all day long, but it would not help one bit. Hm, I think it could help for sure as you could chroot in and do something. For example build a new kernel or initrd or ... You removed openrc? Otherwise boot via openrc and (try to) fix stuff. You could even reinstall openrc from within chroot ... just to get bootin again etc etc
Re: [gentoo-user] Re: plugin-containers missing libraries
There's no firefox-bin in /usr/bin on my system, there's just # ls -l /usr/bin/firefox* lrwxrwxrwx 1 root root 26 May 9 19:13 /usr/bin/firefox - /usr/lib64/firefox/firefox And in that directory, again no shell script; # file /usr/lib64/firefox/firefox-bin /usr/lib64/firefox/firefox-bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, stripped System is ~amd64 for firefox/thunderbird I'm also using ~amd64 firefox (37.0.2) and mine is also a binary. Anyways, what this means is that the library is not loaded by the loader but by firefox at runtime so it's nothing to worry about. I guess some versions or build use a script to preload the library. How do you tell that the library is loaded by firefox? How would it know to load libraries for other binaries?
Re: [gentoo-user] problems debugging a systemd problem
Stefan G. Weichinger li...@xunil.at wrote: On 28.05.2015 09:39, cov...@ccs.covici.com wrote: No, the journal is gone, it was only in /run which is on a tmpfs file system. I can boot from a cd all day long, but it would not help one bit. Hm, I think it could help for sure as you could chroot in and do something. For example build a new kernel or initrd or ... You removed openrc? Otherwise boot via openrc and (try to) fix stuff. You could even reinstall openrc from within chroot ... just to get bootin again etc etc I still have openrc, but Dracut won't work with it, at least maybe because I have systemd use flag enabled. Also, in retrospect, that would not have solved my specific problems, because it was related to an rd.lv command which is specific to dracut. But thanks for your suggestion. I wonder what the rescue target is -- I have never seen that before -- maybe I could configure it so I could boot into a shell and fix things and it would be sort of like a little system of its own. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Re: plugin-containers missing libraries
There's no firefox-bin in /usr/bin on my system, there's just # ls -l /usr/bin/firefox* lrwxrwxrwx 1 root root 26 May 9 19:13 /usr/bin/firefox - /usr/lib64/firefox/firefox And in that directory, again no shell script; # file /usr/lib64/firefox/firefox-bin /usr/lib64/firefox/firefox-bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, stripped System is ~amd64 for firefox/thunderbird It might help if you said which firefox and thunderbird packages you have installed. The non -bin ones (is that what you were asking?)
Re: [gentoo-user] Blocking certain sites the easy way ?
On Thursday, May 28, 2015 7:11:08 AM meino.cra...@gmx.de wrote: Hi, With wireshark I found, that firefox accesses sites on startup, from which I dont know, for what reason this access is needed or whether the NSA, CIA, FBI, BDN, MOSSAD (fill in what organisation you ever suspect to do such things) has invaded my PC. I want to block such accesses for two reasons: First is ...hmmm... to block that accesses... For an easy way to block sites based on domain name just add them to /etc/hosts and map them to 127.0.0.1. second is to find out what will not work than. It depends on what it is, mostlikely something you want. It may be firefox downloading the database of blacklisted sites for the Block reported attack sites and Block reported web forgeries features so those thing will not work properly. It could also be an ad block or some other plugin downloading the ads database. It could be downloading or verifying SSL certificates. It could be the Bookmark sync feature, etc, etc. -- Fernando Rodriguez
Re: [gentoo-user] problems debugging a systemd problem
Canek Peláez Valdés can...@gmail.com wrote: On Thu, May 28, 2015 at 12:09 AM, cov...@ccs.covici.com wrote: Hi folks. I spent a very frustrating time last night trying to figure out why my systemd would not boot using systemd. I am using dracut and its version is 041r2. Now what was happening is that the system would get to the pre-init-queue -- and I even set the rd.break there, but after that the system would not boot -- when I used debug it endlessly said calling setl forever. Now it turned out that the problem was that I had mistyped an rd.lv= line -- instead of ssd-files/usr I had ssd-files/-usr . Now, what I would like to know is how could I tell that it was trying to look for a non-existent lv? At the point of the break. no lvm volumes were active, although strangely enough I saw a e2fsck for the real root file system which was an lvm volume. I am finding its generally hard to debug systemd problems, several other times the system just sat there till I figured it out some other way. Any observations on this would be appreciated, but I don't want to get into a flame war, I just want to minimize the down time. Usually if you can get an emergency shell by adding emergency to the kernel command line (both GRUB and Gummiboot allow you to edit the kernel command line), then is easy to see what the problem is. My experience with LVM has been consistently pretty awful, which is why I don't use in any of my machines, but I suppose a systemctl --all --full will tell you what unit files have failed, and then you can journalctl -b -u them. Also journalctl -b by itself would tell you many times what the problem is. The only problem with the emergency shell is that sometimes is too early in the boot process for the keyboard drivers to have been loaded, but that is easily solved by adding a drivers+= line to a conf file in /etc/dracut.conf.d. Also, and I cannot stress this enough, you never delete your old (and working) kernel+initramfs until you have tested the new one. I would also recommend to leave the entries for the old kernel+initramfs in the GRUB/Gummiboot menu, but you can manage without them. Finally, and this is tooting my own horn, maybe you could try kerninst[1]? It's a little script I started a couple of years ago to automatically compile and install my kernels and generate my initramfs'. I use it in all my machines, and now my kernel update is just a matter of eselecting the new version, and running kerninst. I follow ~amd64 vanilla-sources, so this is roughly every week or two. Beware, though, that I don't use LVM nor RAID nor Luks, but in theory if you have a working kernel+dracut+[grub|gummitboot] configuration, it should also work with them. Thanks for your quick reply, but I do have rd.shell=1, but it did not drop to a shell,it just hung, so I could not do journalctl or anything -- the nearest break point was pre-initqueue which was maybe too early and the next one is pre-mount which it never got to. Unfortunately, I was in a position where I could not use an older kernel, because the older ones didn't have the configs to read gui type partitions-- I always keep several kernels around normally, but this was one of those transitional times when I was stuck. So do I need emergency aswell as rd.shell andis there any way to get a shell when the system appearsto be in some kind of a loop, like calling setl over andover again? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Blocking certain sites the easy way ?
Mick michaelkintz...@gmail.com [15-05-28 07:44]: On Thursday 28 May 2015 06:11:08 meino.cra...@gmx.de wrote: Hi, With wireshark I found, that firefox accesses sites on startup, from which I dont know, for what reason this access is needed or whether the NSA, CIA, FBI, BDN, MOSSAD (fill in what organisation you ever suspect to do such things) has invaded my PC. It may none of the above, but FF and any addons checking what the latest version is of themselves, as well as the Google search on the default hope page doing a DNS query or some such. I want to block such accesses for two reasons: First is ...hmmm... to block that accesses...second is to find out what will not work than. I dont want to install and configure a complete full blown firewalled SEL-Linux thingy here and I dont want to reboot my Linux box for every new site I added. I am looking for a simple solution, which I can use without studying the history of TCP/IP and others... ;))) What can I use for this purpose? You could try an application layer filter[1], but I think it won't work insofar the connections you observed are probably using ports and protocols same as your day to day browsing activity. Therefore you will likely need to use iptables to block individual domains or IP addresses and then regularly add to the list when the servers your browser wants to contact change in that amorphous and reconfiguring cloud out there. You don't have to reboot your box when you change rules, but you'll need to reload iptables. [1] http://l7-filter.sourceforge.net/HOWTO-kernel -- Regards, Mick Hi Mick, thanks for your help ! :) What mechanism is recommended to be used to reinstall/initiate the iptable rules while booting? Any Gentoo-ish? ;) Best regard, Meino
Re: [gentoo-user] problems debugging a systemd problem
On 28.05.2015 10:30, cov...@ccs.covici.com wrote: I still have openrc, but Dracut won't work with it, at least maybe because I have systemd use flag enabled. Also, in retrospect, that would not have solved my specific problems, because it was related to an rd.lv command which is specific to dracut. You could rebuild the initrd from live-cd maybe But thanks for your suggestion. I wonder what the rescue target is -- I have never seen that before -- maybe I could configure it so I could boot into a shell and fix things and it would be sort of like a little system of its own. It's a target of systemd, kind of a runlevel. see http://freedesktop.org/wiki/Software/systemd/Debugging/#index1h1 quote: To boot directly into rescue target add systemd.unit=rescue.target or just 1 to the kernel command line.
Re: [gentoo-user] problems debugging a systemd problem
Stefan G. Weichinger li...@xunil.at wrote: On 28.05.2015 10:30, cov...@ccs.covici.com wrote: I still have openrc, but Dracut won't work with it, at least maybe because I have systemd use flag enabled. Also, in retrospect, that would not have solved my specific problems, because it was related to an rd.lv command which is specific to dracut. You could rebuild the initrd from live-cd maybe But thanks for your suggestion. I wonder what the rescue target is -- I have never seen that before -- maybe I could configure it so I could boot into a shell and fix things and it would be sort of like a little system of its own. It's a target of systemd, kind of a runlevel. see http://freedesktop.org/wiki/Software/systemd/Debugging/#index1h1 quote: To boot directly into rescue target add systemd.unit=rescue.target or just 1 to the kernel command line. OK, thanks, I will definitely check that one out. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 2:15 AM, cov...@ccs.covici.com wrote: Thanks for your quick reply, but I do have rd.shell=1, but it did not drop to a shell,it just hung, so I could not do journalctl or anything -- the nearest break point was pre-initqueue which was maybe too early and the next one is pre-mount which it never got to. It could very well be a dracut bug (consider bringing the issue to them), but how long did you wait while it was looping. I've seen cases where dracut looped for a few minutes before dropping to a shell. There are a few loops where dracut is waiting for udev to detect all devices, and if it is looking for a device that will never appear, then it will potentially loop forever. There should be a timeout, but I don't know what it is set to by default. Once you get a shell you should be able to inspect the journal/dmesg/etc and try to see what is going on. Sure, you could have booted a rescue CD, but I don't see what it would have gained you as far as troubleshooting the problem with your initramfs (though it would have allowed you to rebuild it if the initramfs itself was broken, or try out a different version/etc). As you point out any logs it creates are stored in tmpfs or ramfs - that is true of just about any initramfs since it won't have any place to store them until it mounts root. I don't know if setting the rescue target would have helped. I think that the behavior of that option is to still boot to your root filesystem and THEN drop to a shell. If you want to force a rescue shell within the initramfs you need to use rd.break or such, and as you point out you need to find the right breakpoint for this. I'd suggest talking to the dracut devs about how it should have behaved in those circumstances. At the very least they might be able to improve the error reporting. -- Rich
Re: [gentoo-user] General weirdness - a tale of woe.
On Wed, May 27, 2015 at 8:01 PM, Peter Humphrey pe...@prh.myzen.co.uk wrote: My mdadm.conf is now this: DEVICE /dev/sd[ab]1 DEVICE /dev/sd[ab]5 DEVICE /dev/sd[ab]7 ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1 ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5 ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7 I'll see how that goes; so far no complaints about finding no arrays in the config file. I've never used UUIDs, preferring to be able to read what I'm specifying. The problem with this sort of approach is that you're hard-coding device names. If for whatever reason your devices are lettered differently, mdadm may not assemble the array. Here is an example of one of my old mdadm.conf files: DEVICE /dev/sd[abcdefgh][12345] /dev/hd[abcde][12345] #ARRAY /dev/md126 UUID=e424848a:593e3c8e:0e120ac2:958f662e #ARRAY /dev/md124 UUID=dae2458d:e144dbde:34d5107b:2f8c859e #ARRAY /dev/md127 UUID=4096c546:a0d9d5c4:5063dd02:38d16c75 This tells mdadm to scan all those permutations of device names, find anything with those UUIDs and attempt to assemble the arrays, giving them the preferred minor numbers. Some of those device names probably don't even exist (not all of those drives have 5 partitions, etc). It doesn't matter - mdadm just checks the ones that do exist. Then if for whatever reason sdd is now hdc it doesn't matter. With an approach like yours, mdadm will attempt to create md1 by looking ONLY at sda1 and sdb1, and if that pair forms a valid array it is started, and if not it is not. If you add a new drive to your system or for whatever reason the kernel/udev rules change a little or some race condition changes a little then your devices might get different names, and the array will not be assembled. UUIDs are often preferable in these kinds of configurations, because you're less likely to run into duplicate identifiers, they don't change, and so on. If I mount root=UUID=foo, then my initramfs will try really hard to find that partition and mount it. If I mount root=label=foo then it will still try hard, but if for some reason I have more than one device with that label I could end up booting from the wrong one. If I mount root=/dev/sda1 then my boot may fail if I add a new drive, if the kernel behavior changes, if the udev behavior changes, and so on. I don't believe either the kernel or udev makes promises about device names being stable. It often works out this way, but it isn't ideal to depend on this. -- Rich
[gentoo-user] opensmtpd-5.4.5.201505241924_p1 not working
Hello. After updating to mail-mta/opensmtpd-5.4.5.201505241924_p1 and installing mail-mta/opensmtpd-extras-5.4.5.201505202252 I cannot get opensmtp working. # smtpd -vd fatal: table_create: backend db does not exist In /etc/opensmtpd/smtpd.conf I have the lines: table aliases file:/etc/opensmtpd/aliases table secrets db:/etc/opensmtpd/secrets.db It was working before the update. How can I fix this issue? Is it a bug in the new release of the package? Regards, Romildo
Re: [gentoo-user] General weirdness - a tale of woe.
* Rich Freeman ri...@gentoo.org [150528 08:45]: On Wed, May 27, 2015 at 8:01 PM, Peter Humphrey pe...@prh.myzen.co.uk wrote: [..SNIP..] UUIDs are often preferable in these kinds of configurations, because you're less likely to run into duplicate identifiers, they don't change, and so on. If I mount root=UUID=foo, then my initramfs will try really hard to find that partition and mount it. If I mount root=label=foo then it will still try hard, but if for some reason I have more than one device with that label I could end up booting from the wrong one. If I mount root=/dev/sda1 then my boot may fail if I add a new drive, if the kernel behavior changes, if the udev behavior changes, and so on. I don't believe either the kernel or udev makes promises about device names being stable. It often works out this way, but it isn't ideal to depend on this. -- Rich It's worse than just getting the wrong filesystem mounted if the wrong filesystem gets mounted as /tmp. OpenRC's bootmisc will wipe the /tmp directory at boot (and likely systemd as well, but I haven't checked.) This means if disk device names get shifted and something other than the proper /tmp device gets mounted as /tmp then it's restore-from-backups time. This happened to me and wiped /home (the /dev/md* devices got renumbered once.) So I've switched to UUID mounts so that problem doesn't happen in the future. It's really unpleasant if that happens. Todd
Re: [gentoo-user] General weirdness - a tale of woe.
On Thursday 28 May 2015 08:44:27 Rich Freeman wrote: On Wed, May 27, 2015 at 8:01 PM, Peter Humphrey pe...@prh.myzen.co.uk wrote: My mdadm.conf is now this: DEVICE /dev/sd[ab]1 DEVICE /dev/sd[ab]5 DEVICE /dev/sd[ab]7 ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1 ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5 ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7 I'll see how that goes; so far no complaints about finding no arrays in the config file. I've never used UUIDs, preferring to be able to read what I'm specifying. The problem with this sort of approach is that you're hard-coding device names. If for whatever reason your devices are lettered differently, mdadm may not assemble the array. Here is an example of one of my old mdadm.conf files: DEVICE /dev/sd[abcdefgh][12345] /dev/hd[abcde][12345] #ARRAY /dev/md126 UUID=e424848a:593e3c8e:0e120ac2:958f662e #ARRAY /dev/md124 UUID=dae2458d:e144dbde:34d5107b:2f8c859e #ARRAY /dev/md127 UUID=4096c546:a0d9d5c4:5063dd02:38d16c75 This tells mdadm to scan all those permutations of device names, find anything with those UUIDs and attempt to assemble the arrays, giving them the preferred minor numbers. Some of those device names probably don't even exist (not all of those drives have 5 partitions, etc). It doesn't matter - mdadm just checks the ones that do exist. Then if for whatever reason sdd is now hdc it doesn't matter. With an approach like yours, mdadm will attempt to create md1 by looking ONLY at sda1 and sdb1, and if that pair forms a valid array it is started, and if not it is not. If you add a new drive to your system or for whatever reason the kernel/udev rules change a little or some race condition changes a little then your devices might get different names, and the array will not be assembled. Hmm. I wonder if that's what's happening to me. Perhaps I'd better adopt UUIDs then, once I work out what mine are. Thanks for the advice. -- Rgds Peter
Re: [gentoo-user] Blocking certain sites the easy way ?
meino.cra...@gmx.de wrote: Hi, With wireshark I found, that firefox accesses sites on startup, from which I dont know, for what reason this access is needed or whether the NSA, CIA, FBI, BDN, MOSSAD (fill in what organisation you ever suspect to do such things) has invaded my PC. I want to block such accesses for two reasons: First is ...hmmm... to block that accesses...second is to find out what will not work than. I dont want to install and configure a complete full blown firewalled SEL-Linux thingy here and I dont want to reboot my Linux box for every new site I added. I am looking for a simple solution, which I can use without studying the history of TCP/IP and others... ;))) What can I use for this purpose? Thank you very much in advance for any help! Best regards, Meino Maybe net-firewall/ufw is what you are looking for. It has easy to define filter rules and there also exists a graphical frontend for it (net-firewall/ufw-frontends, never tested by myself). -- Regards wabe
Re: [gentoo-user] problems debugging a systemd problem
Rich Freeman ri...@gentoo.org wrote: On Thu, May 28, 2015 at 2:15 AM, cov...@ccs.covici.com wrote: Thanks for your quick reply, but I do have rd.shell=1, but it did not drop to a shell,it just hung, so I could not do journalctl or anything -- the nearest break point was pre-initqueue which was maybe too early and the next one is pre-mount which it never got to. It could very well be a dracut bug (consider bringing the issue to them), but how long did you wait while it was looping. I've seen cases where dracut looped for a few minutes before dropping to a shell. There are a few loops where dracut is waiting for udev to detect all devices, and if it is looking for a device that will never appear, then it will potentially loop forever. There should be a timeout, but I don't know what it is set to by default. Once you get a shell you should be able to inspect the journal/dmesg/etc and try to see what is going on. Sure, you could have booted a rescue CD, but I don't see what it would have gained you as far as troubleshooting the problem with your initramfs (though it would have allowed you to rebuild it if the initramfs itself was broken, or try out a different version/etc). As you point out any logs it creates are stored in tmpfs or ramfs - that is true of just about any initramfs since it won't have any place to store them until it mounts root. I don't know if setting the rescue target would have helped. I think that the behavior of that option is to still boot to your root filesystem and THEN drop to a shell. If you want to force a rescue shell within the initramfs you need to use rd.break or such, and as you point out you need to find the right breakpoint for this. I'd suggest talking to the dracut devs about how it should have behaved in those circumstances. At the very least they might be able to improve the error reporting. Thanks, so how would I get in touch with dracut devs? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] problems debugging a systemd problem
On Thu, May 28, 2015 at 3:30 AM, cov...@ccs.covici.com wrote: Stefan G. Weichinger li...@xunil.at wrote: On 28.05.2015 09:39, cov...@ccs.covici.com wrote: No, the journal is gone, it was only in /run which is on a tmpfs file system. I can boot from a cd all day long, but it would not help one bit. Hm, I think it could help for sure as you could chroot in and do something. For example build a new kernel or initrd or ... You removed openrc? Otherwise boot via openrc and (try to) fix stuff. You could even reinstall openrc from within chroot ... just to get bootin again etc etc I still have openrc, but Dracut won't work with it, at least maybe because I have systemd use flag enabled. Also, in retrospect, that would not have solved my specific problems, because it was related to an rd.lv command which is specific to dracut. But thanks for your suggestion. I wonder what the rescue target is -- I have never seen that before -- maybe I could configure it so I could boot into a shell and fix things and it would be sort of like a little system of its own. Others have already answered, but I will add that if you put emergency anywhere in the kernel command line, then systemd will boot to the rescue target; that's why I suggested to do it in my first answer. Also, as Rich said, if you wait it's possible that systemd (and/or dracut) will drop you into a rescue shell anyway. Unfortunately, thanks to very slow hardware in the wild, the timeout has been increased to three minutes, and I believe those are *per hardware unit*. So if you have five disks, in theory it could take fifteen minutes to get you to a rescue shell. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
[gentoo-user] Unwelcomed non-native language support
In my everyday work at the computer, I read and type at three or even four different languages. However, I do want to have all program menues and system messages only in English. So, when I found out that it can be achieved by setting -nls USE flag at my make.conf file, I did it, recompiled the system and for a few weeks enjoyed the full control of my Gentoo system. (As far as I can remember the gettext package was successfully depcleaned from my Gentoo system just after that.) However, after those few weeks (and some system updates), I have noticed that my system started to translate some system messages into one of the languages I use but which is not my native language. Moreover, running $ equery depends gettext I get about two fullscreens of packages that supposedly depend on gettext. Nevertheless, in all of them the -nls USE flag is either unset or absent. I have tried to depclean the gettext package from my system once again but portage just ignored my $ emerge --depclean gettext command. I think that it is some kind of a bug in the portage tree: when I set -nls USE flag globally, I do expect that the system messages will appear in English only and will not be translated in any other language, but the system understands that as I would have asked for a non-native language support. Of course, this is not my main problem in this life, but every time I get the system messages translated into my non-native language, I feel as I get a reminder that I do not have a full control of my Gentoo system. So, my questions are: 1. Is it a bug? 2. How can I get rid of those unwelcomed translations in the right way.
Re: [gentoo-user] General weirdness - a tale of woe.
On Thursday 28 May 2015 15:36:04 I wrote: On Thursday 28 May 2015 08:44:27 Rich Freeman wrote: With an approach like yours, mdadm will attempt to create md1 by looking ONLY at sda1 and sdb1, and if that pair forms a valid array it is started, and if not it is not. If you add a new drive to your system or for whatever reason the kernel/udev rules change a little or some race condition changes a little then your devices might get different names, and the array will not be assembled. Hmm. I wonder if that's what's happening to me. Perhaps I'd better adopt UUIDs then, once I work out what mine are. Thanks for the advice. I've found blkid, which tells me the UUIDs of my various devices, thus: # blkid /dev/md7 /dev/md7: UUID=ycGMf9-hEP2-tjT4-AtkJ-n8RI-pZ44-RqvlEY TYPE=LVM2_member Two odd things: 1. /dev/md7 is the physical volume in which logical volumes are defined, so I'm surprised to see TYPE=LVM2_member. 2. There is no entry corresponding to /dev/md7 under /dev/disk/by-uuid, though /dev/md1 and /dev/md5 do have entries there [1]. To recap, md1 and md5 are raid-1 with metadata 1.0; they contain extN file-systems; md7 has metadata 1.0 and is a container for 15 logical volumes, each of which has an extN file-system and is mounted somewhere under / (/usr is not among them; it's in the root file-system). What should I be doing about this? [1] For reference, here's the complete list of entries under /dev/disk/by- uuid, minus the date etc: 1bb4ba53-677a-4a0e-b737-f3e274f0e71e - ../../sda2 1e20e3e6-e218-485b-b5ff-be85a287e364 - ../../sda3 3a2a6e94-a6f0-4479-ae87-44887946148c - ../../sda6 3befff76-2a0e-49fa-9e6f-2bd0ed73cf31 - ../../md5 43e655ca-a6ef-4931-99b6-3aa2ad6c30cb - ../../sda8 443ae151-0dd5-47a5-9ff6-56cc1027b4f7 - ../../dm-3 47b057a0-3454-4777-8b53-ae5d240b608c - ../../dm-11 47fe6d95-38be-4581-983c-a6368bd085b2 - ../../dm-6 53f0c9c2-c21f-4c26-942d-8760e0697fe4 - ../../dm-9 72b063b2-76bd-4080-aca0-f0109c1ab25d - ../../dm-4 8e2a7e68-ac48-4aa2-9d33-64fd5ffbe759 - ../../dm-1 94612986-3a94-4de0-85b4-3ee822dca0ef - ../../dm-8 96ba30f0-dc69-4083-ab76-df117432bfae - ../../sdb2 b24e7a6f-8f27-420b-aed5-bc1272ba4856 - ../../dm-12 c05dab85-aff2-4402-ae91-7d9097e68206 - ../../sdb8 c1145ff8-f3c0-48ad-a4fe-50330280be69 - ../../dm-5 d0f6c604-2ef9-4812-afbf-5fd6965201e2 - ../../md1 d531c442-7a7f-4595-a4f3-4e7416b3ec47 - ../../dm-13 d66bad37-84d6-4cf7-9414-3d9535261c41 - ../../dm-2 db56ddb3-3106-40fc-8345-d92a2354eb58 - ../../dm-0 e69863b9-8fcd-4d7a-b94f-64baa3a77852 - ../../sdb3 e7ed40e0-826e-406d-bc5a-5e5b9ef37434 - ../../dm-10 ee1f1925-3e2b-4964-9ad5-248fff623b3c - ../../sdb6 ee39723d-b950-4d00-8c8e-9dac75fe478c - ../../dm-7 (It would have been nice to sort on the final field but I can't see how to do that.) I assume that the ../../dm-N links refer to the LVs - there are 15 of them. md7 is conspicuous by its absence. This seems like a problem to me, and it may account for /dev/md7 sometimes not being started at boot time. -- Rgds Peter
