[arch-general] [arch-projects] [initscripts] [GIT] Arch Linux initscripts repository branch master updated. 2012.07.5-3-gf670511
Tom: From your latest update to the initscripts in the git repo. This makes sure that systemd supports some initscripts API's. With this patch, systemd will: * Parse and use DAEMONS and MODULES from rc.conf * Run rc.local and rc.local.shutdown on boot and shutdown respectively I have everything working but my network with I load manually. I'm using journalctl etc instead of syslog Since systemd parses the rc.conf file now the only thing I should need in the daemons line is [ network ]. Is that correct? I tried to shoot the message below to you on the arch-projects list, but don't have access on that list to send you mail, so here it is. Tom: Good job. The one suggestion I have comes from my bent for making sure people don't miss things. I would estimate 90 to 95 percent of Arch users wouldn't miss and most others won't unless they are in a hurry (me). Would you consider it over the top to change the following line The local timezone is configured by symlinking /etc/localtime to the correct zoneinfo file under to The local timezone is configured by *symlinking* /etc/localtime to the correct zoneinfo file under making symlinking show up in bold text. Myra -- Life's fun when your sick and psychotic!
Re: [arch-general] [RFC, after the fact] initscripts config
On Mon, Jul 23, 2012 at 12:46:52 +0200, Tom Gundersen wrote: 4.2) To be clear, is there going to be a separate configuration for the HARDWARECLOCK and TIMEZONE variables? There already are. That's the problem. HARDWARECLOCK is configured in the third line of /etc/adjtime (see hwclock(8)), TIMEZONE is configured by pointing the /etc/localtime symlink at what you want. What should it look like for people previously using any other value for HARDWARECLOCK? (for virtualization setups where there is no hardware clock) The manpage no longer mentions the any other value option, and hwclock(8) does not say anything about virtual systems either. Geert -- geert.hendrickx.be :: ge...@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
[arch-general] systemd and pm-utils
Hi, When using systemd to handle suspend, it doesn't run hooks in /etc/pm/sleep.d/ which work when running pm-suspend. My hook is called 01custom and is executable. Is it incapable of handing these suspend/resume scripts or does it have its own method? Thanks, jsteel
[arch-general] tmp cleanup problems
Hi guys, Today I noticed a bunch of the following (kinda scary) errors on boot: Attempted to remove disk file system, and we can't allow that. rm_rf(/tmp): Operation not permitted And my /tmp is not cleaned up. I guess this is caused by the systemd-tmpfiles. I'm using initscripts. I use separate partition for my /tmp. I have following in the /etc/tmpfiles.d/tmp.conf: D /tmp 1777 root root 0d D /var/tmp 1777 root root 10d Is anyone seeing similar errors? Is there a problem with my config, or is a bug? Thanks, Lukas
Re: [arch-general] systemd and pm-utils
On Sat, Jul 28, 2012 at 10:50 AM, jsteel m...@jsteel.org wrote: Hi, When using systemd to handle suspend, it doesn't run hooks in /etc/pm/sleep.d/ which work when running pm-suspend. My hook is called 01custom and is executable. Is it incapable of handing these suspend/resume scripts or does it have its own method? It uses /usr/lib/systemd/system-sleep/. $1 = pre | post $2 = suspend | hibernate -- Mantas Mikulėnas
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
On Sat, Jul 28, 2012 at 3:19 AM, David Benfell benf...@parts-unknown.org wrote: It turns out I do need KillSignal= for my memcached jobs. But when I include it in the service file it complains: Unknown lvalue 'Kill-Signal' in section 'Service'. Ignoring. Probably because it's KillSignal, not Kill-Signal. -- Mantas Mikulėnas
[arch-general] btrfs talking install question
in the install boot loader step I noticed speakup was not mentioned in any of the append lines for btrfs when the configuration file was put into the editor. Will speakup=soft added to the append line enable a talking arch linux installation given everything else was done on the arch linux install mp3 Michael Wapples made some time ago? Hardware eventually fails; software eventually works, no amount of band width can fix poor design Jude jdashiel-at-shellworld-dot-net http://www.shellworld.net/~jdashiel/nj.html
[arch-general] Uninstallable Packages
Sorry if this is dragging up an old topic, but I've been poking around AIF as I'm interested in possibly (hopefully) bringing it up to speed and/or improving it, and I noticed that it's still in the repos, but isn't installable by anyone who doesn't happen to have grub legacy still installed on their system, unless I'm missing something. It seems like we'd want to avoid having to manually remove packages every time it becomes impossible to install a set of them. This might be my unfamiliarity with libalpm or pacman or any other myriad part of the stack, but it seems like the type of thing that could be handled by a utlity and a cron job fairly easily. It also seems like the type of thing that wouldn't be too annoying to deal with manually at the moment, but that could get frustrating for both users and devs down the line. Menial maintanence tasks like that[1] tend to end up sucking down a lot of people's time and energy in the long run, in my experience. If the lack of an automated dead package remover is just a lack of time / patches welcome type of thing, I'd volunteer to take a crack at writing the thing. If it isn't, I'd really like to know why. Footnotes: [1] unless, of course, it's not actually a menial task, in which case please enlighten me -- Jeremiah Dodds github: https://github.com/jdodds irc : exhortatory
Re: [arch-general] [arch-projects] [initscripts] [GIT] Arch Linux initscripts repository branch master updated. 2012.07.5-3-gf670511
On Jul 28, 2012 8:19 AM, Myra Nelson myra.nel...@hughes.net wrote: Tom: From your latest update to the initscripts in the git repo. This makes sure that systemd supports some initscripts API's. With this patch, systemd will: * Parse and use DAEMONS and MODULES from rc.conf * Run rc.local and rc.local.shutdown on boot and shutdown respectively I have everything working but my network with I load manually. I'm using journalctl etc instead of syslog Since systemd parses the rc.conf file now the only thing I should need in the daemons line is [ network ]. Is that correct? Yes, that should be sufficient. I tried to shoot the message below to you on the arch-projects list, but don't have access on that list to send you mail, so here it is. It is open to anyone, but you must sign up first and prefix the message subject with [initscripts]. Tom: Good job. The one suggestion I have comes from my bent for making sure people don't miss things. I would estimate 90 to 95 percent of Arch users wouldn't miss and most others won't unless they are in a hurry (me). Would you consider it over the top to change the following line The local timezone is configured by symlinking /etc/localtime to the correct zoneinfo file under to The local timezone is configured by *symlinking* /etc/localtime to the correct zoneinfo file under making symlinking show up in bold text. Makes sense, will do. Tom
Re: [arch-general] Uninstallable Packages
On 28/07/12 13:04, Jeremiah Dodds wrote: Sorry if this is dragging up an old topic, but I've been poking around AIF as I'm interested in possibly (hopefully) bringing it up to speed and/or improving it, and I noticed that it's still in the repos, but isn't installable by anyone who doesn't happen to have grub legacy still installed on their system, unless I'm missing something. It seems like we'd want to avoid having to manually remove packages every time it becomes impossible to install a set of them. This might be my unfamiliarity with libalpm or pacman or any other myriad part of the stack, but it seems like the type of thing that could be handled by a utlity and a cron job fairly easily. It also seems like the type of thing that wouldn't be too annoying to deal with manually at the moment, but that could get frustrating for both users and devs down the line. Menial maintanence tasks like that[1] tend to end up sucking down a lot of people's time and energy in the long run, in my experience. If the lack of an automated dead package remover is just a lack of time / patches welcome type of thing, I'd volunteer to take a crack at writing the thing. If it isn't, I'd really like to know why. Footnotes: [1] unless, of course, it's not actually a menial task, in which case please enlighten me pacman -Sdd aif Btw you could just use the AIF git repo and I guess the package will soon be removed from the repos anyway. -- Jelle van der Waa signature.asc Description: OpenPGP digital signature
Re: [arch-general] tmp cleanup problems
On Jul 28, 2012 10:00 AM, Lukas Jirkovsky l.jirkov...@gmail.com wrote: Hi guys, Today I noticed a bunch of the following (kinda scary) errors on boot: Attempted to remove disk file system, and we can't allow that. rm_rf(/tmp): Operation not permitted And my /tmp is not cleaned up. I guess this is caused by the systemd-tmpfiles. I'm using initscripts. I use separate partition for my /tmp. I have following in the /etc/tmpfiles.d/tmp.conf: D /tmp 1777 root root 0d D /var/tmp 1777 root root 10d Is anyone seeing similar errors? Is there a problem with my config, or is a bug? Thanks, Lukas This is probably a bug. Please file a report. A check was added to avoid accidentally deleting /, I guess it was too strict. Tom
Re: [arch-general] tmp cleanup problems
On 28 July 2012 13:22, Tom Gundersen t...@jklm.no wrote: This is probably a bug. Please file a report. A check was added to avoid accidentally deleting /, I guess it was too strict. Tom OK, I filled it as FS#30893 Lukas
[arch-general] rc.conf changes, virtual consoles and initramfs
So now that rc.conf was split and the change pushed to the stable repos I have been doing the necessary changes in my system. One problem I have found is that it is not clear how I can configure the system to load (in my case) pt-latin9 and compose.latin1 automatically. This is needed to be able to type things like â and ã. Having KEYMAP=pt-latin9 compose.latin1 in /etc/vconsole.conf will result in an error during boot. Another thing I have noticed is that this change may affect the keymap hook for people that need a fully working mapping, such as people with encrypted root. From what I understand /etc/vconsole.conf will be sourced by /usr/lib/initcpio/install/keymap, listing both keymaps will probably result in an error that will not be reported since -q is used. Listing both keymaps separately will also not work since only the last attribution will take affect. Am I missing something here, or have I stumbled upon a problem? -- Mauro Santos
[arch-general] talking arch disk and instructions were both outdated here
I'll have to download a newer copy of the talking arch disk among other things that takes account of pacstrap and uses the arch scripts rather than the framework to install archlinux. The braille instructions I made are also outdated so I'll fix that after some reading. Earlier this morning I got through the partitioning and formatting of a hard drive and since the material I have on archlinux on this end is that outdated, I decided to install debian on the large hard drive only archlinux could install on earlier. Debian would always thrash the disk before. This time no disk thrashing. Apparently use of archlinux to give debian some clues worked. I'll put archlinux on some of my smaller drives in the future when I figure out how to do that now that the talking archlinux I have no longer finds grub to install it. Hardware eventually fails; software eventually works, no amount of band width can fix poor design Jude jdashiel-at-shellworld-dot-net http://www.shellworld.net/~jdashiel/nj.html
Re: [arch-general] Uninstallable Packages
On Sat, 28 Jul 2012 07:04:37 -0400 Jeremiah Dodds jeremiah.do...@gmail.com wrote: Sorry if this is dragging up an old topic, but I've been poking around AIF as I'm interested in possibly (hopefully) bringing it up to speed and/or improving it, and I noticed that it's still in the repos, but isn't installable by anyone who doesn't happen to have grub legacy still installed on their system, unless I'm missing something. This looks like a packaging bug which is rather general: a package in [extra] depends on a package from [community] or [aur]. AIF is one example, ruby is another... Regarding AIF/grub, you could file a bug to either (a) move AIF to AUR, or (b) make grub-bios provide grub. It seems like we'd want to avoid having to manually remove packages every time it becomes impossible to install a set of them. This might be my unfamiliarity with libalpm or pacman or any other myriad part of the stack, but it seems like the type of thing that could be handled by a utlity and a cron job fairly easily. It also seems like the type of thing that wouldn't be too annoying to deal with manually at the moment, but that could get frustrating for both users and devs down the line. Menial maintanence tasks like that[1] tend to end up sucking down a lot of people's time and energy in the long run, in my experience. If the lack of an automated dead package remover is just a lack of time / patches welcome type of thing, I'd volunteer to take a crack at writing the thing. If it isn't, I'd really like to know why. By 'dead' you mean a package no longer available in the official repos? I would be for such tool provided I could disable it. For example, I still have grub-legacy and don't care to migrate to grub2, so I don't want pacman to remove my grub1. Footnotes: [1] unless, of course, it's not actually a menial task, in which case please enlighten me -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] talking arch disk and instructions were both outdated here
On 28/07/12 17:52, Jude DaShiell wrote: I'll have to download a newer copy of the talking arch disk among other things that takes account of pacstrap and uses the arch scripts rather than the framework to install archlinux. The braille instructions I made are also outdated so I'll fix that after some reading. Earlier this morning I got through the partitioning and formatting of a hard drive and since the material I have on archlinux on this end is that outdated, I decided to install debian on the large hard drive only archlinux could install on earlier. Debian would always thrash the disk before. This time no disk thrashing. Apparently use of archlinux to give debian some clues worked. I'll put archlinux on some of my smaller drives in the future when I figure out how to do that now that the talking archlinux I have no longer finds grub to install it. Hardware eventually fails; software eventually works, no amount of band width can fix poor design Jude jdashiel-at-shellworld-dot-net http://www.shellworld.net/~jdashiel/nj.html No clue what you are talking about, but the new install iso is documented here: https://wiki.archlinux.org/index.php/Arch_Install_Scripts -- Jelle van der Waa signature.asc Description: OpenPGP digital signature
Re: [arch-general] talking arch disk and instructions were both outdated here
Am 28.07.2012 17:52, schrieb Jude DaShiell: I'll have to download a newer copy of the talking arch disk among other things that takes account of pacstrap and uses the arch scripts rather than the framework to install archlinux. The braille instructions I made are also outdated so I'll fix that after some reading. Earlier this morning I got through the partitioning and formatting of a hard drive and since the material I have on archlinux on this end is that outdated, I decided to install debian on the large hard drive only archlinux could install on earlier. Debian would always thrash the disk before. This time no disk thrashing. Apparently use of archlinux to give debian some clues worked. I'll put archlinux on some of my smaller drives in the future when I figure out how to do that now that the talking archlinux I have no longer finds grub to install it. Chris Brannon just released a new iso of the talking arch system: http://the-brannons.com/tarch/ Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-general] Uninstallable Packages
Leonid Isaev lis...@umail.iu.edu writes: On Sat, 28 Jul 2012 07:04:37 -0400 Jeremiah Dodds jeremiah.do...@gmail.com wrote: Sorry if this is dragging up an old topic, but I've been poking around AIF as I'm interested in possibly (hopefully) bringing it up to speed and/or improving it, and I noticed that it's still in the repos, but isn't installable by anyone who doesn't happen to have grub legacy still installed on their system, unless I'm missing something. This looks like a packaging bug which is rather general: a package in [extra] depends on a package from [community] or [aur]. AIF is one example, ruby is another... Right, it's definitely a general issue. Regarding AIF/grub, you could file a bug to either (a) move AIF to AUR, or (b) make grub-bios provide grub. In this particular case, AIF *really* does depend on grub. I'm working on that though. I just noticed that it was available for install from extra still, and that got me thinking about repository consistency. It seems like we'd want to avoid having to manually remove packages every time it becomes impossible to install a set of them. This might be my unfamiliarity with libalpm or pacman or any other myriad part of the stack, but it seems like the type of thing that could be handled by a utlity and a cron job fairly easily. It also seems like the type of thing that wouldn't be too annoying to deal with manually at the moment, but that could get frustrating for both users and devs down the line. Menial maintanence tasks like that[1] tend to end up sucking down a lot of people's time and energy in the long run, in my experience. If the lack of an automated dead package remover is just a lack of time / patches welcome type of thing, I'd volunteer to take a crack at writing the thing. If it isn't, I'd really like to know why. By 'dead' you mean a package no longer available in the official repos? I would be for such tool provided I could disable it. For example, I still have grub-legacy and don't care to migrate to grub2, so I don't want pacman to remove my grub1. By 'dead' I mean a package that depends on things in the repos that are no longer there. I was thinking of something that would be detecting these in the repo and removing their availability purely on the server-side so they didn't show up in -Ss, (or even just marking them in some way), not anything touching installed packages on the end of a user running pacman. At the very most, I'd propose having pacman warn the user about the situation so they knew about it, that's about it. -- Jeremiah Dodds github: https://github.com/jdodds irc : exhortatory
Re: [arch-general] talking arch disk and instructions were both outdated here
According to Pierre Schmitz: #Chris Brannon just released a new iso of the talking arch system: #http://the-brannons.com/tarch/ The wiki instructions for installing the Talking Arch system have also been updated here[1]. With the exception of a couple of things you need to do with Speakup to ensure it starts talking at boot time, the standard installation guide[2] and the Beginners Guide[3] should take you all the way from talking install media to a fully functional talking system. Note that as in the older install media, both Lynks and Elinks are included to allow you to read the online documentation. [1]: https://wiki.archlinux.org/index.php/Arch_Linux_for_the_blind [2]: https://wiki.archlinux.org/index.php/Installation_Guide [3]: https://wiki.archlinux.org/index.php/Beginners_guide ~Kyle -- Kyle is a droid. The whole world knows it. This e-mail shows it.
Re: [arch-general] bad md5sum on archlinux-2012.07.15-netinstall-dual.iso?
On Sun, Jul 29, 2012 at 12:20 AM, David C. Rankin drankina...@suddenlinkmail.com wrote: All, Downloading the archlinux-2012.07.15-netinstall-dual.iso from http://cake.lib.fit.edu/archlinux/iso/2012.07.15/, the md5sums.txt files shows: a40c60ce93efb9dfd9a7353310fed35a archlinux-2012.07.15-netinstall-dual.iso However, I get: cc979f9ce51a0ffac73b1f60437ffea6 archlinux-2012.07.15-netinstall-dual.iso I'll try again, but can someone else confirm the md5sum for the iso? Thanks. -- David C. Rankin, J.D.,P.E. i tried from the same site you posted. the md5sums file is correct. you'd better try again. regards,
Re: [arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2012 02:28 AM, Mantas Mikulėnas wrote: Probably because it's KillSignal, not Kill-Signal. Thanks! I'm about to head out the door, but I've corrected the service files accordingly. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQFD8uAAoJELT202JKF+xpzG0QAIRUlbkjJ+A6tehJIVKACgWr T5s2ip9swRrvWOOEhp5+qbFuaz7XA5v6kXFkSlRsWJkr3wxBLDU3bQCpaFgsfREE EDKB8KuQsxv/YYNt/7cvt+RBmmz0ikyNGFf0mR3B9RTIM5xu8oUIZyHhmCVgh7MN cH2yEYzowkoi3M7o/WBcjkseSWVIiVe03OZI0IcnLh6r/WP59MCwDQ4c2j5bLy1F 2WmizqvpkHnbD/y3/3GEfz1ViTajsfKafkgWROtJVIepDHbXWAnFx5xCCdUpQviQ OUg5kRpfpgHoNPFqUoZkH3HE77XrgNaElf5gvimnC1wZdoSaTFFaE5fZzy+jyx/g 9BBDV2TL1rK9Lnb6b96Vv4EFuJbt0IBBAQr4nGENDcT+Y0fr1yjA1Z8rKnRhyDix pv3eEySRyw3ZXMROHc7RnNXIwLbRzKCsWTNrpT8SxSXM/xsgOIoz1CxzM7ctCu/G GTrt7cdpMrXBco5Nv2B69YfuS8Mg0mbiDL1SoUxc9GlfJ50cRn+Q4z+jvaFGNDUC lETDOKWB+ftg+eVR3MpNSBIqaCc63JGUSzIqqy/CIAObILCBj6IMle9/BtNlxqyL Oa961JZ8xfaXE/YBsR8VU/dAXZZ1B8Hk/jdPLbi52/AKkcUMcgQcbuXrCmuz4ryz J9/QriNtI0PEUOc6cqGm =yXdr -END PGP SIGNATURE-
Re: [arch-general] bad md5sum on archlinux-2012.07.15-netinstall-dual.iso?
On 07/28/2012 12:49 PM, Auguste Pop wrote: i tried from the same site you posted. the md5sums file is correct. you'd better try again. regards, Thank you Auguste! I pulled again from http://mirrors.xmission.com/archlinux/iso/2012.07.15 and got the correct checksum. Glad I check :) That is the first checksum failure I've had in a couple of years. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] gimp 2.8 - How to change gtk controls back to normal?
On 07/26/2012 09:39 PM, Oon-Ee Ng wrote: You'd want to check the gimp-user list I think, but if I recall correctly (from reading the list over the last few weeks) this is the new behaviour for 2.8. I don't use the sliders the way you describe, though. Thanks, that is what I figured. The gimp devs have taken the position that 2.8 is perfect and the only people that prefer 2.6 are low-level users that should go find a simpler graphics program. I guess I'm one of those. 2.6 was excellent, 2.8 just gives me a headache... -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Skype locks up my system, not even sysrq keys work
On Thu, Jul 26, 2012 at 12:34 AM, Mauro Santos registo.maill...@gmail.com wrote: I don't know if the graphics card you are using supports video decoding acceleration and if skype can make use of it, but at least here with the ati binary blob, I can only get video decoding acceleration for one video stream at a time, trying to decode 2 videos at the same time with video decoding acceleration results in a hard crash. I have never tried with skype and currently I'm using the free drivers so I have no way to test this. If this is true for your case it should be quite easy to reproduce. It might have been just a random crash caused by skype too, since it isn't the most stable piece of software you can use. Thanks for this valuable advice again. I tested it, and indeed, when I turn on another video, the system locks up after a while (not immediately though).
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
As far as I can tell from the systemd blog and people's reactions here, the only advantages systemd offers are: - Splitting the configuration files, which increases the robustness of the configuration files - Daemon supervision - Bootup speedup by parallelizing the daemons. However, from the responses of some people, like Jorge Almeida, I see that the benefits of systemd are also given by other programs. - It has been suggested in a different thread to implement support for rc.conf to source other files - which would allow rc.conf to split cleanly - As Jorge Almeida suggested, daemontools [1], perp [2] and s6 [3] can supply daemon supervision *without* changing the init scheme - A patch [4] has been posted, and possibly added, to NetBSD's rcorder, which allows daemons to be started concurrently. As far as init systems go, it seems to me that while Arch touts using a BSD-style init, it's actually hacking around sysvinit to provide a BSD-like interface. This seems wrong to me, as BSD already provides a robust init framework. Why simulate that which you can use? In addition, people have cried out against several problems with systemd, which include: - ini-style configuration vs. shell-style configuration - Large, monolithic binary It seems to me that in addition to adding support for systemd could ease compatibility with other distro's, it would be beneficial to add sourcing to rc.conf (or alternatively to symlink the new systemd configuration files to files in rc.d). However, the only reason to do so is because systemd is widely used - i.e. I do not suggest doing this for every init system around. In addition, it may be considered to move from systemv to NetBSD's init, which stays in-line with the simple interface of rc.conf but adds parallelization and modularity. Lastly, it may be beneficial to suggest to users to install one of the daemon monitors. In sum, systemd offers some benefits that are covered by other programs and patches, while drawing much controversy and exacting a toll which seems a bit too large in the eyes of some users. For this reason, while we should add compatibility for systemd, we shouldn't force it down the users throats. Just my two cents. M [1] - http://cr.yp.to/daemontools.html [2] - http://b0llix.net/perp/ [3] - http://www.skarnet.org/software/s6/ [4] - http://forums.freebsd.org/showthread.php?t=25822 (Concurrent execution of rc-scripts with rcorder(8) )
[arch-general] tty0 not available anymore with systemd
Hi, I can't remember to have changed anything critical in the last couple of days/weeks on this system, therefore I suppose it has something to do with some updates. Since a couple of days I no more got an console on tty0 with systemd. tty1 - tty6 work fine, but tty0 just displays the dialog to enter my password to unlock my encrypted root partition and the results of the fsck systemd is performing during the bootup. My best guess would be that it somehow gets stuck in the initrd, but I'm not sure. Is this anything you already experienced? Have I missed something? As said it worked fine in the past and I can't remember to have changed any configuration or something like that. Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] tty0 not available anymore with systemd
Hi, Am 29.07.2012 00:20, schrieb Mantas Mikulėnas: tty0? How exactly do you switch to it? Ctrl+Alt+F1. One cannot have a console on /dev/tty0, sine it's not a real tty but only a pointer to the currently activated console. Ok, maybe the terminology I've used is wrong. However I'm talking about the console, which normally would come up when pressing Ctrl+Alt+F1. Guess it would be tty1 then ;). Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] tty0 not available anymore with systemd
On Sun, Jul 29, 2012 at 1:46 AM, Karol Babioch ka...@babioch.de wrote: Hi, Am 29.07.2012 00:20, schrieb Mantas Mikulėnas: tty0? How exactly do you switch to it? Ctrl+Alt+F1. That's tty1. Try enabling getty@tty1.service: ln -sf /usr/lib/systemd/system/getty@.service \ /etc/systemd/system/getty.target.wants/getty@tty1.service (systemctl enable getty@tty1.service currently works in systemd-git only...) -- Mantas Mikulėnas
[arch-general] systemd script at boot?
Hi, Can systemd run a bash script at/after boot without having to install initscripts-systemd for compatibility with rc.local? I assume initscripts-systemd will be depreciated eventually so wonder if there is a native way to do this, or if this is the workaround for now. Thanks, jsteel
Re: [arch-general] tty0 not available anymore with systemd
Hi, Am 29.07.2012 00:56, schrieb Mantas Mikulėnas: Try enabling getty@tty1.service: Unfortunately this didn't work. It was enabled already anyway. By the way: systemctl shows that it is enabled, but it is also dead for whatever reason :(. [root@vpcs ~]# systemctl status getty@tty1.service getty@tty1.service - Getty on tty1 Loaded: loaded (/usr/lib/systemd/system/getty@.service; enabled) Active: inactive (dead) Docs: man:agetty(8) CGroup: name=systemd:/system/getty@.service/tty1 What would be the best way to figure out what is going on here? Can't find anything suspicious in the logs :(. Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] systemd script at boot?
You can create a service that runs your shell script at boot. I think it would be something like this: /etc/systemd/system/a-name-you-want.service [Unit] Description=a-name-you-want [Service] ExecStart=/path-to-your-script [Install] WantedBy=multi-user.target 2012/7/28 jsteel m...@jsteel.org Hi, Can systemd run a bash script at/after boot without having to install initscripts-systemd for compatibility with rc.local? I assume initscripts-systemd will be depreciated eventually so wonder if there is a native way to do this, or if this is the workaround for now. Thanks, jsteel -- Leonardo Dagnino
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Sat, Jul 28, 2012 at 4:20 PM, Menachem Moystoviz moyst...@g.jct.ac.ilwrote: As far as I can tell from the systemd blog and people's reactions here, the only advantages systemd offers are: - Splitting the configuration files, which increases the robustness of the configuration files - Daemon supervision - Bootup speedup by parallelizing the daemons. However, from the responses of some people, like Jorge Almeida, I see that the benefits of systemd are also given by other programs. - It has been suggested in a different thread to implement support for rc.conf to source other files - which would allow rc.conf to split cleanly - As Jorge Almeida suggested, daemontools [1], perp [2] and s6 [3] can supply daemon supervision *without* changing the init scheme - A patch [4] has been posted, and possibly added, to NetBSD's rcorder, which allows daemons to be started concurrently. As far as init systems go, it seems to me that while Arch touts using a BSD-style init, it's actually hacking around sysvinit to provide a BSD-like interface. This seems wrong to me, as BSD already provides a robust init framework. Why simulate that which you can use? In addition, people have cried out against several problems with systemd, which include: - ini-style configuration vs. shell-style configuration - Large, monolithic binary It seems to me that in addition to adding support for systemd could ease compatibility with other distro's, it would be beneficial to add sourcing to rc.conf (or alternatively to symlink the new systemd configuration files to files in rc.d). However, the only reason to do so is because systemd is widely used - i.e. I do not suggest doing this for every init system around. In addition, it may be considered to move from systemv to NetBSD's init, which stays in-line with the simple interface of rc.conf but adds parallelization and modularity. Lastly, it may be beneficial to suggest to users to install one of the daemon monitors. In sum, systemd offers some benefits that are covered by other programs and patches, while drawing much controversy and exacting a toll which seems a bit too large in the eyes of some users. For this reason, while we should add compatibility for systemd, we shouldn't force it down the users throats. Just my two cents. M [1] - http://cr.yp.to/daemontools.html [2] - http://b0llix.net/perp/ [3] - http://www.skarnet.org/software/s6/ [4] - http://forums.freebsd.org/showthread.php?t=25822 (Concurrent execution of rc-scripts with rcorder(8) ) here here
[arch-general] archlinux-2012.07.15-netinstall - does it have dm_mod and dmraid?
Guys, Does archlinux-2012.07.15-netinstall have the dmraid modules and executable that were missing in archlinux-2011.08.19-netinstall? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] archlinux-2012.07.15-netinstall - does it have dm_mod and dmraid?
Yes. Leonardo Dagnino 2012/7/28 David C. Rankin drankina...@suddenlinkmail.com Guys, Does archlinux-2012.07.15-netinstall have the dmraid modules and executable that were missing in archlinux-2011.08.19-netinstall? -- David C. Rankin, J.D.,P.E.
[arch-general] minbif and systemd scheme
Hey guys… I haven’t seen so far any .service file to allow minbif to be executed with systemd scheme rather than initscripts. This is a solution I tried myself and seems to work so I decided to share. It consists of the .service file for systemd and a .conf file for tmpfiles.d so that /run/minbif is always available with the correct ownership. minbif.service: http://pastebin.com/htxMGJk3 minbif.conf: http://pastebin.com/BuYxXRHr Well, it’s very simple but I think it would be nice if minbif package provided it by itself. Hope it will be useful for someone! Bye =) -- Caio A. Prado URBANA LEGIO OMNIA VINCIT “The ships hung in the sky in much the same way that bricks don’t.” (Douglas Adams) signature.asc Description: signature
Re: [arch-general] systemd script at boot?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2012 04:10 PM, jsteel wrote: Can systemd run a bash script at/after boot without having to install initscripts-systemd for compatibility with rc.local? I assume initscripts-systemd will be depreciated eventually so wonder if there is a native way to do this, or if this is the workaround for now. There *is* a service available that looks like it would execute rc.local. According to the Arch wiki, there is an initscripts-systemd package and and /etc/rc.local and /etc/rc.local.shutdown can be run at startup and shutdown by enabling rc-local.service and rc-local-shutdown.service. The package is not recommended but it exists. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQFMS9AAoJELT202JKF+xpaxMP/iCqs6eH4GwXBbIPaGEda4yr uKCUDs5MI4HIqIOm0wi1uiKqpPuIunsxRTWXJrPpNjQiqZ//tBjntd5RnvakhMwm QSs6ugmf9CXgEmg5HuSI+HExioUUcMH2jwXLQSLlqbKL4NscWkZkrNkPP9WpYWgU yg+kTVmYUyApUT2agBWR9sgkCwY+fqGZntfSVsZM3pPJcqcFQpoMWo02hJ0V6wLb qfZe83b3OeN2R/sM8uB0FsORM9vpQHgyMuJHLT+MSodlBAb/IaLahFhPnxmjEGEG Dhnt+Vw5wsSZ16EFLl5CMb+AFXsmCfIL2iPZe6oqQrW9cJJUiP283TH1yzgVQuQJ ULskw+jrDzJYSyQsees7fwZWBPrgdQgezZFwGjpAHICKvBnbAP1GppxwQAnoF9w2 WgjNSfjCApZQmFXXm1bJ+lrvK7SBdPM14IfcySzIpSU1qexg/hHdj+rmKPsYB1sg 4PwJshP6tmAkPUc94DHXHxyPG1sZAjZYoYyOFEbHdn2uncHIHJHkUnq10pSlZwkB o1rxqYJa/hohjn+H4QPkxtp+UfIJFe4yUIKQjs3ol309pwi6qeIc9ySz0fm7/jxM DWVPzvoyR9hD4tTGbEJAHfaxCcPdCNdG5b+91z6dkY4gxAdfvF94EXCzSZwp+Uti ygEsQQr4aX2KeU4vt0v7 =XPdq -END PGP SIGNATURE-
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2012 02:20 PM, Menachem Moystoviz wrote: In sum, systemd offers some benefits that are covered by other programs and patches, while drawing much controversy and exacting a toll which seems a bit too large in the eyes of some users. For this reason, while we should add compatibility for systemd, we shouldn't force it down the users throats. Having just survived the conversion to systemd, I would offer a few comments: 1) I learned stuff on this list that didn't seem to have been available in the documentation. And I still don't feel I really have a mastery of systemd service files. My feeling is that the man pages and the wiki could probably use more work. 2) It looks to me like there is some ugliness on logging. The Arch wiki suggests a change to the syslog-ng configuration file so that syslog-ng can work with the systemd journal. The trouble I'm having with that is that--these are the examples I know about--apache2 and postfix do not seem willing to log in a way that the systemd journal can pick up; these daemons apparently will only log through the traditional syslog-ng channel, and are not compatible with the new socket. I actually kind of like journalctl (it has a -f option so you can monitor it like you used to be able to do with tail -f /var/log/everything.log), but you really now have to do multiple commands to get everything that everything.log used to get. 3) The conversion to systemd was mostly a lot of work. It wasn't rocket science, though as noted above, I still don't feel I fully understand what's going on. Many, many packages, especially in the AUR, do not yet have service files. This leads me to suspect that there is at least as much angst among package maintainers about all this as we've seen on this list. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQFMgoAAoJELT202JKF+xplvYQAI6DcviIC2y69t2uhXmadn9X 2XYX+2YHbnM4OnAU2ysdj67bgcN2vKDQiT8GrAb+JQOphx8P0Y4NefkC1fMZUpzy f8EMOIzRaHjfOJ4RKjM+eT9hM3Kg3qlroI9hIcEZM59UnCRMLL1qa8RMY58Bj0lV oOBa4Y2MAi7wNJ0ZlLDnQEFGMNhME9sWaGXYV+VRgzjVUaxAz0/MetJum+Wz5YFv QAHyOgSl14UeB1AeenMxZrS0SDSTVvLofXJRCkus5TqvJFJ9cEakHz2RNvN1Tyft yEW/8vgPSFz160GOvGXVxmqSh0SrYWLUGhRWQ1dLd1j4PI6dB85Sh1u1Z8jVx7Z/ 286o4HBvQHkSMALLDxmgdaltuxlKlOwEn/ZEkUB3tZHXWl3/WD8OtZ/EulUgl/DB vOxWHFWFyt4MKU1tHqwP+UTqKI01y515+uARYmih7vQ2JsXyOXhd76nkgm13M7Pp dTuYlQa9AKOQmyRKsMpYMqerdyo1wYflr8ZgE3vOjjCFFYYYOLXq8jePUcepivvv vdf7Gk2GGHoZrNrBdd82SOaVRKMyKdKEJT5TB1rPf+eiQ3LHdxkJhHNsr9s59cux oxo+CI/bM6Vn0HR4c1Q326aG/7gs0GQd4D6nx9uAhUhI2SDxxLVpitTPGLRjo51j BJesYdSnVPX0cMbj4L3I =+xYY -END PGP SIGNATURE-
Re: [arch-general] tty0 not available anymore with systemd
On Sat, Jul 28, 2012 at 6:15 PM, Karol Babioch ka...@babioch.de wrote: Hi, Am 29.07.2012 00:56, schrieb Mantas Mikulėnas: Try enabling getty@tty1.service: Unfortunately this didn't work. It was enabled already anyway. the link isn't broken, right? pointing to, say, /lib/systemd/... what happens if you try to manually start it with `systemctl start getty@tty1.service`? btw, your status output suggest that it never ran (eg. broken link), not that it has already failed. i'm not seeing an issue here, but most of my getty@tty1.service are an empty file which is then `chattr +i` ... it actually pisses my off that the link is installed by default because the damn thing clears the boot output! `chattr +i` puts an end to that real quick ;-) -- C Anthony
