Re: [arch-general] Executing a command of a chroot outside of the chroot
On Sat, Dec 8, 2012 at 12:16 AM, Guus Snijders gsnijd...@gmail.com wrote: Op 7 dec. 2012 23:46 schreef Δημήτρης Ζέρβας 01tto...@gmail.com het volgende: I think that linking won't solve my problem as I include /data/workbench/mnt/lib in my $LD_LIBRARY_PATH... In that case; isn't it enough to include /data/workbench/mnt/lib as the first item in $LD_LIBRARY_PATH ? I realise that my understanding of this var could be flawed. Mvg, Guus That link should work as long as it does not clash with the real dynamic loader. Since you are using an Android, it should not happen. In my Android phone the dynamic loader is /system/bin/linker and the /lib directory doesn't even exist. AFAIK, there is no way to change the embedded dynamic linker when running the executable directly. Maybe some trick with the binfmt_misc could do the trick but I don't think it is enabled on Android. If you really need this, you may have to resort to change every program in the chroot for a script that does the magic needed. Now what really intrigues me is why you want to call a chroot'ed program from outside of the chroot... -- Rodrigo
Re: [arch-general] crypttab support for non-root devices with systemd
On Sat, Dec 08, 2012 at 09:08:28PM +0100, Karol Babioch wrote: Hi, I've installed Arch on a system with a two disk setup, where the first disk is a SSD, which I'm booting from. The second disk is an encrypted software RAID with LVM on top. Now obviously I want the second disk to be unlocked and mounted automatically on boot. This was no problem in the past. Now with systemd it seems to be harder. At least I get asked for the password on boot. This will unlock the device, however afterwards I have to activate the LVM and mount it manually. Is this already supported out of the box? The wiki mentions something about scripts, which may be changed, but I would like to have something more solid than self made scripts, which may break with every update in the future. Best regards, Karol Babioch In core/lvm2 there's an lvm-on-crypt.service which you can enable. In testing/lvm2, you only need lvm-monitoring.service.
Re: [arch-general] crypttab support for non-root devices with systemd
Hi, Am 08.12.2012 21:21, schrieb Dave Reisner: In core/lvm2 there's an lvm-on-crypt.service which you can enable. In testing/lvm2, you only need lvm-monitoring.service. Thanks for your reply. Although probably both of these service files would require the device to the unlocked. Currently its failing at this stage already. From my understanding /etc/crypttab should work with systemd just fine, shouldn't it? So probably my crypttab is invalid? Because right now I'm getting asked for the passphrase on each and every boot. Any plans on when the lvm-monitoring.service will be released? Is it in the early development, or is this something just waiting to be released? Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] crypttab support for non-root devices with systemd
On Sat, Dec 08, 2012 at 09:52:34PM +0100, Karol Babioch wrote: Hi, Am 08.12.2012 21:21, schrieb Dave Reisner: In core/lvm2 there's an lvm-on-crypt.service which you can enable. In testing/lvm2, you only need lvm-monitoring.service. Thanks for your reply. Although probably both of these service files would require the device to the unlocked. No, only one is required, based on the package you're using. We've made some significant changes to lvm explicitly to make it play better with systemd: https://mailman.archlinux.org/pipermail/arch-dev-public/2012-October/023953.html Currently its failing at this stage already. From my understanding /etc/crypttab should work with systemd just fine, shouldn't it? And it does... So probably my crypttab is invalid? Because right now I'm getting asked for the passphrase on each and every boot. Without posting it, I have no idea. You've not mentioned the behavior you expect, either. 'man 5 crypttab' documents the expected format and allowed parameters. Any plans on when the lvm-monitoring.service will be released? Is it in the early development, or is this something just waiting to be released? I don't know what's holding lvm in testing. This singular service is not the silver bullet you're looking for -- it's a package deal. d
Re: [arch-general] Switching between Internet connections
On Fri, 7 Dec 2012 12:41:56 -0600 Leonid Isaev lis...@umail.iu.edu wrote: Is this behavior normal or a bug? I think it is normal. This discussion may shed some light on the bad reasoning likely behind what you are experiencing as ipv6 overscoped on the back of one necessity. http://marc.info/?l=openbsd-miscm=135110703125929w=2
Re: [arch-general] crypttab support for non-root devices with systemd
Hi, Am 08.12.2012 22:06, schrieb Dave Reisner: Without posting it, I have no idea. Basically it looks like this: raid /dev/sdb1xxx In this setup /dev/sdb1 is a encrypted block device. Its not the one mentioned in the beginning, but the situation is quite similar. xxx is the passphrase. This worked just fine with the old initscripts. Maybe I'm missing something, but from my understanding of the appropriate man page it should actually work? You've not mentioned the behavior you expect, either. Right now I get asked for the passphrase during boot. I would like this dialog to disappear. I would like to have the device unlocked, activated and mounted automatically. For the time being I would like to use lvm-on-crypt, only to be replaced with lvm-monitoring once it hits the official repositories. Thanks for your help! Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] crypttab support for non-root devices with systemd
On Dec 8, 2012 8:12 PM, Karol Babioch ka...@babioch.de wrote: Hi, Am 08.12.2012 22:06, schrieb Dave Reisner: Without posting it, I have no idea. Basically it looks like this: raid /dev/sdb1xxx In this setup /dev/sdb1 is a encrypted block device. Its not the one mentioned in the beginning, but the situation is quite similar. xxx is the passphrase. This worked just fine with the old initscripts. Maybe I'm missing something, but from my understanding of the appropriate man page it should actually work? The man page makes no mention of allowing plaintext passwords in crypttab. Sure enough, this doesn't work. Use a key file. You've not mentioned the behavior you expect, either. Right now I get asked for the passphrase during boot. I would like this dialog to disappear. I would like to have the device unlocked, activated and mounted automatically. For the time being I would like to use lvm-on-crypt, only to be replaced with lvm-monitoring once it hits the official repositories. Thanks for your help! Best regards, Karol Babioch
Re: [arch-general] harddisk suspending far to often
On 12/08/12 at 09:48pm, G. Schlisio wrote: Am 07.12.2012 01:49, schrieb Calvin Morrison: On 6 December 2012 17:05, G. Schlisio g.schli...@dukun.de wrote: Am 06.12.2012 21:07, schrieb Jonathan Steel: On Thu, Dec 06, 2012 at 10:59:27AM +0100, G. Schlisio wrote: after updating my laptop today [0] (no testing enabled) i notice that my harddisk keeps spinning down and up every 10 seconds or so. might this be related to the update or where can i stop this? somehow it resolved itself today. now hdd is running continuously again. If it happens again, you can check this with: hdparm -B /dev/sdx If it's spinning down too often, try: hdparm -B 254 /dev/sdx thank you for your advice. hdparm -B /device returns 254 to me now, thats quire expected, because now everything works fine. i wonder, how/whether it could have been altered yesterday. do programs like powertop touch those values? If you are messing around with powertop, yes I think that could have been it. Usually powertop can adjust hd settings i uninstalled powertop after my last post, but yesterday it happend again. when i checked the APM level it was set to 1. i only experience this after suspend to ram. how can i get to know, why this is happening, and maybe stop it? When I still had rotational hard drives, I noticed that my APM level would reset after suspend. This, I later found, is expected behavior. So you either need to put something in /usr/lib/systemd/system-sleep or make an appropriate service file to reinstate the APM. Why it defaults to 1 I have not idea though. Regards, -- Curtis Shimamoto sugar.and.scru...@gmail.com
[arch-general] On /etc/conf.d deprecation
Hello list, from a reply I got to a bug report (FS#32817, reply is private) I found out that configuration files in /etc/conf.d are deprecated and that the supported way is to replicate and customize service files. Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. /etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file. So I'm curious to know why this mechanism was deprecated? Is it speed we gain by not including the EnvironmentFile directive in the systemd unit file? Is there some other reason I might be missing? Thanks in advance, Dimitris
Re: [arch-general] On /etc/conf.d deprecation
On 12/09/12 at 04:01am, Dimitrios Apostolou wrote: Hello list, from a reply I got to a bug report (FS#32817, reply is private) I found out that configuration files in /etc/conf.d are deprecated and that the supported way is to replicate and customize service files. Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. /etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file. So I'm curious to know why this mechanism was deprecated? Is it speed we gain by not including the EnvironmentFile directive in the systemd unit file? Is there some other reason I might be missing? Thanks in advance, Dimitris Keep some kind of configuration fine and use the .include feature of systemd units to source the config with EnvironmentFile=. -- Curtis Shimamoto sugar.and.scru...@gmail.com
