Re: [arch-general] signature from Thorsten Tpper x...@xxx.xxx is unknown trust
On Mon, Jan 28, 2013 at 04:09:54PM +0100, Kwpolska wrote: On Mon, Jan 28, 2013 at 4:08 PM, Thorsten Töpper atsut...@freethoughts.de wrote: On Mon, 28 Jan 2013 15:56:37 +0100 Sébastien Luttringer se...@seblu.net wrote: Have an archlinux-keyring updated before key expiration is an elegant solution. Cheers, Indeed. Also, it was my mistake not to update the key before it expired and I have to apologize for that. By now there is a new archlinux-keyring package that contains the updated key. I'm sorry for all the trouble this has caused. Bonus question, why did the key even expire? That's generally what happens when you put an expiration date on a GPG key and time passes up until the current time exceeds the expiration date.
Re: [arch-general] [arch-dev-public] Drop VI from [core] (was Re: Winter Cleanup of [community])
On Thu, Jan 24, 2013 at 11:27 AM, Paul Gideon Dann pdgid...@gmail.comwrote: On Thursday 24 Jan 2013 11:05:22 Stéphane Gaudreault wrote: +1 to drop vi. I cannot imagine why someone would want to use this crap ... We already have nano in [core], so I think that vim could stay in [extra] (do we really need 2 text editors in [core] ?). Vi is the standard UNIX text-editor. Many admins rely on the fact that vi is available everywhere. It really should be in core. Also, I know you might be referring to plain vi, which is a completely different beast to Vim, but the latter (which provides vi too) has a *huge* userbase. Calling it crap is just bizarre... Paul Incorrect -- ed is the standard unix editor. http://www.gnu.org/fun/jokes/ed-msg.html More seriously, POSIX says vi is optional for us: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html Please remember that dropping it from [core] makes it in no way any less available. I've no problems with moving vi as long as it doesn't disappear from the install media. It's useful to have around long enough until you can pacman -S vim.
Re: [arch-general] [systemd] udevd and udevadm not found in initramfs when using systemd-git
On Thu, Jan 24, 2013 at 12:32:46PM -0600, William Giokas wrote: All, I rebooted my computer today to test some boot flags only to be greeted with an unbootable machine. Here is a transcript of the boot messages: /init: line 9: systemd-timestamp: not found :: running early hook [udev] /init: line 21: udevd: not found :: running hook [udev] :: Triggering uevents... /init: line 21: udevadm: not found /init: line 21: udevadm: not found /init: line 21: udevadm: not found Waiting 10 seconds for device /dev/sda2... ERROR: device '/dev/sda2' not found. Skipping fsck. ERROR: Unable to find root device '/dev/sda2'. And then I am dropped to a root shell. Attached is my mkinitcpio.conf[1]. This only happens when using an initramfs generated with systemd-git. I built this this image[1] using mkinitcpio 0.12.0.15.g1fb6722. I am also using linux-mainline, but that does not seem to have any effect when downgrading or using a different kernel. If I downgrade systemd to 197, however, rebuild the image and reboot, it goes smoothly. Shutting down my computer cleanly is also an impossibility, as `systemctl poweroff` just hangs with no messages printed. This does not happen with 197. Also attached are the pacman -Ql outputs of my systemd-git[3] and [core]s systemd[4], as well as the mkinitcpio -v output[5]. [1] http://ix.io/46o [2] http://ompldr.org/vaDdobQ/initramfs-linux-mainline.img [3] http://ix.io/46n [4] http://ix.io/46m [5] http://ix.io/46l Thank you, -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F The interpreter has moved. It has little to do with the versions of anything but glibc. If you look in /lib64 inside your image, you'll see a broken symlink. This kind of sucks.
Re: [arch-general] mkinitcpio/fsck.btrfs
On Jan 18, 2013 4:52 PM, Jameson imntr...@gmail.com wrote: On Thu, Jan 17, 2013 at 1:37 PM, Leonardo Dagnino leodag@gmail.com wrote: 2013/1/16 Arno Gaboury arnaud.gabo...@gmail.com On 16/01/13||11:22, Tom Gundersen wrote: Hi Arno, On Tue, Jan 15, 2013 at 12:34 PM, Arno Gaboury arnaud.gabo...@gmail.com wrote: HOOKS=base udev autodetect block lvm2 filesystems fsck usr usbinput shutdown modconf When # mkinitcpio, I get this error: - Running build hook: [fsck] == ERROR: file not found: `fsck.btrfs' == WARNING: No fsck helpers found. fsck will not be run on boot. The initramfs-linux.img is still correct, but I was wondering why this error. As you correctly observe, there is no fsck.btrfs binary. When reading the /usr/lib/initcpio/install/fsck script, it seems to me fsck will add the filesystem name and run /usr/bin/fsck.filesystemame.This will of course translate to fsck.btrfs, which does not exist. /usr/bin/btrfsck is the correct binary. This is not a mistake; the btrfsck binary is not meant to be run automatically at boot as the other fsck.* helpers, it is only meant to be used manually to fix problems. btrfs is designed not to need fsck'ing at boot, but does integrity checking at run-time instead. According to /usr/lib/initcpio/install/btrfs script, the btrfs hook is not needed when using udev. How can I solve this issue? Shall I add the btrfs hook? You could add the btrfs hook, but it would not make a difference for the automatic fsck. What it would give you is the ability to fsck btrfs manually from the initramfs in case of problems (i.e., in case root can not be mounted at all). HTH, Tom Tom, thank you for your clean answer. I will then let this error, as I understand it is more a Warning with no negative impact. Regards. If you want to stop getting that error/warning, you can create fsck.btrfs as a symlink to /bin/true (I think). Regards -- Leonardo Dagnino Am I mistaken in thinking that if you only have btrfs filesystems on a machine, then the fsck hook serves no purpose? Thanks, =-Jameson This is correct. People who want to add a symlink to /bin/true aren't solving the right problem and are only potentially causing trouble for themselves down the road.
Re: [arch-general] rEFInd 0.6.4 + linux 3.7.2-1 fail to boot
On Mon, Jan 14, 2013 at 12:10:31PM -0200, André Vitor de Lima Matos wrote: Hi, everyone. I've a HP Pavilion g4 machine with UEFI, using rEFInd. After a upgraded to refind-efi 0.6.4-1 and linux 3.7.2-1, my system stopped to boot. rEFInd loads properly, and others boot options, like EFI Shell and Windows 8 are working, but trying to boot kernel 3.7.2 froze on the message in begin saying Starting vmlinuz-linux ...kernel options. initrd was built correctly. This issue only occurs with linux 3.7.2, downgrading to 3.7.1 makes system bootable again (from where I'm writing). rEFInd config file is basically default, only with timeout changed to 5. My boot options: root=/dev/AndreSYS/Arch resume=/dev/AndreSYS/Swap cryptdevice=/dev/disk/by-uuid/e38e188e-f775-41fe-9607-ce977c7716d8:syslvm ro add_efi_memmap rootfstype=ext4 -- https://profiles.google.com/andre.vmatos Oh the irony... Please subscribe to arch-dev-public if you're going to continue to use the testing repository: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-January/024260.html
Re: [arch-general] Incorporate udev rules in initrd
On Sun, Jan 13, 2013 at 02:21:01PM +, Rodrigo Rivas wrote: On Sat, Jan 12, 2013 at 10:55 PM, Christoph Vigano m...@cvigano.de wrote: On 31.12.2012 11:00, Rodrigo Rivas wrote: On Mon, Dec 31, 2012 at 8:37 AM, Christoph Vigano m...@cvigano.de wrote: How can I tell mkinitcpio to include a custom udev rule? Do I need to write a hook for that? How can a hook for this look like? AFAIK, using FILES=path-to-udev-rule-file should be enough. The udev binaries and basic rules are already there, so adding the custom rule to the image should make it work automagically. HTH -- Rodrigo Sadly, that did not work although the file containing the rule is inside the initrd (verified with lsinitcpio). Any other idea how to debug this? Well... an ugly hack I did to debug the initrd is, if you use grub: 1. In the grub menu press 'e' to edit the boot commands. 2. Remove the 'root=whatever' or change it so something non-existant. 3. Run the boot commands with F10. This way the initramfs will not mount the root filesystem and will drop to a emergency shell. It will run with the initramfs mounted at '/', so you can use it to debug your problem. Note that you still can mount the real root into, for example, '/mnt' and copy or use any tool or file you need that is not available in initramfs (eg 'udevadm'). Yes, it is a hack, but I don't know a proper way to do it. Other distros, such as Ubuntu, have a 'debug=breakpoint' option to do this kind of things. But, hey, it works, I even used it once to convert the root filesystem from ext4 to btrfs without an additional boot device 8-). -- Rodrigo mkinitcpio's manpage documents a 'break' variable which does this sanely.
Re: [arch-general] kernel 3.7.2 - fails to boot - please help
On Sat, Jan 12, 2013 at 10:47:09PM -0500, Genes Lists wrote: On 01/12/2013 10:38 PM, Genes Lists wrote: Followup to my own post - (1) in spite of errors, 3.7.1 kernel seems to have been installed and the laptop once again boots. (2) I still don't understand the errors from mkinitcpio that happened when installing linux in the chroot - is there something I should do to 'clean' up in some way? (3) Looks to me like something is not good with 3.7.2 kernel .. gene There's nothing wrong with the kernel. You've probably been ignoring the warnings from pacman about file being newer than what's in the repos. file-5.12 was removed from [testing] because it was misidentifying kernel images, which broke mkinitcpio. https://bugs.archlinux.org/task/33373 This is fixed for good in mkinitcpio, as the next version won't rely on file at all.
Re: [arch-general] kernel 3.7.2 - fails to boot - please help
On Sat, Jan 12, 2013 at 10:58:01PM -0500, Genes Lists wrote: On 01/12/2013 10:50 PM, Dave Reisner wrote: There's nothing wrong with the kernel. You've probably been ignoring the warnings from pacman about file being newer than what's in the repos. file-5.12 was removed from [testing] because it was misidentifying kernel images, which broke mkinitcpio. https://bugs.archlinux.org/task/33373 This is fixed for good in mkinitcpio, as the next version won't rely on file at all. file-5.12: spot on - and sorry - downgraded to 5.11 linux-3.7.2: Does this explain why 3.7.2 doesn't boot and 3.7.1 does? O Or is something still amiss with 3.7.2 kernel? Thanks ... gene mkinitcpio didn't generate a valid initramfs for the kernel... you can't boot an ARCH kernel without an initramfs. Nothing is wrong with 3.7.2.
Re: [arch-general] kernel 3.7.2 - fails to boot - please help
On Sat, Jan 12, 2013 at 11:19:17PM -0500, Genes Lists wrote: On 01/12/2013 11:09 PM, Dave Reisner wrote: mkinitcpio didn't generate a valid initramfs for the kernel... you can't boot an ARCH kernel without an initramfs. Nothing is wrong with 3.7.2. Was hoping you'd say that :-) Tho now am a tiny bit puzzled that the initramfs created when I installed 3.7.1 actually booted ... I will re-install 3.7.2 and try again! thank you for your help. gene Because mkinitcpio never created anything on upgrade or downgrade. The initramfs image in /boot remained consistent with your 3.7.1 kernel.
Re: [arch-general] How to suppress the list of variables that are output at shell login?
On Mon, Jan 07, 2013 at 05:51:39PM +0530, Jayesh Badwaik wrote:
Hi,
On Mon, Jan 7, 2013 at 5:18 PM, Rodrigo Rivas
rodrigorivasco...@gmail.com wrote:
You may also add a `echo $profile` command in the /etc/profile file, just
after `for profile in /etc/profile.d/*.sh; do` to see the trace of sourced
files.
Thanks for the suggestion. I implemented this and got the following output.
/etc/profile.d/gpg-agent.sh
No package owns this file. Where did it come from?
declare -x HOME=/root
declare -x LOGNAME=root
declare -x OLDPWD
declare -x PATH=/usr/bin:/usr/local/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
declare -x PWD=/root
declare -x SHELL=/bin/bash
declare -x SHLVL=1
declare -x TERM=xterm
declare -x USER=root
/etc/profile.d/gpm.sh
/etc/profile.d/jdk.sh
I guess, this means the gpg-agent.sh is the one outputting all the
terms. So, I read the gpg-agent.sh and here is the output for the
same:
if pgrep -u ${USER} gpg-agent /dev/null 21; then
eval `cat $gnupginf`
eval `cut -d= -f1 $gnupginf | xargs echo export`
else
eval `gpg-agent --enable-ssh-support --daemon`
fi
Ew.
And after commenting lines selectively, the line
eval `cut -d= -f1 $gnupginf | xargs echo export`
seems to be outputting all the variables. I am not sure what this line
does exactly. I am guessing that it checks if the gpg daemon is on,
and if it is not, it turns it on, and if it is, it lists some
environment variables, according to some condition. I am not sure
which.
Is my guess correct? In which case, would it be safe to comment the lines?
No, this happens because nothing is passed to xargs, which results in:
eval `echo export`
Or, simple running 'export'. You'll see that running export without any
arguments simply dumps a list of exported variables.
I'd suggest removing this file entirely if no package owns it and using
something like keychain if you want a singleton ssh-agent for your user.
Re: [arch-general] [arch-dev-public] network interface naming with systemd 197
On Mon, Jan 07, 2013 at 09:35:45AM -0600, Leonid Isaev wrote: On Mon, 07 Jan 2013 08:23:10 +0100 Andrea Scarpino and...@archlinux.org wrote: On Monday 07 January 2013 07:51:30 Allan McRae wrote: Upstream decision... vanilla packages should follow it. I agree with Allan. We don't use to change the default behavior. Ship it as default and add two lines on how to disable it. If I may chime in... regarding switching from MAC-based iface naming to ID_NET_NAME_PATH-based naming. How exactly are these ID_NET_NAME_PATH variables assigned? For instance, I have a box with 2 pci intel cards: 1. DEVPATH=/devices/pci:00/:00:05.0/:02:00.0/net/elan0 ID_NET_NAME_PATH=enp2s0f0 2. DEVPATH=/devices/pci:00/:00:06.0/:03:00.0/net/elan1 ID_NET_NAME_PATH=enp3s0f0 Do I correctly understand that enp?s0f0 is chosen based on a particular pci slot the card is inserted in and will change if I choose to replug the cards? Yes, it's derived from the PCI path of the card in this case, and yes it'll change if you physically move the card. There's some examples of composed paths in udev source: http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n21 If this is a concern to you, ID_NET_NAME_MAC is also available, which will always be the MAC from the hardware and should never be any possible faked address from the OS side. $ macchanger -m 12:34:56:78:90:ab eth0 Current MAC: de:ad:be:ef:00:01 (unknown) Faked MAC: 12:34:56:78:90:ab (unknown) $ udevadm info -q property /sys/class/net/eth0 | grep ID_NET_NAME_MAC ID_NET_NAME_MAC=enxdeadbeef01 d
Re: [arch-general] Pidgin voice/video support
On Sat, Dec 29, 2012 at 11:36:28PM -0500, Scott Lawrence wrote: Hey all, The pidgin package in extra appears to be compiled without voice/video support (`--disable-vv`). Is this ommission intentional? It requires an older version of farstream we don't package https://bugs.archlinux.org/task/33159 d
Re: [arch-general] Install problem
On Thu, Dec 27, 2012 at 07:45:19PM +, Fons Adriaensen wrote: Hello, today I did a fresh install using the december release of the install media. Everything done 'to the book' (the install guide wiki page). Bootloader is syslinux. When booting the freshly installed system, I get the syslinux menu, select Archlinux or fallback, things seem to be normal for a few seconds then everything stops. After some time I get a message that /dev/sda3 (which is the / partition) can't be found and I'm dropped into an emergency shell. Use a persistent identifier such as a LABEL or UUID tag, rather than an unreliable kernel name. Not convinced this is the problem, but it's better to let /init figure out what device this really corresponds to in the kernel. No LVM or RAID, just a single SATA disk with sda1 = /boot (100M, ext2) sda2 = swap (2G) sda3 = / (~250G, ext4) Assuming this is native SATA and not setup in compat mode, your image needs to contain the modules 'ahci', 'sd_mod', and 'ext4' (ignoring dependencies which I assume mkinitcpio found, added). Make sure the kernel version for the image matches whatever the installer gave you (3.6.10-1-ARCH if you stuck with [core]). 'lsinitcpio -a' will nicely lay all this out for you. You'll probably find your problem/solution here which will involve rebuilding the initramfs. Make sure /boot is mounted... Partioning done with cfdisk. Unrelated, I suggest you don't use cfdisk until util-linux 2.23. cfdisk still expects disk geometry to be measurable in cylinders, heads and sectors -- an idea that's been obsolete for nearly 2 decades. fdisk and parted are both better choices if MBR is sufficient. d
Re: [arch-general] Nvidia Driver woes on Macbook 3,2
On Dec 20, 2012 6:27 AM, Daniel Bryan danbr...@gmail.com wrote: First of all, I'm sorry if the general discussion list isn't for questions like this. I wasn't sure how to figure out what's appropriate. Per https://bbs.archlinux.org/viewtopic.php?id=154496, I've had a real ordeal trying to get video working on Arch on a repurposed late 2010 Macbook Air. I've never had issues like this with video / X in Arch before. I know this creature... I used to own one. Used to. I'm wondering if anyone can give me a push in the right direction to at least diagnose this problem. It's getting pretty hard to work without a browser! $ lspci | grep VGA 02:00.0 VGA compatible controller: NVIDIA Corporation MCP89 [GeForce 320M] (rev a2) Here's what I've tried in EFI mode: - all the proprietary drivers listed on the nvidia page on the Arch wiki; each of them either wouldn't load X or showed a blank screen; ctrl-alt-fN didn't work and I had to do a hard reboot The proprietary nvidia driver cannot work in EFI mode -- it depends on the bios being available for various parameters in locating the screen. - standard nouveau setup - X sort of starts up but there are weird artifacts, mouse doesn't work, and it freezes up pretty quickly. - nouveau with mesa-git - as above - nouveau with mesa-full - above This is actually progress based on bug reports I read a while ago and in line with my previous comment. The *only* choice at the time was bios mode with the nvidia driver. I've also tried BIOS compatibility mode, but I wasn't able to get my drives to mount. Probably because in EFI mode, the sata disk uses native AHCI rather than PATA compat (ata-generic and pata-acpi). You likely tried to use a auto detect trimmed image which didn't have the proper modules. Using the fallback image would have gotten you far enough to rebuild the pruned initramfs with the right modules. At any rate, it was very slow to boot, so I really want to stick with the EFI + GRUB2 setup. My Xorg.0.log when loading the proprietary driver, which just shows a black screen: http://pastie.org/5556341 My Xorg.0.log when loading nouveau, which has strange artifacts, incomplete rendering of windows, and soon locks up: http://codepad.org/QFdP9Fax I have no .xinitrc file. For nouveau, I have the default X config. For the proprietary drivers, I can nvidia-xconfig. I've been trying everything both as a normal user and as root. Video was working fine under OSX the day before I installed Arch so I don't think it's the hardware. Ah. But it is... Just not in the way you expect. Mac hardware is not off the shelf hardware you find anywhere else. The nvidia 320M is an MBA only device, and as such, drivers work best on OSX and only by luck elsewhere. I'm at a loss here and would appreciate any advice. I'm afraid I have nothing positive to add. I ended up selling my MBA. Thanks, Daniel
Re: [arch-general] Mounting /var early in systemd
On Wed, Dec 12, 2012 at 11:10:24AM +, Paul Gideon Dann wrote: On Wednesday 12 Dec 2012 00:40:43 Tom Gundersen wrote: Sockets in /var should automatically be ordered After=var.mount, so this should in theory just work. How are you mounting /var? I assume an fstab entry would not do in your setting, so I guess you somehow generate a custom var.mount file? Please link to the code so I could have a look. That's what I hoped too. I've tried several approaches. I'm trying a mount unit here, because I was hoping there might be a bit more magic to it. However, it does mean that I had to hardcode the mount path (%H doesn't seem to work), but if I can get this working, I have a oneshot unit that should take care of that. I'd sooner use a generator than a oneshot unit to perform a mount. I created a sockets-pre.target unit, ordered before sockets.target, and the following unit is ordered before that, because I was hoping that might help. It doesn't, presumably because the socket units and this unit are all before sockets.target, and all get started at the same time. If the sockets were set after sockets-pre.target, this would probably work. (But in that case they might as well be specified directly in the unit, and the sockets-pre target can be dropped.) If sockets.target is too late, then order it before that. man bootup shows a synchronization point at sysinit.target before jobs for sockets.target are even dispatched. [Unit] Description=/var directory for the node DefaultDependencies=false Requires=sockets-pre.target Before=sockets-pre.target [Mount] What=192.168.0.1:/srv/nfs/cluster-store/vars/node07 Where=/var Type=nfs Options=v3,nolock [Install] RequiredBy=local-fs.target Bootchart is available here: http://giddie.homeip.net/screenshots/cluster-node-var-mount-boot-chart.png Thanks, Paul
Re: [arch-general] systemd and core dumps
On Mon, Dec 10, 2012 at 11:24:17PM -0500, Olivier Langlois wrote: Apparently core dumps (if enabled) are stored in the systemd journal. ~ $ cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e systemd-coredumpctl looks nice to use but I am not totally sure yet that collecting core dumps in the journal is something that I want systematically. I am looking for a way to override this. I haven't found any mention of that option in systemd documentation. Does anyone here would have an idea where I could search? Olivier It's configured via /lib/sysctl.d/coredump.conf, which is kind of sneaky. If you want to disable coredump collection in the journal: ln -s /dev/null /etc/sysctl.d/coredump.conf And then reapply sysctl settings: /lib/systemd/systemd-sysctl d
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
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] 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] Escape sequences instead of colors in terminal
On Dec 5, 2012 6:11 PM, Marcel Korpel marcel.li...@gmail.com wrote: Hi all, I already asked this at the forums, but as no one has an answer there I hope someone here knows a solution. On a Git cheat sheet I found that I could add nice colors to Git's output, so I edited my ~/.gitconfig by adding: [color] ui = auto [color branch] current = yellow reverse local = yellow remote = green [color diff] meta = yellow bold frag = magenta bold old = red bold new = green bold [color status] added = yellow changed = green untracked = cyan When performing a git log my terminal looks like this: http://ompldr.org/vZ2t1bA (escape sequences instead of colors). The same problem appears with git diff: http://ompldr.org/vZ2t1bg However, as you can see in the second screenshot, git status and git branch look correct. This happens in urxvt, but also in xterm and the terminal screens (tty[1-6]). Do you know what's wrong? Regards, Marcel Your pager is to blame. Assuming you're using less, you need to pass the -R option. You can add: export LESS=-R To your shell rc file.
Re: [arch-general] rootfs remains in ro at boot on fresh install with new December ISO
On Mon, Dec 03, 2012 at 05:00:48PM +, LANGLOIS Olivier PIS -EXT wrote: Hi, I hope it is not caused by the shortcut that I have taken to update my usb install key from november iso to december iso as described in the other thread. The first symptom that I have observed is that dhcpcd isn't able to update /etc/resolv.conf I am going to provide as much relevant info so you can tell me what to look for 1. Installed from december iso on newly created GPT ext4 partitions 2. Bootloader GRUB2 3. Did a systemctl mask tmpfs as I am mounting a disk partition on /tmp from fstab 4. Double checked 2-3 times that all my mounts are rw in fstab You'll want to actually provide your /etc/fstab as well as the output of: systemctl status / Right after booting... 5. Once logged, I have no problem doing mount -o remount,rw / 6. I have removed the ro kernel parameter option in grub.cfg (BTW, why is this used at all? I'm a little bit ignorant about Linux booting good practices). By doing so rootfs still remains ro. 'ro' is the default if neither 'rw' nor 'ro' are specified. If you want your root to be mounted rw initially, you need to do 2 things: 1) explicitly add 'rw' to your kernel cmdline 2) include the fsck hook in your initramfs Otherwise, it's left up to your /etc/fstab to ensure that it's remounted properly. I am suspecting either systemd or the content of the initramfs. Until now, those are still black boxes to me. What should I look at to resolve my rootfs ro problem? Strange suspicion... Without seeing it, I suspect your /etc/fstab is at fault, simply because I've learned better than to trust anecdotal evidnce. d
Re: [arch-general] systemd sessions, su -l, and access to /dev/
On Sun, Nov 25, 2012 at 12:27:01PM -0500, Genes MailLists wrote: Just to be clear, this isn't something the systemd developers came up with. ConsoleKit was responsible applying the same ACLs for local sessions before. To give credit where it's due thoough I could me misremembering, but don't CK and systemd share the same developers? CK was their first go at session permission management - as of spring 2011 or so they deprecated CK and absorbed its functionality into systemd / logind. gene/ Same developers? Not really[0]. Same company? Sure, Red Hat gets their paws on a lot of widely used Linux software (including being the largest corporate contributor to the kernel, at least in 2011). [0] http://cgit.freedesktop.org/ConsoleKit/log/ d
Re: [arch-general] Gentoo udev fork w/o systemd
I normally wouldn't respond to trolls on this list and really I'd rather have seen this post be moderated straight to where it belongs -- /dev/null. However On Mon, Nov 19, 2012 at 2:31 PM, Jérôme Bartand moije...@gmail.com wrote: I want to bring to your attention that Gentoo is working on a udev fork called eudev that will - respect the Unix philosophy Sorry, perhaps you could explain how current udev (udev, not systemd) defies this, and why it's relevant for a small set of binaries and library which only serve to handle uevents from the kernel. Please keep in mind when writing your response that udev is still entirely useable without systemd. No, Lennart's infamous post exclaiming how standalone udev has no future is not an indication that it's going to break any time soon. - be POSIX-compliant and get rid of glibcisms Why does this matter? Do you have any concept of what POSIX defines and doesn't define? udev is a piece of software which is intimately involved with the Linux kernel, and necessarily must be, to accomplish its goals. Furthermore, the glibcisms used by udev has nearly wholly been adopted by the other popular libcs -- eglibc, uclibc, and musl. - have no unnecessary dependencies (systemd, kmod) You seem to have this backwards. systemd relies on udev, not vice versa. kmod is a real thing which solves a real problem. Going back to module-init-tools causes unsolvable regressions which were addressed by the implementation of a library which userspace has been lacking for years, and which was developed after much talk at the Linux Plumbers conference a year ago. Jon Masters and Rusty Russel both strongly support the implementation of libkmod, as do other people who are well known in low level userspace and kernel space as well. Feel free to point out why this is a bad idea. - support separate /usr Please explain why udev makes this a non-reality. A properly working separate /usr without an initramfs is a unicorn. It's been broken long before udev did whatever you think it did to break it. It's hopelessly pointless to do, and if you're still bent on it, the modern initramfs implementations support mounting a separate /usr from early userspace, and cleanly unmounting it on shutdown. Do you have any concept of what the problems associated with this are? You can't possibly, or else you wouldn't be parroting this tripe. http://thread.gmane.org/gmane.linux.gentoo.project/2262 Maybe you should have pointed out this thread: http://gentoo.2317880.n4.nabble.com/udev-ng-Was-Summary-Council-meeting-Tuesday-13-November-2012-td252237.html Which really only points out how flawed their non-existant plan is, and how much resistance they're getting to the idea. I can only assume you haven't actually read it. with the goal to make it default for Gentoo in the future, along with OpenRC. I know from past discussions on this mailing list that not everybody in the Arch community is happy with systemd. They are looking for contributors and this is an opportunity for cross-community collaboration. Feel free to join them. Your sinking ship awaits you.
Re: [arch-general] Invalid signatures
On Tue, Nov 06, 2012 at 01:50:01PM -0500, David Rosenstrauch wrote: Saw these errors from pacman today, which are preventing me from upgrading some packages: error: directfb: signature from Eric Belanger e...@archlinux.org is invalid error: xmms2: signature from Sergej Pupykin a...@sergej.pp.ru is invalid error: failed to commit transaction (invalid or corrupted package (PGP signature)) Anyone have an idea what's up? DR Nuke the packages from your cache, and redownload them. The error message is misleading -- the signatures are invalid FOR the packages, meaning the package data is not what the signature expected. The situation is much improved come pacman 4.1 -- we'll just prompt you to delete the package, much like we did historically when a package failed checksums. d
Re: [arch-general] Invalid signatures
On Tue, Nov 06, 2012 at 01:11:38PM -0600, Leonid Isaev wrote: On Tue, 6 Nov 2012 14:02:23 -0500 Dave Reisner d...@falconindy.com wrote: On Tue, Nov 06, 2012 at 01:50:01PM -0500, David Rosenstrauch wrote: Saw these errors from pacman today, which are preventing me from upgrading some packages: error: directfb: signature from Eric Belanger e...@archlinux.org is invalid error: xmms2: signature from Sergej Pupykin a...@sergej.pp.ru is invalid error: failed to commit transaction (invalid or corrupted package (PGP signature)) Anyone have an idea what's up? DR Nuke the packages from your cache, and redownload them. The error message is misleading -- the signatures are invalid FOR the packages, meaning the package data is not what the signature expected. The situation is much improved come pacman 4.1 -- we'll just prompt you to delete the package, much like we did historically when a package failed checksums. d A bit OT, but anyway... Are there any plans for actually storing *.sig files in the cache alongside the packages? This costs a tiny amount of space, but IMHO will make verification (especially of old packages) much easier. We don't have any plans right now to do this. d
Re: [arch-general] Forking daemons and systemd
On Mon, Nov 05, 2012 at 10:01:11AM -0600, Leonid Isaev wrote: Hi, I was wondering whether there is a guideline regarding using Type=forking daemons in systemd units. For instance, if a daemon supports a cmdline switch to run in foreground isn't it better to use this argument in ExecStart? Personally, I was bitten by this with haveged.service which fails on shutdown and whose unit has Type=forking, but I also noticed that ntpd is allowed to fork. Both of them support foreground operation (haveged -F and ntpd -n respectively)? Essentially, it comes down to ordering of other daemons. It's always going to be some trifling amount faster to start a daemon in the foreground because systemd assumes it to be alive as soon as it starts. Conversely, a Type=forking daemon is only considered alive only once the parent process has exited. What this means is that while you might be able to start a daemon which normally forks in non-forking mode, you can't guarantee that daemons which rely on the non-forking daemon can be reliably started, since various listeners or other channels may not be established in time. The ideal solution is to implement sd_notify() and use Type=notify, or full blown socket activation should it be appropriate for the daemon. Both of these cases allow for essentially fire-and-forget style startup with guarantees of availability for ordering. Of course, if you don't think you ever need to order anything on a given daemon, then Type=simple is just fine. HTH, d
Re: [arch-general] USB Flash drive problems
On Tue, Nov 06, 2012 at 03:23:25AM +0800, Rashif Ray Rahman wrote: On 6 November 2012 02:50, Squall Lionheart headmastersqu...@gmail.com wrote: I guess running systemctl should tell you? If you are using systemd it will list a lot of running services. Otherwise I assume it will return a dbus error (but I haven't tried that myself, so only a guess). FYI, I haven't updated to systemd yet and the error when running systemctl reads: Failed to get D-Bus connection: No connection to service manager. Yes, that is correct behaviour, and means you're not running systemd. I believe a valid logind session needs to exist for these to work, and that means booting with systemd. Just to be clear, the logind session isn't needed -- systemd's private socket needs to be available, meaning /run/systemd/private exists. d
Re: [arch-general] USB Flash drive problems
On Mon, Nov 05, 2012 at 08:22:33PM +0100, coderkun wrote: Am Montag, den 05.11.2012, 18:22 + schrieb P .NIKOLIC: How do i check to see if it is systemd or not $ printf %d `systemd-notify --booted` systemd-notify doesn't print anything. If you really want to print something: $ systemd-notify --booted echo booted on systemd or $ systemd-notify --booted; echo $? man systemd-notify: “[…] --booted Returns 0 if the system was booted up with systemd, non-zero otherwise. […]” Note the returns, not prints. d
Re: [arch-general] Forking daemons and systemd
On Mon, Nov 05, 2012 at 02:37:15PM -0600, Leonid Isaev wrote: On Mon, 5 Nov 2012 11:18:48 -0500 Dave Reisner d...@falconindy.com wrote: On Mon, Nov 05, 2012 at 10:01:11AM -0600, Leonid Isaev wrote: Hi, I was wondering whether there is a guideline regarding using Type=forking daemons in systemd units. For instance, if a daemon supports a cmdline switch to run in foreground isn't it better to use this argument in ExecStart? Personally, I was bitten by this with haveged.service which fails on shutdown and whose unit has Type=forking, but I also noticed that ntpd is allowed to fork. Both of them support foreground operation (haveged -F and ntpd -n respectively)? Essentially, it comes down to ordering of other daemons. It's always going to be some trifling amount faster to start a daemon in the foreground because systemd assumes it to be alive as soon as it starts. Conversely, a Type=forking daemon is only considered alive only once the parent process has exited. What this means is that while you might be able to start a daemon which normally forks in non-forking mode, you can't guarantee that daemons which rely on the non-forking daemon can be reliably started, since various listeners or other channels may not be established in time. The ideal solution is to implement sd_notify() and use Type=notify, or full blown socket activation should it be appropriate for the daemon. Both of these cases allow for essentially fire-and-forget style startup with guarantees of availability for ordering. Of course, if you don't think you ever need to order anything on a given daemon, then Type=simple is just fine. HTH, d Aha... thanks for the clarification. I'm pretty sure that havege does not open any sockets/has to be a dependency of anything, but ntpd I'll have to check. It isn't just side effects which are a concern -- it might be the facility being provided that you want to wait on. Using part of your own example, you might not want to start your mail daemon before ntpd has run, to ensure proper timestamping. There's even a 'time-sync.target' documented by systemd.special(7) which one might want to order on, making ntpd's startup more important. d
Re: [arch-general] iptables/ip6tables unit error
On Sun, Nov 04, 2012 at 12:07:59AM -0300, Martín Cigorraga wrote: Hi all, today I found this error with the iptables/ip6tables units, does anybody know what is happening? ~ $ su root /home/msx # systemctl enable iptables.service ln -s '/usr/lib/systemd/system/iptables.service' '/etc/systemd/system/multi-user.target.wants/iptables.service' /home/msx # systemctl start iptables.service Job for iptables.service failed. See 'systemctl status iptables.service' and 'journalctl -n' for details. /home/msx # systemctl status iptables.service iptables.service - Packet Filtering Framework Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled) Active: failed (Result: exit-code) since Sun, 2012-11-04 00:00:01 ART; 11s ago Process: 5442 ExecStart=/usr/sbin/iptables-restore /etc/iptables/iptables.rules (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/iptables.service Nov 04 00:00:01 heybeavis systemd[1]: Starting Packet Filtering Framework... Nov 04 00:00:01 heybeavis iptables-restore[5442]: Can't open /etc/iptables/iptables.rules: No such file or directory Perhaps you want to pay attention to this line right here. There is only a sample config shipped with iptables. Nov 04 00:00:01 heybeavis systemd[1]: iptables.service: main process exited, code=exited, status=1/FAILURE Nov 04 00:00:01 heybeavis systemd[1]: Failed to start Packet Filtering Framework. Nov 04 00:00:01 heybeavis systemd[1]: Unit iptables.service entered failed state This have me a little disoriented since iptables are built in the stock kernel, the one I'm using o_0 Some day people will read their own error messages.
Re: [arch-general] SystemD: Is there a way to disable PrivateTmp globally?
On Fri, Nov 02, 2012 at 10:48:53AM +0100, Rodrigo Rivas wrote: On Thu, Nov 1, 2012 at 7:11 PM, Jan Steffens jan.steff...@gmail.com wrote: The files are in subdirectories. /tmp/systemd-private-XX is bound to /tmp, /var/tmp/systemd-private-XX is bound to /var/tmp. Also you can get which directories are used by which process with the following command: $ sudo grep systemd-private /proc/*/mountinfo I don't know if there is a proper tool to do that, though. -- Rodrigo Find the pid of the process, and findmnt can show you a pretty layout of the mount namespace: findmnt -N pid
Re: [arch-general] [arch-dev-public] Big changes to LVM2 in testing
On Fri, Nov 02, 2012 at 10:59:41AM +0100, Christian Hesse wrote: Thomas Bächler tho...@archlinux.org on Thu, 2012/11/01 15:34: Am 01.11.2012 15:22, schrieb Christian Hesse: Thomas Bächler tho...@archlinux.org on Thu, 2012/11/01 02:05: I discovered some new awesomeness in LVM2 (okay, not THAT new, but still, so far unknown to me). Just to be sure and as in testing can lead to some confusion... This has been enabled in 2.02.98-2? Yes, correct. Now that we have bigger changes to the package... How about moving everything to /usr/ and getting rid of the complicated configure call? pacman 4.1 is a blocker for moving ahead with the /usr merge. It hugely improves the conflict checking when directories become symlinks.
Re: [arch-general] systemd + crypttab
On Thu, Nov 01, 2012 at 03:42:42PM -0200, André Vitor de Lima Matos wrote: Hi. I've a system where there's a harddisk encrypted with luks and a lvm pv over it, used for backup. This disk is never removed or inserted while system is online, but not in every boot up it's present. Setting this volume in crypttab, when disk is absent, cryptsetup service hangs for several seconds, before timing out and allowing systemd to complete boot. There's any way of avoiding this, may be putting it to background, or something like this? Thanks, crypttab(5) explains that nofail is the option you want to use: nofail The system will not wait for the device to show up and be unlocked at boot, and not fail the boot if it doesn't show up. You'll need this in /etc/fstab as well. d
Re: [arch-general] Moving CK-removal + GNOME 3.6? Announcement draft.
On Mon, Oct 29, 2012 at 4:33 PM, Greg Bouzakis gregbouza...@gmail.com wrote: Tom Gundersen wrote: What about: ConsoleKit replaced by logind With GNOME 3.6, polkit and networkmanager moving to extra, ConsoleKit has now been removed from the repositories. Any package that previously depended on it now relies on systemd-logind instead. That means that the system must be booted with systemd to be fully functional. In addition to GNOME, both KDE and XFCE are also affected by this change. This is mostly OK but not only users of DE's are affected. Its pretty much everyone but at least a mention on DM's should be added as well. And probably a mention on [0] as a solution for people not using one. [0]: http://blog.falconindy.com/articles/back-to-basics-with- x-and-systemd.html My 2 cents Greg No, my blog post is a workaround for the current status quo. If everyone is going to need to do this, we may as well just modify our own shipped /etc/X11/xinit/xserverrc as proprosed here: https://bugs.archlinux.org/task/32206 dave
Re: [arch-general] Strange network problem
On Mon, Oct 22, 2012 at 10:15:18PM +, Fons Adriaensen wrote: Hello all, I've got a strange problem with a machine that had a fresh install three weeks ago. Nothing new has been installed on it since then. About one time in four, after that machine has been booted, a ssh to it (on a LAN) fails with 'no route to host'. Using ip link and ip addr on it shows everything is OK, it's not a NIC that gets the And 'ip r' shows the machine has a default route to the gateway? It's a two way street. Do you have any roblems with outbound connections originating from this machine? d wrong name or so. The network on that machine is set up using netcfg, in the recommended way (/etc/conf.d/netcfg). Rebooting has solved the problem in all cases. Sounds delightfully racy. Any hints as to what is going wrong ? I'm not sure there's enough info here for anyone to do anything more than guess.
Re: [arch-general] Leafnode and Systemd
On Mon, Oct 22, 2012 at 11:19:37PM +0100, Whiskers wrote: Thank you to all those who responded :)) I now have Leafnode-2 up and running smoothly with systemd. I have created these files: $ cat /etc/systemd/system/leafnode.socket [Unit] Description=Leafnode NNTP Socket [Socket] ListenStream=119 Accept=yes [Install] WantedBy=sockets.target and $ cat /etc/systemd/system/leafnode@.service [Unit] Description=Leafnode NNTP service After=syslog.target This isn't needed. syslog is always available thanks to the journal socket. [Service] ExecStart=/usr/local/sbin/leafnode /usr/local? StandardInput=socket User=news Access control depends entirely on ufw (iptables), rather than specifying a hostname or IPv6 or IPv4 number in leafnode.socket, although that would Binding to a specifc IP is hardly what I'd call access control. probably work instead. The ListenStream line could probably be omitted entirely, unless some port other than 119 is required. Without the ListenStream declaration, systemd has no idea what port to open the socket on. It's needed. Run # systemctl start leafnode.socket and # systemctl enable leafnode.socket to start systemd listening for calls for Leafnode immediately and after the next system boot. -- -- ^^ -- Whiskers -- ~~
Re: [arch-general] Leafnode and Systemd
On Tue, Oct 23, 2012 at 12:34:20AM +0100, Whiskers wrote: On Mon, 22 Oct 2012 18:40:23 -0400 Dave Reisner d...@falconindy.com wrote: On Mon, Oct 22, 2012 at 11:19:37PM +0100, Whiskers wrote: Thank you to all those who responded :)) I now have Leafnode-2 up and running smoothly with systemd. I have created these files: $ cat /etc/systemd/system/leafnode.socket [Unit] Description=Leafnode NNTP Socket [Socket] ListenStream=119 Accept=yes [Install] WantedBy=sockets.target and $ cat /etc/systemd/system/leafnode@.service [Unit] Description=Leafnode NNTP service After=syslog.target This isn't needed. syslog is always available thanks to the journal socket. OK. [Service] ExecStart=/usr/local/sbin/leafnode /usr/local? That's where Leafnode-2 puts itself by default. I assumed you were using the package in [community]. StandardInput=socket User=news Access control depends entirely on ufw (iptables), rather than specifying a hostname or IPv6 or IPv4 number in leafnode.socket, although that would Binding to a specifc IP is hardly what I'd call access control. Wouldn't ListenStream=127.0.0.1;119 prevent anyone not logged in to localhost from using Leafnode? Sure. Nit: Would be a colon, not a semi-colon delimiter. probably work instead. The ListenStream line could probably be omitted entirely, unless some port other than 119 is required. Without the ListenStream declaration, systemd has no idea what port to open the socket on. It's needed. Xinetd doesn't need to be told. Isn't there a table of standard ports for specified services? Yes, there's a table of standard ports -- it's /etc/services. It merely lets you refer to ports by name rather than by number. Something still needs to indicate what port to listen on, regardless of how its mentioned. So, I call bull on xinetd not needing to know this. _somehow_ it's being told. d
Re: [arch-general] syslog-ng depends on systemd?
On Sun, Oct 21, 2012 at 07:24:28PM +1000, Allan McRae wrote: On 21/10/12 17:28, gt wrote: Hi, with the recent update of syslog-ng (3.3.6-2), systemd has been added as a dependency. I though systemd providing its own logging and syslog-ng wasn't needed. Then why is systemd needed for syslog-ng to run? As far i can see from the diffs, nothing has changed apart from adding systemd as a dependency. Look in syslog-ng.conf: unix-dgram(/run/systemd/journal/syslog); That means, in its default configuration it requires systemd. Well that, and the linker seems to want systemd as well: $ objdump -p /usr/lib/syslog-ng/libafsocket.so | grep NEEDED NEEDED libsyslog-ng-3.3.6.so NEEDED libsyslog-ng-crypto.so NEEDED libssl.so.1.0.0 NEEDED libcrypto.so.1.0.0 NEEDED libsystemd-daemon.so.0-- o hai NEEDED libpthread.so.0 NEEDED libc.so.6 d
Re: [arch-general] permissions mismatch error while upgrading the system
On Thu, Oct 18, 2012 at 12:46:36PM +1100, Gaetan Bisson wrote: [2012-10-17 15:42:56 -0300] Martín Cigorraga: warning: directory permissions differ on var/lib/nfs/rpc_pipefs/ filesystem: 555 package: 755 The difference between 555 and 755 is write permission for the owner... So it should be completely harmless to chmod that directory to 755. -- Gaetan Pretty sure the idea here is that the permissions in userland reflect what the kernel presents us with for permissions on the filesystem. No user will be able to write to rpc_pipefs, so the filesystem itself is 555. We should change this in the nfs-utils package so that its installed as 555. If you recall, the same thing happened with /sys being mounted as 555 as of kernel 3.4: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c56d8a73 d
Re: [arch-general] Leafnode and Systemd
On Thu, Oct 18, 2012 at 08:26:16PM +0100, Whiskers wrote: On Thu, 18 Oct 2012 00:03:57 +0200 Thomas Bächler tho...@archlinux.org wrote: Am 17.10.2012 21:29, schrieb Whiskers: Rather than install tcp-wrappers on my Arch system, I'd like to use whatever the proper server is nowadays instead of /usr/sbin/tcpd - but what is it? Why would you replace tcpd with anything? Does it serve any purpose at all? Thanks for responding. On a system with tcp-wrappers, tcpd is the server which launches leafnode. From man leafnode: [...] The leafnode program itself is the NNTP server. It is run from /etc/inetd.conf when someone wants to read news. The other parts of the package, fetchnews and texpire, are responsible for fetching new news from another server, and for deleting old news. [...] No network-level access control is supported. This is a deliberate omission: Implementing this is a job which should not be redone for each and every service. I recommend that either firewalling or tcpd be used for access control. [...] Xinetd is the 'new improved' inetd, and the xinetd setup recommended in the Leafnode tarball's README has tcpd as the server and leafnode as the server argument, as in the /etc/xinetd.d/nntp file previously quoted. This of course doesn't work on my Arch system, as tcp-wrappers (and thus, tcpd) is missing. It's quite simple. Get rid of tcpd as the server. It's just a wrapper that launches an arbitrary process which doesn't link to libwrap.so so that tcp-wrappers can be used for ACLs. It isn't a requirement -- it's a recommendation. So I'm trying to work out how to get leafnode available on demand, without using tcp-wrappers and tcpd, but with ufw, and with the new systemd (I've uninstalled initscripts from my system). Use inetd-style activation via systemd. See sshd@.service and sshd.socket as an example. xinetd is redundant. d
Re: [arch-general] Final step before changing to systemd
On Tue, Oct 16, 2012 at 11:10:21AM +0200, Thomas Bächler wrote: Am 16.10.2012 03:56, schrieb Martín Cigorraga: On Mon, Oct 15, 2012 at 10:50 PM, Gaetan Bisson bis...@archlinux.orgwrote: [2012-10-15 22:25:58 -0300] Martín Cigorraga: Basically I need to know how to handle these daemons: hwclock Ditch it. Use NTP instead: I think systemd does hwclock handling in some way. However, you should always run NTP, on every machine, real or virtual. systemd reimplements the bare minimum of hwclock(8) to seal the kernel timezone, as the first call to settimeofday(2) on bootup is special. The userspace timezone used will warp the kernel's clock by a given number of minutes -- this means 0 for UTC, and some non-zero value for localtime (UTC offset in hours * 60). This is an ugly hack, and part of why it's never recommended to run with the BIOS clock in localtime. Any regular adjustment of the hwclock should be handled by an NTP daemon, which can read from an authoritative source. d
Re: [arch-general] Suggestions for email for a paranoid Archer
On Thu, Oct 11, 2012 at 07:49:00PM -0500, sung...@gmail.com wrote: On Thu, Oct 11, 2012 at 02:13:54PM -0400, Dave Reisner wrote: Really, just add two-factor auth to a gmail account and be done with it. Google has no interest in singular people. It should be noted that Gmail's two-factor authentication provides no extra security if you're planning on using it with a mail client. You will have to set up an application specific password, which is a fixed-length alphanumeric password given to you by Google. Despite the name, it is simply another password that can be used to log in via IMAP/POP through any client (`openssl s_connect`, etc), without the out-of-band verification. Sure, what I had in mind was actually to take advantage of it. Disable POP/IMAP access and use OTP with webmail. This is true two factor auth and *does* provide added security. Moreover, Googlers who take an interest in data or logs belonging to singular people find themselves no longer working at Google. This is true, but if you were really very paranoid, you would notice No, if you were really very paranoid, you'd realize that you just need to stay off the Internet. that you don't have any control over how long Google keeps deleted email on the server, and that any unencrypted emails on a server can be obtained by governments with relative ease. Well, I happen to know the retention policies, so this doesn't apply to me. I'll further point out that Google in particular is extremely transparent about what they give out to the government: http://www.google.com/transparencyreport/removals/government/ I'm not sure what you're trying to imply about unencrypted email and government bodies, but it sounds rather silly. Perhaps I don't drink enough koolaid. If you control the server and mailserver, you can encrypt your drive and also have all incoming email encrypted with your public key, so that your mail isn't just sitting around on a box for the taking. Receive encrypted email? How are you going to ensure that this always happens? I suppose you could simply deny anyone who isn't relaying over TLS (and just accept that you're going to miss out on a lot mail), but how do you control the sender's environment? There's equally many things on the sender's side (assuming they're vulnerable) that could potentially implicate you in whatever it is you're trying to hide. To expand on this, how do you control what happens to a message that you forward or write? You need to equally paranoid friends. Neither of these things would stop a truly determined government-level attacker (unencrypted mail is still vulnerable in-flight for instance), but it would be useful if you have not yet been identified as someone of interest. Again, if you're really going to be paranoid, just stay off the Internet. What we have here is an OP who's merely waking up to the realization that the definition of freedom is a bit different between meatspace and cyberspace. d
Re: [arch-general] [arch-dev-public] Changes to postgresql
On Thu, Oct 11, 2012 at 03:43:20PM +0300, Marti Raudsepp wrote: On Thu, Oct 11, 2012 at 2:26 PM, Thomas Bächler tho...@archlinux.org wrote: 1) postgresql expects its configuration files in /usr/etc/postgresql/. It doesn't install any files there by default, so namcap doesn't notice - however, you can copy the sample files from /usr/share/postgresql to this location. This must be fixed by appending --sysconfdir=/etc to the configure options. I think you're wrong about this. PostgreSQL, by default, does not store config files in /etc (or sysconfdir) at all. Configuration files are stored along with everything else in PGDATA (/var/lib/postgres/data)... % sudo -u postgres strace -eopen postgres -D /var/lib/postgres/data 2/tmp/strace.out [...] ^C % egrep '(etc|conf)' /tmp/strace.out open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3 open(/var/lib/postgres/data/postgresql.conf, O_RDONLY) = 3 open(/etc/nsswitch.conf, O_RDONLY|O_CLOEXEC) = 3 open(/etc/host.conf, O_RDONLY|O_CLOEXEC) = 3 open(/etc/resolv.conf, O_RDONLY|O_CLOEXEC) = 3 open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3 open(/etc/hosts, O_RDONLY|O_CLOEXEC) = 3 open(/etc/gai.conf, O_RDONLY|O_CLOEXEC) = 3 open(/etc/hosts, O_RDONLY|O_CLOEXEC) = 8 open(/var/lib/postgres/data/pg_hba.conf, O_RDONLY) = 9 open(/var/lib/postgres/data/pg_ident.conf, O_RDONLY) = 9 No attempted accesses to /usr/etc. Regards, Marti lack of evidence in an strace doesn't absolve the wrong config flag. $ strings /usr/sbin/postgres | grep -F /usr/etc FILE:/usr/etc/postgresql/krb5.keytab /usr/etc/postgresql Feel free to scan any other binary shipped with postgres. Pretty much all of them refer to /usr/etc/postgresql. d
Re: [arch-general] Suggestions for email for a paranoid Archer
On Thu, Oct 11, 2012 at 06:18:10PM +0200, Menachem Moystoviz wrote: Basically, the suggestion I'm seeing here is: go, work, get a VPS - can probably get one for cheap - and setup Arch on it. Sounds good. Will only have to figure out how to get money... Gesh Yes, and then spend the rest of your nights worrying about the security and stability of your own server. Seems like a lovely waste of time and money for someone who, by their own word, has little of each to spend. Really, just add two-factor auth to a gmail account and be done with it. Google has no interest in singular people. Moreover, Googlers who take an interest in data or logs belonging to singular people find themselves no longer working at Google. d
Re: [arch-general] [arch-dev-public] [draft] Install medium 2012.10.06 introduces systemd
On Oct 7, 2012 1:45 PM, Martín Cigorraga m...@archlinux.us wrote: * The following new packages are available on the live system: ethtool, fsarchiver, gummiboot-efi, mc, partclone, partimage, refind-efi, rfkill, sudo, testdisk, wget, xl2tpd +1 fsarchiver! Can I suggest to add tmux on an upcoming release!? Tmux is far from crucial and the ISO has already bloated in size above what I'd like to see it at. Ignoring tmux also sidesteps the evitable holy war of why not screen?
[arch-general] mkinitcpio: mdadm_udev Hook
On 03/10/12, Thomas B?chler wrote: You need to create a file /etc/mdadm.conf. mdadm --examine --scan will generate the right lines for you. This file will be added to the initramfs and your names will be fine again. Yep, that's what I've done, and I've used the mdadm hook as I have in the past. Based on the mkinitcpio wiki page, and the forum post, I'm under the impression that using mdadm_udev to auto-assemble the arrays is what I should be using (and is what will be supported in the future). The mdadm_udev hook does work as advertised, but I don't see how I can use it when I need a known /dev/mdx device for use in something like a cryptdevice= kernel arg. Thomas is pointing out that the mdadm_udev hook will (should?) still honor your /etc/mdadm.conf if it has ARRAY decls in it (you'll see it being picked up on the mkinitcpio run if this is true). If that isn't happening, or it isn't being honored, we should find out why. Alternatively, cryptdevice understands tags, e.g: cryptdevice=UUID=46c78135-8ac0-4928-8b26-5d23a77b1ff1:cryptrewt Of course, since there isn't a filesystem involved, UUID is the only one that makes sense for MBR disks. PARTUUID is also supported, and PARTLABEL support will be available in the next mkinitcpio release. Cheers, Dave
Re: [arch-general] [aur-general] [arch-dev-public] final leg of /lib removal
On Tue, Jul 03, 2012 at 07:56:32PM +0200, Ike Devolder wrote: Op dinsdag 3 juli 2012 11:41:08 schreef Dave Reisner: Hey all, *** If you use a custom kernel, this will affect you. Please read the big scary note at the end *** I'm taking today to work on the last roadblock before Allan can move glibc out of /lib. This basically consists of a rebuild of: - kmod (to drop our local patch) - linux, linux-lts (diff for linux here: http://paste.xinu.at/LLd/) - all OOT kernel modules (for /usr/lib/modules/extramodules-*) - bash-completion (temp patch until /lib is a symlink: http://paste.xinu.at/xEs/) I'll be doing this all locally to avoid building against allan's new toolchain in [staging]. This will hopefully all hit [testing] by the end of the day. You know where to find me if you have any questions or angry rants. If you'd like to do some early testing, I'm leaving the rebuilt kmod and kernel packages on gerolde: http://dev.archlinux.org/~dreisner/linux-usrmove/ (i686 packages are lagging behind at the moment) BIG SCARY NOTE: Due to the kmod changes, this will BREAK all module tools for users with their own kernels. If you do not rebuild your kernel after pulling in the new kmod, you're going to have a bad time. See the paste link above for inspiration. Cheers! Dave I'm replying on this in arch-general and aur-general because i cant post in arch-dev. So if i understand correctly we (the people running custom kernels) can't prepare for this ? I posted the new kmod package here explicitly so that users can get this package in preparation... I'll post it again since I changed the server I'm hosting these on: updated URL: http://pkgbuild.com/~dreisner/linux-usrmove/ There is no way of moving the modules already to /usr/lib ? I assume kmod now only looks in /lib. Currently, kmod is patched to respect config dirs in /usr/lib, but modules in /lib. After removing the patch, it uniformly searches /usr/lib for everything (I'm intentionally ignoring /etc and /run here). Another note, people with custom repositories should move their kernels in sync with the official repositories ? --Ike As with any large change, I'll mention on dev-public when this goes to testing, and there will be an associated news item when it moves to core. I realize this is a harsh change, but I don't really have many options for doing this more smoothly. If you're using the stock kernel, this should all just work. mkinitcpio has supported this setup for months now, and I've had my own kernel in /usr/lib/modules for almost as long. Worst case scenario, users of custom kernels can: - manually move /lib/modules/mycustomkernel to /usr/lib/modules/ until they can do a proper rebuild. - boot a stock -ARCH kernel (you DO have it listed as a fallback, right?) until they can do a proper rebuild. Emphasis on until they can do a proper rebuild. It's important that this all gets done before we introduce a new glibc package that wipes out /lib entirely. If you have custom kernel bits lying around in /lib/modules, it's going to block the eventual glibc upgrade that brings this (no, it won't be immediately with 2.16). dave pgp4cJpmN2Iy4.pgp Description: PGP signature
Re: [arch-general] [aur-general] [arch-dev-public] final leg of /lib removal
On Wed, Jul 04, 2012 at 06:42:09AM +0800, Oon-Ee Ng wrote: On Jul 4, 2012 3:38 AM, Tom Gundersen t...@jklm.no wrote: We all know that no one reads the news items, nor dev-public, so I think adding an extra warning should save us a few hundred mails/forumposts/IRC conversations. -t I see a good opportunity to start pruning the list of users of all the above channels =). The same users who don't read the above may not notice post-upgrade messages either. On the flip side, most custom kernel users should be more savvy than the average, do I don't see much of a problem. I maintain two aur kennels, shall I implement the move now (seems like it'd work even before kmod upgrades)? No, this won't work pre-kmod update. You either read modules from /lib/modules or /usr/lib/modules. Not both.
[arch-general] [mkinitcpio] support for /usr on a separate partition
Hi all, With the release of mkinitcpio 0.8.2, we've added support for mounting /usr from early userspace when it exists as a separate partition. This has been something people have been asking about for a little while, so I figured I'd make a call out for the feature. There's two requirements to make sure this works: 1) Include the shutdown hook in /etc/mkinitcpio.conf. This copies the contents of the initramfs to /run/initramfs during bootstrap and additionally adds a small script (cleverly called shutdown). On shutdown, initscripts will bind mount the API filesystems into /run/initramfs, pivot into this new root, and then unmount the real filesystems from top to bottom. For the time being, this is a fairly dumb process. We don't break down stacked filesystems like LVM or close crypt mappings. I may aim to do for the next release. 2) Include the fsck hook in /etc/mkinitcpio.conf. This needs to go _before_ autodetect if your /usr is a different FS from your root. Neglecting to add the fsck hook will result in bad things. I expect this to change next release and the fsck hook will be smart enough to grab binaries for only root and usr. The fsck hook is highly recommended for everyone, not just those with a separate /usr. Running fsck in early userspace means the device can be checked before it's even mounting -- any and all repairs can be performed without the need for a reboot. With systemd, this pretty much all works the same. The shutdown script is honored, and your root will not be re-fsck'd due to a tell-tale file dropped in /run/initramfs. Happy testing! dave pgpf0yuUEBHZz.pgp Description: PGP signature
[arch-general] [mkinitcpio] release 0.8.0
Hi all, I've tagged mkinitcpio 0.8.0, which came a little earlier than I would have liked, but there's still fun things to talk about. The major point of interest is the addition of fsck functionality. The logic in init is triggered by the addition of the 'fsck' install hook. If added after the autodetect hook, only the necessarily helper for the root FS will be added. Eventually, there may be reason to add fsck prior to this hook, but probably not yet. Operation is hands off until something blows up, at which point we follow similar logic to that of rc.sysinit. I'll explicitly call out that if you're using this hook, make sure you have a useful keyboard -- this probably means adding the usbinput hook. Other than fsck, there's were lot of cleanup efforts in the early userspace init to modularize the functionality, but it generally remains the same. Everything remains largely the same functionally, but I'll point out that if you pass a major/minor pair as your root device or don't use udev, you will likely no longer see root mounted as /dev/root, but as a more descriptive block device. As always, this has stood up to my army of VMs, but nothing's better for finding bugs than real world testing. Thanks for Gerardo and Tom for their contributions to this release. The full shortlog is below. Dave Reisner (15): mkinitcpio: dereference symlinks when resolving kernver update bash completion Makefile: install binaries to /usr/bin init: don't tell the kernel about the path to modprobe init: create /run/initramfs after mounting /run init_functions: refactor poll_device autodetect: store rootfstype for use by other hooks init: use util-linux's /bin/mount init_functions: move root resolution to separate function init_functions: generalize resolve_device init_functions: resolve M:m to device file fsck: implement basic fsck support install/fsck: new install hook to add fsck and helpers init_functions: simplify parse_cmdline use util-linux's switch_root binary Gerardo Exequiel Pozzi (5): hooks/resume: Remove unused function hooks/resume: Remove grep usage init: Remove grep usage init: Remove sed cmd usage init: Remove unneeded test Tom Gundersen (1): add_symlink: fix argument ordering and add_dir call pgpfIy6gYszOK.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] [signoff] vpnc 0.5.3-4
On Sat, Aug 13, 2011 at 11:08:15AM +0200, Thomas Bächler wrote: Fix FS#25002 (add net-tools dep for now), FS#23452 (fix path, add optdepend) and FS#25095 (add supplied patch). Please sign off. I also want to mention that I don't use vpnc anymore, and haven't done so for years. I don't want to keep maintaining it, so if there are takers among the devs, please step up. Anyone else? User signoffs are welcome. I'd like to get this moved to core soon-ish to make way for some more concrete changes, namely: * Updating to an svn tarball which has some lovely bug fixes -- several other distros are packaging trunk. * An updated vpnc-script maintained by David Woodhouse (intel employee and major kernel contributor) [1]. He's added ipv6 support and a few bugfixes as well. I've also sent David a pull request to get rid of the net-tools dependency (at least in Linux) and fix a bug in his updates. d [1] http://git.infradead.org/users/dwmw2/vpnc-scripts.git
[arch-general] iniitcpio root device check
Alright, I did that, but it is still doing the root device check and
dropping into the recovery shell, so I have to press Ctrl-D to
continue.
From /etc/mkinitcpio.conf:
MODULES= # I was putting the modules here, now they are in install/9p
HOOKS=base udev autodetect 9p filesystems
start /lib/initcpio/hooks/9p
run_hook () {
modprobe 9p
modprobe 9pnet
modprobe fscache
modprobe virtio
modprobe virtio_ring
modprobe virtio_pci
modprobe 9pnet_virtio
}
FYI, you can run:
modprobe -a 9p 9pnet fscache ..
and save yourself some forks.
9p_mount_handler() {
mount -t 9p -o ro,${rootflags} $root $1
}
mount_handler=9p_mount_handler
end /lib/initcpio/hooks/9p
start /lib/initcpio/install/9p
#!/bin/bash
build() {
MODULES+= 9p 9pnet fscache virtio virtio_ring virtio_pci 9pnet_virtio
}
help() {
catHELPEOF
This hook allows a 9p virtual filesystem passthrough to be used
as the root filesystem when run qemu KVM.
HELPEOF
}
end /lib/initcpio/install/9p
It does not seem to matter where I put the 9p hook in the HOOKS string
before rebuilding the initcpio images.
Dwight
My fault for suggesting a rotten name. You can't start a function name
with a number.
$ 9p() { echo hi; }
ash: syntax error: bad function name
Parsing failed on sourcing the hook, and mount_handler was never
declared. Rename the function to something that ash plays nicely with
and you should get some joy.
dave
[arch-general] iniitcpio root device check
Ok, I renamed 9p_mount_handler to ninep_mount_handler and updated
mount_handler= accordingly, and rebuild the initcpio images.
Still no joy... :)
I went so far as to rename 9p to ninep in
/lib/initcpio/{install,hooks} and the HOOKS string, and rebuilt the
initcpio images, but that did not help.
Dwight
Let's try this one more time. You're missing a pointer to your install
script. Part of the build function needs:
SCRIPT=ninep
or whatever you're calling it...
d
Re: [arch-general] [arch-dev-public] [signoff] kernel26-2.6.38.3-1
On Apr 21, 2011 6:17 AM, Tom Gundersen t...@jklm.no wrote: On Thu, Apr 21, 2011 at 7:16 AM, Andreas Radke a.ra...@arcor.de wrote: Am Mon, 18 Apr 2011 07:29:20 +0200 schrieb Tobias Powalowski t.p...@gmx.de: yes, i think this is because i enabled printk_time option. Once again somebody request something and we don't think about it and enable it without any need... The configuration item CONFIG_EARLY_PRINTK: CONFIG_PRINTK_TIME is not the same as CONFIG_EARLY_PRINTK. The former is very useful to make sense of dmesg (otherwise you dont know what messages belong together) and it should not have any negative side effects (I have been using it for years). The latter might be, as you say, annoying and should perhaps be removed, it is not new in this release though (it is from before the start of the packages repo)... Cheers, Tom the kconfig for PRINTK_TIME doesn't mention that its only setting a default behavior. The cmdline accepts printk.time= which can be set to 1/0 to appropriately disable or enable. Plus one to removing this as its really only good for debugging and making a mess of your logs. Dave
[arch-general] [systemd] v23 released, heads up
Hey all, A heads up for anyone using systemd, I've just pushed the latest tag to [community-testing]. It's going to be hanging out there until we at least see udev-167. More notably, there's been a fairly silly change [1] in place that will muck up the formatting of log facilities in dmesg and syslog [2] without a kernel patch [3] to accompany it. Understand that this is mostly cosmetic, but for anyone micromanaging their syslogs, this may have an impact unless you backport the patch to your kernel. regards, dave [1] http://cgit.freedesktop.org/systemd/commit/?id=7c3b203c5c69fc37c8d143851cd395cbf8920786 [2] http://sprunge.us/Hcjg [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=9d90c8d9cde929cbc575098e825d7c29d9f45054
[arch-general] util-linux 2.19 release
Attached is a changelog and a PKGBUILD for the recently released
util-linux 2.19. Changes I've made to the PKGBUILD:
- name change: the project is once again called util-linux. I've updated
the conflicts accordingly, and removed the ancient reference to
linux32. I think its worth keeping the versioned conflict with
e2fsprogs.
- remove install scriptlet: this info file is no longer provided
- use autogen.sh script instead of manually invoking autotools
- remove --enable-rdev flag. this has been non-existant since 2.17
- no need to rm stuff in package() -- these files are no longer part of
util-linux
Other thoughts: If we build this with --enable-libmount-mount, we can do
away with /etc/mtab and make it a symlink to /proc/self/mounts. It is,
however, marked as experimental in the release notes.
I've been running the -git version of util-linux for about a month now,
and have had no problems with low level functionality e.g. booting or
mounting.
thanks,
dave
# $Id: PKGBUILD 108823 2011-02-03 20:52:35Z thomas $
# Maintainer: judd jvi...@zeroflux.org
pkgname=util-linux
pkgver=2.19
pkgrel=1
pkgdesc=Miscellaneous system utilities for Linux
url=http://userweb.kernel.org/~kzak/util-linux/;
arch=('i686' 'x86_64')
groups=('base')
depends=('bash' 'ncurses=5.7' 'zlib' 'filesystem')
replaces=('util-linux-ng')
conflicts=('util-linux-ng' 'e2fsprogs1.41.8-2')
license=('GPL2')
options=('!libtool')
source=(ftp://ftp.kernel.org/pub/linux/utils/util-linux/v$pkgver/$pkgname-$pkgver.tar.bz2;)
optdepends=('perl: for chkdupexe support')
md5sums=('590ca71aad0b254e2631d84401f28255')
build() {
cd $srcdir/$pkgname-$pkgver
# relocate hwclock adjustment file
sed -e 's%etc/adjtime%var/lib/hwclock/adjtime%' -i hwclock/hwclock.c
./autogen.sh
./configure --enable-arch --enable-write --enable-raw --disable-wall
--enable-partx
make HAVE_SLN=yes ADD_RAW=yes
}
package() {
cd $srcdir/$pkgname-$pkgver
make HAVE_SLN=yes ADD_RAW=yes DESTDIR=$pkgdir install
install -dm755 ${pkgdir}/var/lib/hwclock
}
Util-linux 2.19 Release Notes (10-Feb-2011)
===
The util-linux-ng project has been renamed back to util-linux.
Release highlights
--
lsblk(8):
- this NEW COMMAND lists information about all or selected block devices in
tree-like format.
partx(8):
- this command has been rewritten to use libblkid for partition tables
parsing. It supports aix, bsd, dos, gpt, mac, minix, sgi, solaris_x86, sun,
ultrix and unixware now.
- supports new command line option --show to list partitions in new format
- prints UUID and name for GPT and mac partitions
findmnt(8):
- supports new command line option --submounts to list all submounts for
selected mountpoint(s)
agetty(8):
- supports new command line options -c and -s to reuse already initialized
tty cflags and existing baud rate
mount(8), umount(8):
- could be linked with libmount (--enable-libmount-mount) to manage userspace
mount options outside /etc/mtab on systems where the file is a symlink to
/proc/mounts. (EXPERIMENTAL)
losetup(8), mount(8):
- uses /sys/dev/block/device/loop/backing_file rather than loopdev ioctls
(requires kernel = 2.6.37)
fsck(8):
- supports new command line option -l to lock whole-disk device by
exclusive flock(2). This option is recommended when more fsck(8) instances
are executed in the same time.
rtcwake(8):
- supports new mode show to print the current RTC alarm time
fstrim(8):
- this NEW COMMAND allows to discard unused blocks on a mounted filesystem
(wrapper for FITRIM ioctl)
swapon(8):
- supports new options discard and nofail
blkid(8):
- low-level probing (-p) returns 8 exit code for ambivalent probing results
libmount:
- include file has been renamed from mount/mount.h to libmount/libmount.h
Re: [arch-general] util-linux 2.19 release
On Sun, Feb 13, 2011 at 08:42:30PM -0500, Dave Reisner wrote: Attached is a changelog and a PKGBUILD for the recently released util-linux 2.19. Changes I've made to the PKGBUILD: - name change: the project is once again called util-linux. I've updated the conflicts accordingly, and removed the ancient reference to linux32. I think its worth keeping the versioned conflict with e2fsprogs. - remove install scriptlet: this info file is no longer provided - use autogen.sh script instead of manually invoking autotools - remove --enable-rdev flag. this has been non-existant since 2.17 - no need to rm stuff in package() -- these files are no longer part of util-linux Other thoughts: If we build this with --enable-libmount-mount, we can do away with /etc/mtab and make it a symlink to /proc/self/mounts. It is, however, marked as experimental in the release notes. I've been running the -git version of util-linux for about a month now, and have had no problems with low level functionality e.g. booting or mounting. thanks, dave Minor amendment to my own PKGBUILD -- the HAVE_SLN and ADD_RAW flags to make are no longer necessary either (in both build and package). And the unmentioned errata: 2.19 provides the functionality needed by systemd for proper fsck operation. dave
Re: [arch-general] [arch-dev-public] Fwd: [arch-dev] [signoff] ppp-2.4.5-2
On Wed, Feb 09, 2011 at 03:26:29PM -0500, Eric Bélanger wrote: Forwarding to public ML. -- Forwarded message -- From: Stéphane Gaudreault steph...@archlinux.org Date: Wed, Feb 9, 2011 at 2:23 PM Subject: [arch-dev] [signoff] ppp-2.4.5-2 To: arch-...@archlinux.org * Rebuild of old package * Tidy up PKGBUILD * Fix build error with recent kernel * Fix permissions on libs Please signoff both as I do not run this pkg. Thanks Stéphane I recall last time there was a new build of ppp around, it came down to user signoffs. In case it comes down to that again, I can still connect to my VPN, so I'll sign off for x86_64. dave
Re: [arch-general] [core/filesystem 2010.10-1 - 2010.12-1] breaks makepkg and firefox
On Sat, Dec 18, 2010 at 05:14:45PM -0300, Martín Cigorraga wrote: Dear devs, guys: I've been struggling for the past three days trying to find what was breaking makepkg [0] script and preventing Firefox to launch. Thanks I do weekly backups of my system I found after trial error -updating one package at a time- the responsable is the core/filesystem package. Is anyone else suffering this? I already tried to look for info in www.archlinux.org/packages but it's not listed there. Should I open a new ticket at the bugtracker? Thanks for any advice. 0. Here are some logs: makepkg output after installing new filesystem 2010.12-1: http://aur.pastebin.com/VzRUu6yN /etc/makepkg.conf (untouched): http://aur.pastebin.com/RnqjbYaX last pacman's log with filesystem 2010.12-1 package installed: http://aur.pastebin.com/rZtXgifP Looks to me like the errors are related to yaourt. makepkg doesn't built in /tmp unless you explicitly tell it to. Make sure /tmp is set with permission 1777 d
Re: [arch-general] [arch-dev-public] [signoff] filesystem 2010.12-1
On Tue, Dec 14, 2010 at 07:25:11PM +0100, Thomas Bächler wrote: Am 14.12.2010 19:02, schrieb Jesse Young: Hopefully I'm not too late. But I think you should know that filesystem depends on iana-etc, which is not in the base group, nor is it on the core install CD. What I would do is to add iana-etc to base/core ISO, which should not hold up this signoff, but if another course of action is taken, it might block this filesystem release from moving to core. It is not on the old core CD(s). Every new core CD will include all packages from core, so there is no problem. It is worth noting, however, that the upstream for iana-etc seems to have disappeared. As to why Arch took these files from an intermediary I'm not sure, but they appear to have been taken from iana itself: http://www.iana.org/assignments/port-numbers http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt d
Re: [arch-general] [arch-dev-public] nilfs-utils moving in core
On Wed, Dec 08, 2010 at 11:18:20AM -0200, Armando M. Baratti wrote: Em 08-12-2010 09:57, Heiko Baums escreveu: Am Tue, 7 Dec 2010 23:25:06 -0500 schrieb Loui Changlouipc@gmail.com: So those packages are affected: e2fsprogs reiserfsprogs btrfs-progs(-unstable) nilfs-utils jfsutils xfsprogs nfs-utils package files === = e2fsprogs already in core reiserfsprogs already in core btrfs-progs(-unstable)124 KB1 MB nilfs-utils79 KB 336 KB jfsutils already in core xfsprogs already in core nfs-utils already in core Armando I highly doubt that this was _ever_ a question of size in the repos. More likely, It's a matter of time vs. gain for a small number of volunteers. If you're a user who knows that they want a particular exotic filesystem that isn't widely used, you the user, on this very day, have the following exciting options including but not limited to: 1) dont use AIF. not to sleight Dieter, but there's more ways to install Arch than just by using AIF. 2) format and mount the partitions yourself, convince AIF that this has been done, and continue installing as you like, with AIF. I've done this before with btrfs, as have others. 3) use Archboot, which supports a wider range of packages. Being the capable and intelligent user who clearly has sufficient reason for wanting such a thing, I'm sure you can think of other ways to accomplish your goal. d
Re: [arch-general] [arch-dev-public] [signoff] pptpclient-1.7.2-3
On Wed, Nov 24, 2010 at 06:04:46PM +1000, Allan McRae wrote: On 19/11/10 23:32, Allan McRae wrote: Rebuild of old package, tidy PKGBUILD, use our CFLAGS/LDFLAGS. Signoff both, This is probably not a very widely used package so user signoff are good here too. Allan Works for me (tm). I can still connect to my VPN and do stuff. dave
Re: [arch-general] [arch-dev-public] [signoff] udev-164-1
On Wed, Nov 24, 2010 at 04:16:55PM +0100, Tobias Powalowski wrote: Hi guys, udev 164 Bugfixes. GUdev moved from /usr to /. - added systemd support - fixed udev.install file - fixed .pc files greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org Is systemd support going to be something that starts gradually making its way into Arch? I'd like to know if this is going to be a new trend so I can plan accordingly (as I'm the maintainer of most things systemd in the AUR). The purist in me would rather see this not happen, as it's somewhat blurring the line between the official repos and the AUR... dave
Re: [arch-general] [arch-dev-public] [signoff] udev-164-1
On Wed, Nov 24, 2010 at 05:02:35PM +0100, Tobias Powalowski wrote: Am Mittwoch 24 November 2010 schrieb Dave Reisner: On Wed, Nov 24, 2010 at 04:16:55PM +0100, Tobias Powalowski wrote: Hi guys, udev 164 Bugfixes. GUdev moved from /usr to /. - added systemd support - fixed udev.install file - fixed .pc files greetings tpowa Is systemd support going to be something that starts gradually making its way into Arch? I'd like to know if this is going to be a new trend so I can plan accordingly (as I'm the maintainer of most things systemd in the AUR). The purist in me would rather see this not happen, as it's somewhat blurring the line between the official repos and the AUR... dave I added the support for you to make your life easier, i have not looked into systemd at all. greetings tpowa Well then, thanks very much! dave
Re: [arch-general] abs [WAS: arch-dev-public] Package maintainers wanted - heimdal, db, abs
On Sat, Nov 06, 2010 at 06:59:20PM +0800, Ng Oon-Ee wrote: Wasn't there a successor or replacement to abs in the works? A git-based one, I believe? (maybe I'm creating false memories?) On Sat, 2010-11-06 at 16:40 +1000, Allan McRae wrote: Perhaps you were thinking of: https://github.com/str1ngs/abs And iirc, there's been at least 2 conversations on this list about switching to git from svn for the packages repo itself. d
Re: [arch-general] New nvidia driver - video mode not recognized - remove vga= from kernel line?
On Fri, Oct 29, 2010 at 07:47:29AM -0500, David C. Rankin wrote: On 10/28/2010 08:57 PM, Dave Reisner wrote: Specify the mode as decimal instead of hex -- in this case it'd be 794. Dave, That worked! Thanks. But, G., what changed to make whatever checks now not like the hex designation? I have used the hex designation for at least a *decade*. I have no idea why this happens, but I came across this myself with my htpc. d
Re: [arch-general] [arch-dev-public] db-5.1 rebuild
On Sat, Oct 30, 2010 at 11:27:48AM +1000, Allan McRae wrote: On 30/10/10 05:59, Andreas Radke wrote: Am Thu, 28 Oct 2010 14:29:54 +1000 schrieb Allan McRaeal...@archlinux.org: We only have the various openoffice packages left to go: go-openoffice openoffice-base openoffice-base-beta openoffice-base-devel That is close enough to done that I will move this rebuild from [staging] at the weekend regardless of their status. Allan Move all to testing and then I'll do the missing rebuilds. LibO will probably also need rebuild. Rebuild is in [testing] now. It appears that libreoffice does not need a rebuild. Allan I wouldn't be too sure about that: $ soffice /usr/lib/ooo-3.3/program/soffice.bin: error while loading shared libraries: libdb-4.8.so: cannot open shared object file: No such file or directory
Re: [arch-general] New nvidia driver - video mode not recognized - remove vga= from kernel line?
On Wed, Oct 27, 2010 at 09:36:52PM -0500, David C. Rankin wrote: Guys, To add to the nvidia issues, after update to the latest driver (nvidia 260.19.12-1) the machine stops during boot due to (Invalid video mode, press enter to see list) Pressing enter then lists the available modes. However, when I enter one of the listed modes, it is rejected and I get prompted again with the (Invalid video mode, press enter to see list). I don't know whether this is a bug, a KMS thing, or what, but I have never had any problems passing vga=0x31a on the kernel line with the nvidia driver before. (I know with ATI, KMS early is recommended, and no vga= on the kernel line) Is anybody else seeing this? Should I just remove the vga= line? After letting the (Invalid video mode, press enter to see list) prompt time-out, it all continues fine and the nvidia driver loads without issue. What say the experts? Specify the mode as decimal instead of hex -- in this case it'd be 794. dave reisner
Re: [arch-general] [PATCH] rc.sysinit: only call modprobe once
On Mon, Sep 20, 2010 at 05:39:25PM +0200, Kurt J. Bosch wrote:
2010-09-20 04:10, Dave Reisner:
On Mon, Sep 20, 2010 at 11:57:06AM +1000, Allan McRae wrote:
On 20/09/10 11:54, Dave Reisner wrote:
Use modprobe -a and a bash PE to filter the MODULES array.
Signed-off-by: Dave Reisnerd...@falconindy.com
---
rc.sysinit | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..4b6e1e7 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,14 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd/dev/null; then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off -f /proc/modules ]]; then
-stat_busy Loading Modules
-for mod in ${modul...@]}; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
-done
-stat_done
+if [[ $load_modules != off -f /proc/modules ]] (( ${#modul...@]}
0 )); then
+ stat_busy Loading Modules
+ /sbin/modprobe -a ${modul...@]/#\!*/}
+ stat_done
fi
# Wait for udev uevents
Does this still work in the null case where there is only modules
specified with ! in the front?
Allan
Excellent observation -- it would not. Counting the size of the array
with the PE in place isn't possible (or desirable), either. Perhaps a
more graceful solution is to reassign the output of the PE to a new
array and operate based on that. Certainly still beats calling modprobe
for every element in the array, imo.
d
I think it could be done like so:
From 6465c90fc851b12cfce791228415ae1c2823e050 Mon Sep 17 00:00:00 2001
From: Kurt J. Bosch kjb-temp-2...@alpenjodel.de
Date: Mon, 20 Sep 2010 17:31:54 +0200
Subject: [PATCH] rc.sysinit: only call modprobe once (as proposed by
Dave Reisner)
---
rc.sysinit |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..07b3f67 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,13 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd /dev/null; then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off -f /proc/modules ]]; then
+modules=$( echo ${MODULES[*]/\!*/} )
+if [[ $modules $load_modules != off -f /proc/modules ]]; then
stat_busy Loading Modules
-for mod in ${modul...@]}; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
-done
+/sbin/modprobe -a $modules
stat_done
fi
--
1.7.0.3
Your echo is redundant. Just quote the expansion and assign it.
modules=${modul...@]/#\!*}
I think we're a long way away from the day when there's a '!' as
part of a module name, but I think it's probably best to anchor the
expression to the start of each element regardless.
d
Re: [arch-general] [PATCH] rc.sysinit: only call modprobe once
Your echo is redundant. Just quote the expansion and assign it.
NAK. Try this:
MODULES=( '!foo' '!bar' )
modules=${modul...@]/#\!*}
[[ $modules ]] echo '$modules' is not a null string
' ' is not a null string
modules=${modul...@]/#\!*}
I think we're a long way away from the day when there's a '!' as
part of a module name, but I think it's probably best to anchor the
expression to the start of each element regardless.
OK, but the quotes aren't needed because word splitting is not
performed here. So we finally get:
modules=$( echo ${modul...@]/#\!*} )
--
Kurt
We're going to have to agree that we're both right, and we're both
wrong. The echo is _still_ unnecessary. I've learned to quote everything in
bash, and now it's working against me.
$ MODULES=( '!foo' '!bar' )
$ modules=${modul...@]/#\!*/}
$ [[ -z $modules ]] echo null
null
d
[arch-general] [PATCH] rc.sysinit: only call modprobe once
Use modprobe -a and a bash PE to filter the MODULES array.
Signed-off-by: Dave Reisner d...@falconindy.com
---
rc.sysinit |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..07180d0 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -94,11 +94,7 @@ fi
# Load modules from the MODULES array defined in rc.conf
if [[ $load_modules != off -f /proc/modules ]]; then
stat_busy Loading Modules
-for mod in ${modul...@]}; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
-done
+/sbin/modprobe -a ${modul...@]/\!*/}
stat_done
fi
--
1.7.2.3
Re: [arch-general] [PATCH] rc.sysinit: only call modprobe once
On Sun, Sep 19, 2010 at 08:47:03PM -0400, Dave Reisner wrote:
Use modprobe -a and a bash PE to filter the MODULES array.
Signed-off-by: Dave Reisner d...@falconindy.com
---
rc.sysinit |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..07180d0 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -94,11 +94,7 @@ fi
# Load modules from the MODULES array defined in rc.conf
if [[ $load_modules != off -f /proc/modules ]]; then
stat_busy Loading Modules
-for mod in ${modul...@]}; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
-done
+/sbin/modprobe -a ${modul...@]/\!*/}
stat_done
fi
--
1.7.2.3
Seems I've forgotten about the null case here. Disregard this, I'll
resend.
[arch-general] [PATCH] rc.sysinit: only call modprobe once
Use modprobe -a and a bash PE to filter the MODULES array.
Signed-off-by: Dave Reisner d...@falconindy.com
---
rc.sysinit | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..4b6e1e7 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,14 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd /dev/null; then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off -f /proc/modules ]]; then
-stat_busy Loading Modules
-for mod in ${modul...@]}; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
-done
-stat_done
+if [[ $load_modules != off -f /proc/modules ]] (( ${#modul...@]} 0 ));
then
+ stat_busy Loading Modules
+ /sbin/modprobe -a ${modul...@]/#\!*/}
+ stat_done
fi
# Wait for udev uevents
--
1.7.2.3
Re: [arch-general] [PATCH] rc.sysinit: only call modprobe once
On Mon, Sep 20, 2010 at 11:57:06AM +1000, Allan McRae wrote:
On 20/09/10 11:54, Dave Reisner wrote:
Use modprobe -a and a bash PE to filter the MODULES array.
Signed-off-by: Dave Reisnerd...@falconindy.com
---
rc.sysinit | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..4b6e1e7 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,14 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd/dev/null; then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off -f /proc/modules ]]; then
-stat_busy Loading Modules
-for mod in ${modul...@]}; do
-if [[ $mod = ${mod#!} ]]; then
-/sbin/modprobe $mod
-fi
-done
-stat_done
+if [[ $load_modules != off -f /proc/modules ]] (( ${#modul...@]} 0
)); then
+stat_busy Loading Modules
+/sbin/modprobe -a ${modul...@]/#\!*/}
+stat_done
fi
# Wait for udev uevents
Does this still work in the null case where there is only modules
specified with ! in the front?
Allan
Excellent observation -- it would not. Counting the size of the array
with the PE in place isn't possible (or desirable), either. Perhaps a
more graceful solution is to reassign the output of the PE to a new
array and operate based on that. Certainly still beats calling modprobe
for every element in the array, imo.
d
Re: [arch-general] Adobe Releases New 64-bit Flash Plugin For Linux
On Thu, Sep 16, 2010 at 09:14:22AM -0300, Denis A. Altoé Falqueto wrote: On Thu, Sep 16, 2010 at 9:10 AM, Rafael Beraldo rafaelluisbera...@gmail.com wrote: You may have seen this, however it is interesting to spread the word: http://linux.slashdot.org/story/10/09/16/0340226/Adobe-Releases-New-64-bit-Flash-Plugin-For-Linux http://linux.slashdot.org/story/10/09/16/0340226/Adobe-Releases-New-64-bit-Flash-Plugin-For-LinuxI hope this comes to the repositories soon…it is kind of sad, though, 'cause a great deal of people (including me) might use [multilib] just because of Flash. It is in AUR already. http://aur.archlinux.org/packages.php?ID=32072. As it is only a prerelease, it shouldn't be in the repos, though. The former 64-bit flash plugin was never anything but a pre-release. d
Re: [arch-general] nfs4: access denied by server while mounting....
On Mon, Sep 13, 2010 at 02:50:06PM +0100, Ananda Samaddar wrote: I'm tearing my hair out over this one. I'm trying to export some directories using nfs. I've read the Arch Wiki and even been on the IRC channel but I can't fix this bloody problem. I have a desktop and a laptop both running Arch. The desktop is the server and the laptop the client. I'm using MAC-DHCP address reservation so the desktop has a static ip of 192.168.1.3 and the laptop 192.168.1.4. Here are the relevant configs: SERVER /etc/exports: /home/ananda/ 192.168.1.4(ro,fsid=0,no_subtree_check,async,nohide) /home/ananda/Music 192.168.1.4(ro,no_subtree_check,async,nohide) /etc/hosts.allow: nfsd: 192.168.1.4 rpcbind: 192.168.1.4 mountd: 192.168.1.4 I then start, rpcbind, nfs-common and nfs-server in order on the sever. CLIENT /etc/hosts.allow: rpcbind: 192.168.1.3 I then start rpcbind and nfs-common in that order on the client. There are no firewalls or iptables rules on the desktop and laptop as I'm behind a NAT and I'm lazy. The domain names in /etc/idmapd.conf are identical on both client and server too. When I try the command: mount -t nfs4 192.168.1.3:/home/ananda /mnt/shares I get the error message: mount.nfs4: access denied by server while mounting 192.168.1.3:/home/ananda The error is the same if I try nfs as the type. I've also run showmount on the client and the server at 192.168.1.3 shows the correct exports. I have no idea what's wrong. I've check and double checked everything. Any help will be appreciated. thanks, Ananda You declared /home/ananda as fsid=0, so just mount 192.168.1.3: without specifying a path. d
Re: [arch-general] [PATCH] Ignore empty lines when grepping host's mirrorlist
On Sat, Sep 11, 2010 at 01:46:48AM +0300, Evangelos Foutras wrote:
---
mkarchroot |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mkarchroot b/mkarchroot
index fe436f7..5cb9a0f 100755
--- a/mkarchroot
+++ b/mkarchroot
@@ -73,7 +73,7 @@ if [ -z $cache_dir ]; then
fi
if [ -f /etc/pacman.d/mirrorlist ]; then
- host_mirror=$(grep -v '^#' -m1 /etc/pacman.d/mirrorlist | sed -E
's#/os/(i686|x86_64)#/os/\$arch#g')
+ host_mirror=$(grep -E -v '^(#|$)' -m1 /etc/pacman.d/mirrorlist | sed -E
's#/os/(i686|x86_64)#/os/\$arch#g')
fi
if [ -z ${host_mirror} ]; then
host_mirror='Server =
http://mirrors.kernel.org/archlinux/$repo/os/$arch'
--
1.7.2.3
Keep in mind this will still catch a line that only has spaces in it. I
would suggest using the pattern '^[\t ]*(#|$)' instead to avoid this.
d
Re: [arch-general] [PATCH] Ignore empty lines when grepping host's mirrorlist
On Sat, Sep 11, 2010 at 02:55:40AM +0300, Evangelos Foutras wrote:
On Sat, Sep 11, 2010 at 1:59 AM, Dave Reisner d...@falconindy.com wrote:
On Sat, Sep 11, 2010 at 01:46:48AM +0300, Evangelos Foutras wrote:
---
mkarchroot | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mkarchroot b/mkarchroot
index fe436f7..5cb9a0f 100755
--- a/mkarchroot
+++ b/mkarchroot
@@ -73,7 +73,7 @@ if [ -z $cache_dir ]; then
fi
if [ -f /etc/pacman.d/mirrorlist ]; then
- host_mirror=$(grep -v '^#' -m1 /etc/pacman.d/mirrorlist | sed -E
's#/os/(i686|x86_64)#/os/\$arch#g')
+ host_mirror=$(grep -E -v '^(#|$)' -m1 /etc/pacman.d/mirrorlist | sed
-E 's#/os/(i686|x86_64)#/os/\$arch#g')
fi
if [ -z ${host_mirror} ]; then
host_mirror='Server =
http://mirrors.kernel.org/archlinux/$repo/os/$arch'
--
1.7.2.3
Keep in mind this will still catch a line that only has spaces in it. I
would suggest using the pattern '^[\t ]*(#|$)' instead to avoid this.
d
Now that I think about it, maybe it would be best to just grep for
'^Server' instead of discarding irrelevant lines. :p
Even better! Well played.
d
[arch-general] [PATCH] rc.sysinit: condense calls to mkdir and chmod
---
rc.sysinit |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index f7df48c..bee4efb 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -276,8 +276,7 @@ stat_busy Removing Leftover Files
: | /var/run/utmp
/bin/chmod 0664 /var/run/utmp
# Keep {x,k,g}dm happy with xorg
-/bin/mkdir /tmp/.ICE-unix /bin/chmod 1777 /tmp/.ICE-unix
-/bin/mkdir /tmp/.X11-unix /bin/chmod 1777 /tmp/.X11-unix
+/bin/mkdir -m1777 /tmp/.{X11,ICE}-unix
stat_done
#status Updating Shared Library Links /sbin/ldconfig
--
1.7.2.3
Re: [arch-general] [PATCH 01/48] Bashification of initscripts
On Tue, Sep 07, 2010 at 09:51:59PM -0500, Victor Lowther wrote:
On Tue, Sep 7, 2010 at 3:32 PM, Thomas Bächler tho...@archlinux.org wrote:
Am 30.06.2010 23:47, schrieb Victor Lowther:
Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
Bashifying this framework should result in about a 30% speedup, assuming no
IO latency and that all programs we call also take zero time. :)
I just pushed the patches - I was going to do more review of some of
them, but I am apparently too busy. Please post any patches (especially
if a correction of patch 21 is needed, I haven't finished reading the
discussion) rebased on the current initscripts.git.
Your last patch has a typo (missed close paren):
-snip-
There's a typo in the network script from commit a334b36b:
diff --git a/network b/network
index 20ff9c7..5abb824 100755
--- a/network
+++ b/network
@@ -96,7 +96,7 @@ rtup()
rtdown()
{
-if [[ ! $1 ]; then
+if [[ ! $1 ]]; then
echo usage: $0 rtdown route_name
return 1
fi
Re: [arch-general] [PATCH 01/48] Bashification of initscripts
On Tue, Sep 07, 2010 at 10:32:28PM +0200, Thomas Bächler wrote: Am 30.06.2010 23:47, schrieb Victor Lowther: Despite efforts to make the initscripts POSIX, we use bash 4.0 features. Bashifying this framework should result in about a 30% speedup, assuming no IO latency and that all programs we call also take zero time. :) I just pushed the patches - I was going to do more review of some of them, but I am apparently too busy. Please post any patches (especially if a correction of patch 21 is needed, I haven't finished reading the discussion) rebased on the current initscripts.git. I'm noticing that in general, the vim modelines aren't followed. Not sure what editor was used to rebase these scripts, but the mix of tabs and spaces for indents is somewhat irritating. I'm about to send a pair of patches (neither of which address this) but which follow the modeline. d
[arch-general] [PATCH 1/2] kill_everything: Reduce number of -f tests
Instead of checking for the existance of a file in /var/run/daemons on
every iteration, handle the null case by setting nullglob. The shopt
call is done inside a subshell as to not bother the environment since we
may be going to runlevel 1 only temporarily.
---
functions |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/functions b/functions
index b9ba718..7a0c4f8 100644
--- a/functions
+++ b/functions
@@ -206,11 +206,13 @@ kill_everything() {
# $1 = where we are being called from.
# This is used to determine which hooks to run.
# Find daemons NOT in the DAEMONS array. Shut these down first
+(
+shopt -s nullglob
for daemon in /var/run/daemons/*; do
-[[ -f $daemon ]] || continue
daemon=${daemon##*/}
in_array $daemon ${daemo...@]} || stop_daemon $daemon
done
+)
# Shutdown daemons in reverse order
for ((i=${#daemo...@]}-1; i=0; i--)); do
--
1.7.2.3
[arch-general] [PATCH 2/2] rc.sysinit: Reduce number of calls to /bin/rm
Take full advantage of /bin/rm accepting multiple arguments. We still
use two calls to separate the recursive from the non-recursive call.
---
rc.sysinit |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index b25f7ac..0af84de 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -270,11 +270,8 @@ if [[ -f $RANDOM_SEED ]]; then
fi
stat_busy Removing Leftover Files
-/bin/rm -f /etc/nologin /dev/null
-/bin/rm -f /etc/shutdownpid /dev/null
-/bin/rm -f /var/lock/* /dev/null
+/bin/rm -f /etc/{nologin,shutdownpid} /var/lock/* /forcefsck /dev/null
/bin/rm -rf /tmp/* /tmp/.* /dev/null
-/bin/rm -f /forcefsck /dev/null
[[ -d /var/run ]] /usr/bin/find /var/run/ \! -type d -delete )
: | /var/run/utmp
/bin/chmod 0664 /var/run/utmp
--
1.7.2.3
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
On Wed, Sep 01, 2010 at 07:30:45PM +0200, Kurt J. Bosch wrote: 2010-09-01 13:03, Dave Reisner: The _current_ behavior doesn't define an order unless its in DAEMONS. I've reverted _your_ behavior, which I don't feel has proper justification. I referred to extras/initscripts which indeed does. Please read the code: http://projects.archlinux.org/initscripts.git/tree/rc.shutdown?id=2010.07-1 Indeed, I was mistaken. However, I still stand by the idea that trying to parse the output of /bin/ls is flawed from the ground up. ls is made for human parsing, not programatical parsing. Suppose I start daemons foo, bar and baz (in that order) after Arch boots. Why then, should the shutdown order of these daemons change merely because I had to restart bar, which is independent of foo and baz? Because you know which is the right order and rc.shutdown just rolls back what you did. ^^ No, rc.shutdown does _not_ know the right order. The current behavior is broken. Example: 1) start network 2) start rpcbind 3) start nfs-common 4) restart network network now shuts down first, rendering the OS unable to cleanly close any outstanding nfs shares. This commonly results in a long hang at shutdown and the possibility of truncated files. d
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
On Thu, Sep 02, 2010 at 01:53:20AM +0200, Kurt J. Bosch wrote: 2010-09-01 22:52, Dave Reisner: On Wed, Sep 01, 2010 at 07:30:45PM +0200, Kurt J. Bosch wrote: 2010-09-01 13:03, Dave Reisner: The _current_ behavior doesn't define an order unless its in DAEMONS. I've reverted _your_ behavior, which I don't feel has proper justification. I referred to extras/initscripts which indeed does. Please read the code: http://projects.archlinux.org/initscripts.git/tree/rc.shutdown?id=2010.07-1 Indeed, I was mistaken. However, I still stand by the idea that trying to parse the output of /bin/ls is flawed from the ground up. ls is made for human parsing, not programatical parsing. Suppose I start daemons foo, bar and baz (in that order) after Arch boots. Why then, should the shutdown order of these daemons change merely because I had to restart bar, which is independent of foo and baz? Because you know which is the right order and rc.shutdown just rolls back what you did. ^^ No, rc.shutdown does _not_ know the right order. The current behavior is broken. Example: 1) start network 2) start rpcbind 3) start nfs-common 4) restart network network now shuts down first, rendering the OS unable to cleanly close any outstanding nfs shares. This commonly results in a long hang at shutdown and the possibility of truncated files. That's exactly what I meant. _You_ should now what you're doing and rc.shutdown tries its best afterwards. There is no real daemons dependency handling in Arch (probably because of KISS) so we can't expect it does always the right thing, but at least without the restart it would do in your example and that's better than nothing (random order) isn't it? :) Isn't the KISS solution just to add the thing to the DAEMONS array? We're clearly in disagreement, and this is getting a little circular. I'm going to bow out from this gracefully -- the devs can resolve this as they see fit.
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
On Tue, Aug 31, 2010 at 10:07:52AM +0200, Kurt J. Bosch wrote:
--snip--
I suggest:
From b202be97f8dc1c0c68aaea792d4457c674c673f3 Mon Sep 17 00:00:00 2001
From: Kurt J. Bosch kjb-temp-2...@alpenjodel.de
Date: Tue, 31 Aug 2010 09:57:47 +0200
Subject: [PATCH 17/17] Correct behaviour of kill_everything()
---
functions | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/functions b/functions
index b9ba718..3ca7324 100644
--- a/functions
+++ b/functions
@@ -205,10 +205,9 @@ ck_status() {
kill_everything() {
# $1 = where we are being called from.
# This is used to determine which hooks to run.
-# Find daemons NOT in the DAEMONS array. Shut these down first
-for daemon in /var/run/daemons/*; do
-[[ -f $daemon ]] || continue
-daemon=${daemon##*/}
+# Find daemons NOT in the DAEMONS array.
+# Shut these down first in reverse order.
+for daemon in $( /bin/ls -t /var/run/daemons ); do
in_array $daemon ${daemo...@]} || stop_daemon $daemon
done
@@ -220,7 +219,7 @@ kill_everything() {
# Terminate all processes
stat_busy Sending SIGTERM To Processes
-run_hook $1_prekillall
+run_hook ${1}_prekillall
/sbin/killall5 -15 /dev/null
/bin/sleep 5
stat_done
@@ -230,7 +229,7 @@ kill_everything() {
/bin/sleep 1
stat_done
-run_hook $1_postkillall
+run_hook ${1}_postkillall
}
activate_vgs() {
--
1.7.0.3
Parsing the output of ls will never be better than using shell globbing
no matter how much simpler it might make the code appear to be. Not only
are you avoiding a fork, but the shell glob will properly handle any odd
characters thrown into the mix. You'll see breakage on something as
simple as a space in your suggestion. While I'm inclined to believe that
there will never be a space in the name of a daemon in Arch, if we're
going for pure Bash in this rewrite, let's use Bash instead of
mindlessly forking.
The only useful change here is to remove the line:
[[ -f $daemon ]] || continue
and instead call 'shopt -s nullglob' outside the loop. Sorry for the
no-patch patch.
d
Re: [arch-general] Vala out of date
On Fri, Aug 27, 2010 at 06:09:27PM +0200, Andre Osku Schmidt wrote: On Fri, Aug 27, 2010 at 5:39 PM, Jackson Alley toomanymirr...@gmail.com wrote: On 08/27/2010 11:27 AM, Ionuț Bîru wrote: On 08/27/2010 06:23 PM, Jackson Alley wrote: The vala package is several versions out of date and some packages now depend on the .9 branch like shotwell. Here's an updated PKGBUILD: http://dpaste.com/234866/ Jackson for the 99 time, vala 0.9.x is the devel branch and i'm not going to update it. shotwell was updated to 0.7 and vala 0.9.5 is a _makedepends_ not a depends for this app My apologies, my googling didn't turn up this prior discussion and the phrasing on the vala homepage (http://live.gnome.org/Vala/Release) lables the 0.9.x version as releases not a development branch. Jackson hehe, i was one of those 99 too. and there seems to be a secret versioning schema that all gnome projects follow: odd numbers are unstable and even are stable. but yeah, i never found this definition on the gnome site neither... Section 3.1 of the link below mentions it. http://developer.gnome.org/gep/gep-4.html Not the most visible location for it, but given that its organization wide, it doesn't make sense to be mentioned for each individual project either. d
Re: [arch-general] rc.conf man page
On Mon, Aug 23, 2010 at 05:37:29PM -0400, David Campbell wrote: Excerpts from Dave Reisner's message of 2010-08-23 14:59:11 -0400: *ROUTES (array)*:: A list of routes to be created. For each item in this list, the 'network' service expects to find a variable of the same name to exist providing a string of parameters to be passed to the 'route' command in order to create the route. Routes can prevented from being created by prefixing with a '!' symbol. For a variable to be found it must exist, so to exist is redundant. Fixed on my copy. The last sentence should read, Routes can be..., not Routes can prevented..., or better yet, Prevent a route from being created by prefixing it with a bang (!).. Also fixed, and I like your rewording. I like this manpage, although, I am not so sure it is wise to have a manpage for rc.conf. rc.conf is well commented, and if there is a manpage, the two will have to be kept in sync with each other. Having the code with the documentation also makes understanding the documentation easier. I suggest either adding to the comments in rc.conf if they are not sufficient, or leaving out of the manpage information that can already be found in rc.conf. My concern is that /etc/rc.conf is mutable, while a man page is not. AIF uses this commenting as guidance, but it (as well as rc.conf itself) could just as easily say refer to the man page. d
[arch-general] rc.conf man page
I threw together a man page for rc.conf based on info gleaned from the Wiki, rc.conf itself, and my own experiences. I offer it up for for adoption into the initscripts package along with comments, critcisms, and rotten tomatoes. The format is asciidoc, which is the same format used by pacman. If desirable, I'm willing to compile other pages for system config files in a similar manner. d / vim:set ts=4 sw=4 syntax=asciidoc noet: / rc.conf(5) == Name rc.conf - core system configuration file Synopsis rc.conf Description --- This manual page is meant to describe the fields defined in /etc/rc.conf. Localization *LOCALE*:: This sets your system language, which will be used by all i18n-friendly applications and utilities. You can get a list of the available locales by running locale -a from the command line. This setting's default is fine for US English users. *HARDWARECLOCK*:: Specifies whether the hardware clock, which is synchronized from on bootup and to on shutdown, stores UTC time, or the localtime. UTC makes sense because it greatly simplifies changing timezones and daylight savings time. localtime is necessary if you dual boot with an operating system that only stores localtime to the hardware clock, such as Windows. *TIMEZONE*:: Specifies your time zone. Possible time zones are the relative path to a zoneinfo file starting from the directory /usr/share/zoneinfo. For example, a German timezone would be Europe/Berlin, which refers to the file /usr/share/zoneinfo/Europe/Berlin. *KEYMAP*:: The layout describing your keyboard. This defaults to qwerty. Available keymaps are in /usr/share/kbd/keymaps. Note that this setting has no effect in X. *CONSOLEFONT*:: Defines the console font to load with the setfont program on boot-up (e.g. ter-v14b). Available fonts are in /usr/share/kbd/consolefonts. *CONSOLEMAP*:: Defines the console map to load with the setfont program on boot-up (8859-1_to_uni for example). Available maps are found in /usr/share/kbd/consoletrans. You will want to set this to a map suitable for your locale (8859-1 for Latin1, for example) if you use an utf8 locale above and use programs that generate 8-bit output. Note that this setting has no effect in X. *USECOLOR*:: Set to 'yes' or 'no'. Enable (or disable) colorized status messages during bootup and when starting/stopping daemons. Hardware *MOD_AUTOLOAD*:: Set to 'yes' or 'no'. If set to 'yes', your hardware will be scanned at boot time by udev and the appropriate kernel modules will be loaded. *MODULES (array)*:: Explicit list of modules to be loaded or blacklisted during bootup. This can be defined in addition to setting MOD_AUTOLOAD as 'yes' and *must* be defined if MOD_AUTOLOAD is set to 'no'. To blacklist a module, prefix it with a '!' symbol. *USELVM*:: Set to 'yes' or 'no'. If you use LVM, set this to 'yes'. Networking -- *HOSTNAME*:: Sets of the hostname of the machine. *INTERFACES (array)*:: A list of network interfaces, specified by their kernel name (e.g. eth0). For each interface in this list, the 'network' service expects a variable of the same name to exist providing either a parameter string for initialization, or 'dhcp'. Interfaces can be prevented from starting by prefixing with a '!'. Example: eth0=eth0 192.168.0.10 netmask 255.255.255.0 broadcast 192.168.1.255 eth1=dhcp INTERFACES=(eth0 !eth1) *ROUTES (array)*:: A list of routes to be created. For each item in this list, the 'network' service expects to find a variable of the same name to exist providing a string of parameters to be passed to the 'route' command in order to create the route. Routes can prevented from being created by prefixing with a '!' symbol. Example: gateway=default gw 192.168.0.1 ROUTES=(gateway) Daemons --- *DAEMONS (array)*:: A list of daemons to be started by 'rc.multi'. Daemons are started *in the order listed* and shutdown in reverse order. Each entry must have a corresponding script existing in '/etc/rc.d'. To start a daemon in the background, prefix it with a '@' symbol. To prevent a daemon from being started, prefix it with a '!' symbol.
Re: [arch-general] Colorized Output Listing
On Fri, Aug 20, 2010 at 07:53:17PM +0600, reflexing wrote: Guys, does ArchLinux source ~/.profile file? If not, why? I better prefer to set i.e. aliases for all my shells, not only BASH… -- Jabber: reflex...@reflexing.ru, ICQ: 8163230, Skype on demand. Read the INVOCATION section of bash(1). d
Re: [arch-general] Colorized Output Listing
On Fri, Aug 20, 2010 at 10:03:30AM -0400, Dave Reisner wrote: On Fri, Aug 20, 2010 at 07:53:17PM +0600, reflexing wrote: Guys, does ArchLinux source ~/.profile file? If not, why? I better prefer to set i.e. aliases for all my shells, not only BASH… -- Jabber: reflex...@reflexing.ru, ICQ: 8163230, Skype on demand. Read the INVOCATION section of bash(1). d Er, that is to say.. it has nothing to do with your distro. Sourcing files out of your home directory is reliant on the shell. d
Re: [arch-general] Colorized Output Listing
On Fri, Aug 20, 2010 at 08:07:02PM +0600, reflexing wrote: On Fri, Aug 20, 2010 at 8:04 PM, Dave Reisner d...@falconindy.com wrote: On Fri, Aug 20, 2010 at 10:03:30AM -0400, Dave Reisner wrote: On Fri, Aug 20, 2010 at 07:53:17PM +0600, reflexing wrote: Guys, does ArchLinux source ~/.profile file? If not, why? I better prefer to set i.e. aliases for all my shells, not only BASH… -- Jabber: reflex...@reflexing.ru, ICQ: 8163230, Skype on demand. Read the INVOCATION section of bash(1). d Er, that is to say.. it has nothing to do with your distro. Sourcing files out of your home directory is reliant on the shell. d It worked for me in RHEL but didn't worked in ArchLinux, please confirm. -- Jabber: reflex...@reflexing.ru, ICQ: 8163230, Skype on demand. Since you didn't read the man page, I'll quote it here for you: When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes com‐ mands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.pro‐ file, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior. Short form: if .bash_profile and/or .bash_login exist, .profile will never be read. Again, this is all distro agnostic. d
Re: [arch-general] Colorized Output Listing
On Thu, Aug 19, 2010 at 08:43:29PM -0400, Carlos Mennens wrote: It's very frustrating in Arch that my directories[blue], text files[white], tarballs[red], symbolic links[blue], and scripts[green] are all the same color. How can I colorize this in bash so my Arch Linux system is much easier to sort through? I checked the Wiki and only found something about colorizing my PS1 which is not what I really care about. Thanks for any help... Make yourself a dircolors file. Maybe this'll get you started: http://github.com/falconindy/dotfiles/blob/master/.dircolors d
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
On Thu, Aug 19, 2010 at 02:34:50PM +1000, Allan McRae wrote:
On 19/08/10 14:23, Victor Lowther wrote:
I am missing the difference. Diff please?
Yours:
+ /bin/mknod /dev/rtc c $major $minor
His:
/bin/mknod /dev/${dev##*/} c $major $minor
Yours creates /dev/rtc and his creates /dev/rtc and /dev/rtc0
Allan
Couldn't we avoid all this by just flipping a switch in the kernel?
CONFIG_RTC_DRV_CMOS=y
If it's compiled into the kernel, udev picks it up and creates the /dev
nodes for us.
d
Re: [arch-general] script to reformat 'pacman -Ss' output into 2 readable columns (prevents blindness)
On Thu, Aug 05, 2010 at 10:51:45PM -0500, David C. Rankin wrote:
Guys,
I developed a script...
Hi.
Let's see what we can do about cutting back a little on the verbosity,
and upping the utility...
-
#!/bin/bash
pkg=()
desc=()
count=-1
WIDTH=${WIDTH:-50}
while read line; do
if [[ $line =~ ^(testing|core|extra|community|community-testing)/* ]]; then
(( count++ ))
pkg[count]=$line
continue
fi
desc[count]+=$line
done
i=0
while (( i = count )); do
IFS=$'\n' read -r -d'\0' -a blockdesc (fmt -w$WIDTH ${desc[i]})
paste -d' ' (printf %-49s ${pkg[i]}) (echo ${blockdesc[0]})
for line in ${blockde...@]:1}; do
printf %-50s%s\n $line
done
(( ++i ))
[[ $1 == -d ]] echo
done
-
It takes STDIN, and accepts a -d option to add a space after each
package. Descriptions have a default width of 50 characters (meaning a
total width of 100 characters). You can alter this by specifying WIDTH
as an environment var, e.g.
$ pacman -Ss | WIDTH=30 ./foofilter -d
Personally I think pacman-color is a better solution that mangling the
output like this, but to each their own.
d
Re: [arch-general] [arch-announce] Forum Update in Progress
On Fri, Jul 30, 2010 at 10:51:15AM +0100, Peter Lewis wrote: On Friday 30 Jul 2010 at 02:01 Arch Linux: Recent news updates: Allan McRae wrote: The update of our forum software to FluxBB 1.4 is currently in progress and may take a few more hours. Now it's done, the fonts are all big! Is it just my eyes, or can they be made smaller again (the fonts, not my eyes)? Thanks :-) Pete. Simply awesome. FluxBB somehow managed to make itself look even better. Thanks for taking the time to do this upgrade, Pierre. d
[arch-general] Clarfication request regarding mkinitcpio code
There's a few things in mkinitcpio I'd like to cleanup, but I need to
have one issue clarified before I proceed. The header of mkinitcpio
itself states that various parts need to run under Busybox's ash, and
thus various standards need to be adhered to. However, the file itself
sports a /bin/bash shebang, and makes mild use of parameter expansion,
e.g. APPNAME=${0##*/} on line 44.
I understand that hooks themselves need to run in a more POSIX
environment, but would it be safe to use more Bash syntax in the
code that generates the initcpio image? I would be sticking to a feature
set compatible with 3.2.
thanks,
dave reisner
Re: [arch-general] perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
On Tue, Jul 20, 2010 at 07:34:10PM -0500, C Anthony Risinger wrote: On Tue, Jul 20, 2010 at 5:55 PM, Loui Chang louipc@gmail.com wrote: On Tue 20 Jul 2010 17:14 +0200, Damjan Georgievski wrote: This is what happens to me now # pacman -Syu ... :: Starting full system upgrade... warning: perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1) I guess this happens because I have installed something from testing at one point, and anyway, I know how to override this warningm but.. The question is, should pacman think that 2.1401 is newer than 2.15 ? I would hope so. 1401 15 at the same time [snipped ls output] :-D C Anthony Sure, because ls is ignorant of the fact that its sorting numbers versus letters. From a lexicographical perspective, what ls is doing above is correct. If you pass the data along to something that actually takes into account that its sorting numbers... $ ls -1 | sort -n 1 2 3 4 5 6 7 8 9 10 11 12 13 ... you get the point Pacman follows its own rules, as described in the man page. 1401 should be newer than 15, but of course upstream should have, imo, versioned it as 2.14.01 to avoid this kind of nonsense. dave
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, Jul 17, 2010 at 12:23:48PM -0300, Rafael Beraldo wrote: 2010/7/17 Thomas Dziedzic gos...@gmail.com On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee ngoo...@gmail.com wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. Agreed with Ng Oon-Ee on this one. In this case, I think the best would be the middle ground. I mean, when upgrading the kernel, the older would be named “vmlinuz26-old” and the initramfs “kernel26-old.img”. This would be a secutiry measure --- what if a new kernel doesn't work? Then you're boned anyways because /lib/modules/$(uname -r)/ was replaced. It'll be missing in the case of a 2.6.X upgrade. d
[arch-general] [PATCH] mkinitcpio: mount real root device instead of symlink
If a symlink such as /dev/disk/by-uuid/x is provided on the kernel cmdline,
resolve it and mount that device instead of the symlink. This prevents some
ugliness in the output of commands such as mount or df.
Signed-off-by: Dave Reisner d...@falconindy.com
---
init_functions |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/init_functions b/init_functions
index 1ae844b..37b9ebb 100644
--- a/init_functions
+++ b/init_functions
@@ -93,5 +93,8 @@ default_mount_handler() {
else
rwopt=ro
fi
+if [ -L ${root} ]; then
+ root=$(readlink -f ${root})
+fi
mount ${fstype:+-t ${fstype}} -o ${rwopt}${rootflags:+,${rootflags}}
${root} $1
}
--
1.7.1.1
