- Arch-dev-public - lists.archlinux.org

[arch-dev-public] [signoff] btrfs-progs
by Tom Gundersen 27 Jul '12

27 Jul '12

Hi guys, Seems not many of us yet use btrfs, I therefore would like to ask if any users can signoff on the btrfs-progs in testing (i.e. verify that the package appears to work). In particular, I'm interested to hear if someone who uses btrfs-progs and initscripts from testing could verify that the multi-device support still works? If you have the btrfs hook in your initramfs, then please enable udev too and regenerate the image to verify that that also still works. For those who are interested: the change we made was to scan btrfs devices for multi-device support using udev rules as the devices appear rather than doing it unconditionally after "all the devices should be ready". This approach should hopefully be more reliable than the old one. Cheers, Tom

1 0

Re: [arch-dev-public] [mkinitcpio][RFC] a better fallback image?
by Dave Reisner 27 Jul '12

27 Jul '12

On Thu, Jul 26, 2012 at 12:01:22AM +0200, Tom Gundersen wrote: > On Wed, Jul 25, 2012 at 11:43 PM, Dave Reisner <d(a)falconindy.com> wrote: > > On Wed, Jul 25, 2012 at 11:21:10PM +0200, Tom Gundersen wrote: > >> Dave, Tobias, Thomas, > >> > >> I just managed to hose one of my machines. It was mainly due to an > >> unfortunate series of events, but I have a suggestion which would have > >> avoided this situation and might beneficial in general. > > > > Oops. ;P > > > > What did you break? > > Had a hard crash during a pacman. Trying to fix things from a rescue > shell I installed the kernel and as I didn't have udev running, > mkinitcpio claimed /dev was not mounted (at least I think that's why > that happened) and refused to run. I then started udevd manually, and > the machine hung again. > > Result: on next restart I had a 3.5 kernel, but the modules in both my > initramfs' were 3.2 (or something like that). So without an ext4 I was > sad. > Fun! > > You've mentioned this idea before, and more recently, so has Jan. I've > > slowly and quietly been adding support to mkinitcpio to make this less > > painful to do. An xz-compressed image with the usb and fw hooks still > > weighs in at under 10MiB, so I have no real concerns about this being > > problematic for users with separate /boot partitions. > > Nice! > > > That said, I'm wondering how it would be possible to generate this at > > compile time. I'm not really sure how this would be possible. Is there > > any objection to just adding another preset (maybe related to how you > > fubar'd your install this time?). > > The underlying problem is that in principle you might (as I did) > upgrade your kernel without running mkinitcpio. We have seen pacman > issues causing this, simple crashes as what I had might cause it, or a > broken mkinitcpio.conf might do it (I guess the last one could be > worked around by adding a special preset that does not care about user > config). > Well that answers the why, but that was the easy question =P. I suppose I could re-add a flag that would point mkinitcpio at a different module root (making no attempt to fully reimplement --basedir), which could be simply passed onto modinfo/modprobe ...but that would require patching modinfo first. > > As an alternative/addition, which has also been brought up before, why > > don't we build in the most basic of modules? I'll bet we can cover at > > least 50% of the use cases by picking some choice pata/sata modules > > (e.g. ahci, ata_piix, pata_jmicron, sd_mod, ext4) and compiling them in > > staticly. It, of course, doesn't cover folks with non-trivial setups, > > but it provides a bulletproof bootstrap for a lot of people. > > I really think this would be a good idea. I wanted to make some > additions to pierres pkgstats stuff so we could have an idea of how > large percentage of our users would be covered by the modules you > propose. I expect the vast majority would. Sure. I'd love to see the running kernel version and the first column of /proc/modules submitted with pkgstats. If we were to reset the global stats (or just reset the epoch) and make a concerted effort to have people submit (news post, social media, allan's blog, etc) I'll bet we could gather some good usage stats from -ARCH kernel consumers in a fairly short timeframe. > Cheers, > > Tom

3 4

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 27 Jul '12

27 Jul '12

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 6 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 9 fully signed off packages * 22 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (6 total) == * initscripts-2012.07.5-1 (any) * systemd-187-3 (i686) * systemd-187-3 (x86_64) * pkgstats-2.2-1 (any) * cups-1.6.0-1 (i686) * cups-1.6.0-1 (x86_64) == Incomplete signoffs for [core] (8 total) == * initscripts-2012.07.5-1 (any) 1/2 signoffs * btrfs-progs-0.19.20120328-4 (i686) 0/2 signoffs * cryptsetup-1.5.0-1 (i686) 0/2 signoffs * iptables-1.4.14-3 (i686) 1/2 signoffs * systemd-187-3 (i686) 0/2 signoffs * wpa_actiond-1.3-1 (i686) 0/2 signoffs * btrfs-progs-0.19.20120328-4 (x86_64) 1/2 signoffs * systemd-187-3 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (14 total) == * pkgstats-2.2-1 (any) 0/2 signoffs * cups-1.6.0-1 (i686) 0/2 signoffs * fcpci-31107-79 (i686) 0/2 signoffs * fcpcmcia-31107-74 (i686) 0/2 signoffs * libwacom-0.6-1 (i686) 0/2 signoffs * lirc-1:0.9.0-24 (i686) 0/2 signoffs * nvidia-302.17-5 (i686) 0/2 signoffs * openconnect-1:4.00-1 (i686) 0/2 signoffs * cups-1.6.0-1 (x86_64) 0/2 signoffs * fcpci-31107-79 (x86_64) 0/2 signoffs * fcpcmcia-31107-74 (x86_64) 0/2 signoffs * libwacom-0.6-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-24 (x86_64) 0/2 signoffs * openconnect-1:4.00-1 (x86_64) 1/2 signoffs == Completed signoffs (9 total) == * filesystem-2012.7-1 (any) * linux-3.5-1 (i686) * cryptsetup-1.5.0-1 (x86_64) * iptables-1.4.14-3 (x86_64) * linux-3.5-1 (x86_64) * wpa_actiond-1.3-1 (x86_64) * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (i686) * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (x86_64) * nvidia-302.17-5 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * openconnect-1:4.00-1 (i686), since 2012-06-21 * openconnect-1:4.00-1 (x86_64), since 2012-06-21 * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (i686), since 2012-06-21 * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (x86_64), since 2012-06-21 == Top five in signoffs in last 24 hours == 1. lfleischer - 7 signoffs 2. stephane - 4 signoffs 3. foutrelis - 2 signoffs

1 0

[arch-dev-public] [RFC, after the fact] initscripts config
by Tom Gundersen 26 Jul '12

26 Jul '12

Hi guys, The controversy of the recent change to rc.conf took me by surprise (silly me). So, let appologise for not taking this to arch-dev-public first and let me go back in time, and present an RFC, so we can all agree on what to do and I'll make whatever changes necessary and push a new version to testing. It seems that there was no opposition to the change to crypttab (except for some minor details being discussed at arch-projects), so I won't comment on that. Current state of affairs: rc.conf is the central configuration file for all Arch-specific settings. It is emphatically not the only configuration file for basic system configuration (locale.gen, hosts, fstab, crypttab and inittab spring to mind). Some of the configuration in rc.conf already have their own configuration files shipped by upstream (HARDWARECLOCK and TIMEZONE in particular). The fact that these variables are configured in two places, which can get out of sync (most of the time without the admin even knowing about the second place) causes endless minor bugs. The systemd project has been working towards providing a common set of configuration files for all distributions (regardless of what init daemon they use). This has been done by taking input from all the distros that contribute to systemd, and trying to pick the good things from each distro and leaving out the bad. I have been making sure that these configuration files can support whatever setups our old configuration files currently do. Most recently I added support for keyfile-offset to the systemd crypttab format as that was the last blocker (in my opinion) before systemd's crypttab format could replace Arch's. I'd like to point out that getting these sorts of changes into the systemd project has been surprisingly easy. Initscripts and systemd both now support the same configuration formats (i.e. we can read the systemd format, and systemd can read ours). rc.conf is documented in its own manpage, cross-referenced with the systemd configuration files' manpages. What I propose: 1) Support all current and past configuration options in rc.conf in perpetuity (if for whatever reason something must be dropped, this will of course be announced in the normal way). This is for instance what we did with the old network syntax, that should still work just fine, even if it is marked as deprecated for a long time. This perpetual support will at least be the case in initscripts, I have no strong opinions about whether or not this should be done in systemd as well (probably not). 2) Deprecate the "harmful" configuration options from rc.conf (i.e. the ones that cause bugs), as they are clearly not Arch-specific, and have their own configuration files. The deprecation means removing them from the standard rc.conf and recommending against their use in rc.conf(5) as well as explaining how they should be configured instead. 3) Remove esoteric configuration options from rc.conf and only document them in the manpage. I don't feel strongly about this at all, and would be happy to revert it if people object. My reasoning here is that only experts should be changing them, so nothing a new user should need to be faced with. As I said, not a big deal. 4) This is (apparently) the controversial one, and this one I do feel strongly about: Embrace the systemd configuration files (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname and /etc/modules-load.d/) fully and declare them to be the recommended standard. This means removing KEYMAP, CONSOLEFONT, CONSOLEMAP, LOCALE and HOSTNAME from the default rc.conf and recommending the alternative format in rc.conf(5). We would of course still support the old options. Justification of (4): a) This is in line with (at least my take on) the aim of rc.conf: these options are no longer Arch-specific, but rather something shared with many other distros. b) This is more KISS (of course this is purely subjective, but I'll put it out there anyway): one configuration file per type of options is simpler than mixing them all together. Why should networking and locale be configured in the same file? If we mix that, why don't we also add in fstab and the rest? c) The difference between the new and the old format for an end user is truly trivial. I appreciate people not liking this change, but anyone who claims that this is a major regression will not be taken seriously. Sorry. d) The new format does not require a bash interpreter to be read. This means that lots of things which were previously impossible will now be possible (reading and writing the configs from programs can now be done in a sound way). e) People who use more than one distro don't have to learn more than one format. f) Guides, howtos, documentation will now apply equally well to Arch as to the other major distros. g) Having a huge ecosystem working on and agreeing on these formats should be an obvious benefit. h) The major one: systemd is here to stay, more and more Arch devs and users switch to systemd and we will increasingly struggle to get enough testers and reviewers for initscripts. However, I really want to support initscripts as long as I can. To make this doable for me, we need to unify. We need to share code, configuration and behavior to make initscripts sustainable even with very few testers. You might argue that what we should do is to block systemd in order to support initscripts. However, I think that would be a huge error as systemd is simply too superior in every way, so preventing our users from using it is not doing anyone any favors. I must admit I'm a bit exasperated by the shortsightedness of most of the flames on BBS/IRC/MLs. So if you are going to veto this, please also outline an alternative long-term plan. Cheers, Tom

3 5

[arch-dev-public] cups 1.6.0 hitting testing
by Andreas Radke 26 Jul '12

26 Jul '12

A major cups update hits testing. Cups has dropped native printer browsing support for Linux OS, you now need to run the avahi-daemon before you start cupsd. Make sure you also cleanup your cupds.conf. My server seems to print well. Clients can see the printers in the print dialog here. Please report broken stuff you may find to our tracker or upstream. Note: Please also test the systemd-socket patch. My server is running initscripts so I can't test it. It has become a mix of the Fedora and the Gentoo patch (no big differences). -Andy

1 0

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 26 Jul '12

26 Jul '12

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 13 fully signed off packages * 20 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [core] (7 total) == * initscripts-2012.07.4-1 (any) 4/8 signoffs * btrfs-progs-0.19.20120328-4 (i686) 0/2 signoffs * cryptsetup-1.5.0-1 (i686) 0/2 signoffs * iptables-1.4.14-3 (i686) 1/2 signoffs * wpa_actiond-1.3-1 (i686) 0/2 signoffs * btrfs-progs-0.19.20120328-4 (x86_64) 1/2 signoffs * cryptsetup-1.5.0-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (13 total) == * bind-9.9.1.P2-1 (i686) 0/2 signoffs * fcpci-31107-79 (i686) 0/2 signoffs * fcpcmcia-31107-74 (i686) 0/2 signoffs * libwacom-0.6-1 (i686) 0/2 signoffs * lirc-1:0.9.0-24 (i686) 0/2 signoffs * nvidia-302.17-5 (i686) 0/2 signoffs * openconnect-1:4.00-1 (i686) 0/2 signoffs * bind-9.9.1.P2-1 (x86_64) 0/2 signoffs * fcpci-31107-79 (x86_64) 0/2 signoffs * fcpcmcia-31107-74 (x86_64) 0/2 signoffs * libwacom-0.6-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-24 (x86_64) 0/2 signoffs * openconnect-1:4.00-1 (x86_64) 1/2 signoffs == Completed signoffs (13 total) == * filesystem-2012.7-1 (any) * iana-etc-2.30-3 (any) * dnsutils-9.9.1.P2-1 (i686) * linux-3.5-1 (i686) * systemd-187-2 (i686) * dnsutils-9.9.1.P2-1 (x86_64) * iptables-1.4.14-3 (x86_64) * linux-3.5-1 (x86_64) * systemd-187-2 (x86_64) * wpa_actiond-1.3-1 (x86_64) * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (i686) * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (x86_64) * nvidia-302.17-5 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * openconnect-1:4.00-1 (i686), since 2012-06-21 * openconnect-1:4.00-1 (x86_64), since 2012-06-21 * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (i686), since 2012-06-21 * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (x86_64), since 2012-06-21 == Top five in signoffs in last 24 hours == 1. stephane - 2 signoffs 2. andyrtr - 2 signoffs

1 0

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 25 Jul '12

25 Jul '12

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 8 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 12 fully signed off packages * 21 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (8 total) == * dnsutils-9.9.1.P2-1 (i686) * iptables-1.4.14-3 (i686) * dnsutils-9.9.1.P2-1 (x86_64) * iptables-1.4.14-3 (x86_64) * bind-9.9.1.P2-1 (i686) * libwacom-0.6-1 (i686) * bind-9.9.1.P2-1 (x86_64) * libwacom-0.6-1 (x86_64) == Incomplete signoffs for [core] (8 total) == * initscripts-2012.07.4-1 (any) 3/8 signoffs * btrfs-progs-0.19.20120328-4 (i686) 0/2 signoffs * cryptsetup-1.5.0-1 (i686) 0/2 signoffs * iptables-1.4.14-3 (i686) 1/2 signoffs * wpa_actiond-1.3-1 (i686) 0/2 signoffs * btrfs-progs-0.19.20120328-4 (x86_64) 1/2 signoffs * cryptsetup-1.5.0-1 (x86_64) 1/2 signoffs * iptables-1.4.14-3 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (13 total) == * bind-9.9.1.P2-1 (i686) 0/2 signoffs * fcpci-31107-79 (i686) 0/2 signoffs * fcpcmcia-31107-74 (i686) 0/2 signoffs * libwacom-0.6-1 (i686) 0/2 signoffs * lirc-1:0.9.0-24 (i686) 0/2 signoffs * nvidia-302.17-5 (i686) 0/2 signoffs * openconnect-1:4.00-1 (i686) 0/2 signoffs * bind-9.9.1.P2-1 (x86_64) 0/2 signoffs * fcpci-31107-79 (x86_64) 0/2 signoffs * fcpcmcia-31107-74 (x86_64) 0/2 signoffs * libwacom-0.6-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-24 (x86_64) 0/2 signoffs * openconnect-1:4.00-1 (x86_64) 1/2 signoffs == Completed signoffs (12 total) == * filesystem-2012.7-1 (any) * iana-etc-2.30-3 (any) * dnsutils-9.9.1.P2-1 (i686) * linux-3.5-1 (i686) * systemd-187-2 (i686) * dnsutils-9.9.1.P2-1 (x86_64) * linux-3.5-1 (x86_64) * systemd-187-2 (x86_64) * wpa_actiond-1.3-1 (x86_64) * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (i686) * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (x86_64) * nvidia-302.17-5 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * openconnect-1:4.00-1 (i686), since 2012-06-21 * openconnect-1:4.00-1 (x86_64), since 2012-06-21 * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (i686), since 2012-06-21 * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (x86_64), since 2012-06-21 == Top five in signoffs in last 24 hours == 1. idevolder - 9 signoffs 2. dan - 4 signoffs 3. foutrelis - 3 signoffs 4. bisson - 2 signoffs 5. tomegun - 2 signoffs

1 0

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 24 Jul '12

24 Jul '12

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 14 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 7 fully signed off packages * 21 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (14 total) == * iana-etc-2.30-3 (any) * initscripts-2012.07.4-1 (any) * btrfs-progs-0.19.20120328-4 (i686) * linux-3.5-1 (i686) * btrfs-progs-0.19.20120328-4 (x86_64) * linux-3.5-1 (x86_64) * fcpci-31107-79 (i686) * fcpcmcia-31107-74 (i686) * lirc-1:0.9.0-24 (i686) * nvidia-302.17-5 (i686) * fcpci-31107-79 (x86_64) * fcpcmcia-31107-74 (x86_64) * lirc-1:0.9.0-24 (x86_64) * nvidia-302.17-5 (x86_64) == Incomplete signoffs for [core] (8 total) == * iana-etc-2.30-3 (any) 1/2 signoffs * initscripts-2012.07.4-1 (any) 2/8 signoffs * btrfs-progs-0.19.20120328-4 (i686) 0/2 signoffs * cryptsetup-1.5.0-1 (i686) 0/2 signoffs * linux-3.5-1 (i686) 1/2 signoffs * wpa_actiond-1.3-1 (i686) 0/2 signoffs * btrfs-progs-0.19.20120328-4 (x86_64) 0/2 signoffs * cryptsetup-1.5.0-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (13 total) == * fcpci-31107-79 (i686) 0/2 signoffs * fcpcmcia-31107-74 (i686) 0/2 signoffs * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (i686) 1/2 signoffs * lirc-1:0.9.0-24 (i686) 0/2 signoffs * nvidia-302.17-5 (i686) 0/2 signoffs * openconnect-1:4.00-1 (i686) 0/2 signoffs * zsh-5.0.0-1 (i686) 0/2 signoffs * fcpci-31107-79 (x86_64) 0/2 signoffs * fcpcmcia-31107-74 (x86_64) 0/2 signoffs * lirc-1:0.9.0-24 (x86_64) 0/2 signoffs * nvidia-302.17-5 (x86_64) 1/2 signoffs * openconnect-1:4.00-1 (x86_64) 1/2 signoffs * zsh-5.0.0-1 (x86_64) 0/2 signoffs == Completed signoffs (7 total) == * filesystem-2012.7-1 (any) * netcfg-2.8.8-1 (any) * systemd-187-2 (i686) * linux-3.5-1 (x86_64) * systemd-187-2 (x86_64) * wpa_actiond-1.3-1 (x86_64) * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * openconnect-1:4.00-1 (i686), since 2012-06-21 * openconnect-1:4.00-1 (x86_64), since 2012-06-21 * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (i686), since 2012-06-21 * kdeplasma-applets-networkmanagement-1:0.9.0.3-1 (x86_64), since 2012-06-21 == Top five in signoffs in last 24 hours == 1. eric - 6 signoffs 2. bisson - 3 signoffs 3. tomegun - 2 signoffs 4. stephane - 1 signoffs

1 0

[arch-dev-public] resignation
by Dieter Plaetinck 23 Jul '12

23 Jul '12

Hi, I'm stepping down as last remaining releng member. It's not so much lack of time, it's more about lack of mental energy/interest. Some other devs (and Gerardo) are already taking good care of archiso, Thomas manages to patch up the releng scripts every time they break, and now there's some interest in installer scripts again, so I guess now is a good time for me to throw the towel. I've been pondering doing this for already a long time, I even wrote a few resignation mails at some points, but always discarded them before sending. AIF is arguably an over-engineered piece of software, but only because it aimed to make it "dead-easy" for users to do installations - even complicated ones - (and not just interactive, but also automated ones) which I still think is a noble goal worth pursuing, but we're too small of a team to maintain it, and me being the only one who understands it doesn't help either. If it would have been written in python it could have been more elegant and simple and might have had a very different life (with more interest from the community/other devs). I've definitely learned a lot from it, and have a bunch of ideas on how things can be done better if one would like to pursue the goals that aif pursues, but lack the interest in devoting more energy. Although I might be interested to help out if others take the lead. I would like to thank everyone who's ever contributed to Arch Linux in one way or another (some of you guys are very dedicated), There's also the guys at (open)suse who are doing lovely projects (mirrorbrain, autoinst, openQA, ...) and who have tried to work with us, I regret not being able to giving them the attention they deserve. (there's the autobuilds, the openQA automatic tests, the iso feedback webapp, which are by themselves useful but we haven't been able so far to tie them together. I still think we can achieve the autobuild+autotest+autorelease system I know some of us are dreaming of) I also look back happily on speaking with everyone in the AL community I've ever met, I never met somebody I didn't like. My personal hilights being Froscon 2009 (http://dieter.plaetinck.be/froscon_2009_afterthoughts -- check the picture of Gerhard and I!) and Archcon 2010 (http://dieter.plaetinck.be/back_from_canada_archcon.html) which was not only great for the Arch love, my trip to Canada was one of the best trips of my life, and I got to meet Dusty, who I now consider a close personal friend. good luck with AL and with your personal lives. Dieter

6 5

[arch-dev-public] [RFC] loading kernel modules
by Tom Gundersen 23 Jul '12

23 Jul '12

Hi guys, As of linux-3.5 almost all in-kernel modules are autoloaded on demand, so the need for manually specifying modules to load in MODULES (or otherwise) is almost gone. However, for out-of-tree modules, this might not yet be the case. For this purpose, we now have very simple mechanisms for packages to instruct initscripts (or systemd) to load (or blacklist) modules at boot. In other words, rather than package "foo" having a post-install message saying "Please add foo_module to MODULES in rc.conf and blacklist bar_module" it could simply install /usr/lib/modules-load.d/foo.conf: foo_module /usr/lib/modprobe.d/foo.conf: blacklist bar_module The reasoning being that an admin is almost certainly not going to want to install a package and then not follow the post-install instructions. Conversely, on un-install (s)he is likely to want to revert these changes. On the rare occasions the admin does not want the standard behavior, it can be overridden by writing (possibly empty) files to /etc/mod{ules-load,probe}.d/foo.conf Is this something we'd like to do? -t PS: A quick look shows that at least vhba, virtualbox and fcpci could benefit from this (though of course the benefits should be evaluated on a case-by-case basis).

2 2