Can we please communicate better?

karol · 2012-01-21 14:11:21

Would it hurt to inform the user (e.g. in pacman's output) that kmod is a drop-in m-i-t replacement w/o the config file?

[2012-01-13 01:44] starting full system upgrade
[2012-01-13 01:48] warning: /etc/modprobe.d/modprobe.conf saved as /etc/modprobe.d/mod
probe.conf.pacsave
[2012-01-13 01:48] removed module-init-tools (3.16-3)

...

[2012-01-13 01:48] installed kmod (3-6)
[2012-01-13 01:48] upgraded util-linux (2.20.1-1 -> 2.20.1-2)

Not a word. But wait, it gets better:

[2012-01-13 01:49] upgraded udev (175-1 -> 177-1)
[2012-01-13 01:49] upgraded mkinitcpio (0.8.0-3 -> 0.8.1-1)
[2012-01-13 01:49] >>> Updating module dependencies. Please wait ...
[2012-01-13 01:49] >>> Generating initial ramdisk, using mkinitcpio.  Please wait...
[2012-01-13 01:49] ==> Building image from preset: 'default'
[2012-01-13 01:49]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initra
mfs-linux.img
[2012-01-13 01:49] ==> Starting build: 3.2.0-2-ARCH
[2012-01-13 01:49]   -> Parsing hook: [base]
[2012-01-13 01:49]   -> Parsing hook: [udev]
[2012-01-13 01:49] ==> ERROR: file not found: `/lib/udev/rules.d/50-firmware.rules'
[2012-01-13 01:49] ==> ERROR: file not found: `/lib/udev/firmware'
[2012-01-13 01:49]   -> Parsing hook: [autodetect]
[2012-01-13 01:49]   -> Parsing hook: [pata]
[2012-01-13 01:49]   -> Parsing hook: [scsi]
[2012-01-13 01:49]   -> Parsing hook: [sata]
[2012-01-13 01:49]   -> Parsing hook: [filesystems]
[2012-01-13 01:49]   -> Parsing hook: [consolefont]
[2012-01-13 01:49] ==> ERROR: file not found: `/etc/modprobe.d/modprobe.conf'
[2012-01-13 01:49] ==> Generating module dependencies
[2012-01-13 01:49] ==> Creating gzip initcpio image: /boot/initramfs-linux.img
[2012-01-13 01:49] ==> WARNING: errors were encountered during the build. The image ma
y not be complete.
[2012-01-13 01:49] ==> Image generation successful
[2012-01-13 01:49] ==> Building image from preset: 'fallback'
[2012-01-13 01:49]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initra
mfs-linux-fallback.img -S autodetect
[2012-01-13 01:49] ==> Starting build: 3.2.0-2-ARCH
[2012-01-13 01:49]   -> Parsing hook: [base]
[2012-01-13 01:49]   -> Parsing hook: [udev]
[2012-01-13 01:49] ==> ERROR: file not found: `/lib/udev/rules.d/50-firmware.rules'
[2012-01-13 01:49] ==> ERROR: file not found: `/lib/udev/firmware'
[2012-01-13 01:49]   -> Parsing hook: [pata]
[2012-01-13 01:49]   -> Parsing hook: [scsi]
[2012-01-13 01:49]   -> Parsing hook: [sata]
[2012-01-13 01:49]   -> Parsing hook: [filesystems]
[2012-01-13 01:49]   -> Parsing hook: [consolefont]
[2012-01-13 01:49] ==> ERROR: file not found: `/etc/modprobe.d/modprobe.conf'
[2012-01-13 01:49] ==> Generating module dependencies
[2012-01-13 01:49] ==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img
[2012-01-13 01:49] ==> WARNING: errors were encountered during the build. The image may not be complete.
[2012-01-13 01:49] ==> Image generation successful
[2012-01-13 01:49] upgraded linux (3.2-1 -> 3.2-2)

Fixing the filename and rebuilding the image is not a big deal, but it's not obvious.

Much of the great work Arch devs and maintainers do gets a bad rap because of such communication failures.

falconindy · 2012-01-21 14:51:43

What you have in your log here is an upgrade from [testing]. This was all very clearly mentioned:

http://mailman.archlinux.org/pipermail/ … 22324.html # everything you didn't want to know about kmod
http://mailman.archlinux.org/pipermail/ … 22384.html # udev upgrade will cause warnings in mkinitcpio

karol · 2012-01-21 15:00:16

I've read it all, it's not about me :-) Yes, I was running [testing] on this computer, but it's the same on my other box that uses non-testing repos. Same lack of info, same errors.
It seems following the ML is not optional even if you don't use [testing] and I disagree if you think that making it mandatory is the right thing to do.

Earnestly · 2012-01-21 15:00:55

I agree with Karol, also thanks for the links Falconindy. Pity they aren't as obvious as Pacman's output/Announcements/Forums.

graysky · 2012-01-21 15:20:40

+1
perhaps best to add key info to a readme.install for kmod.

On this topic, where is the "right" place to put the following if not in /etc/modprobe.d/modprobe.conf ?

$ cat /etc/modprobe.d/modprobe.conf 
blacklist w83781d
blacklist snd_pcsp
blacklist pcspkr
blacklist rtl8187
blacklist floppy

karol · 2012-01-21 15:27:54

/etc/modprobe.d/modprobe.conf is the right place, kmod simply doesn't ship the config file.
Test it to see if it works.

graysky · 2012-01-21 15:30:30

@karol - if that is true then why does the kmod package move it away to a .pacsave?!

karol · 2012-01-21 15:33:08

graysky wrote:

@karol - if that is true then why does the kmod package move it away to a .pacsave?!

Because *it doesn't ship this file* and module-init-tools (which did) were removed:

[2012-01-13 01:44] starting full system upgrade
[2012-01-13 01:48] warning: /etc/modprobe.d/modprobe.conf saved as /etc/modprobe.d/mod
probe.conf.pacsave
[2012-01-13 01:48] removed module-init-tools (3.16-3)

Since you modified this config, it was saved as a pacsave file.

graysky · 2012-01-21 15:36:19

@karol - that makes sense. thx.

stefanwilkens · 2012-01-21 16:13:06

Moving out possible user config doesn't seem to match our usual modus operandi, I would agree that we can be a little more verbose about this.

if only to void some of the "zomg what happened" spam on bbs / irc.

karol · 2012-01-21 16:16:28

stefanwilkens wrote:

Moving out possible user config doesn't seem to match our usual modus operandi

And what do you think should be done instead?

stefanwilkens · 2012-01-21 16:26:03

karol wrote:

stefanwilkens wrote:
Moving out possible user config doesn't seem to match our usual modus operandi
And what do you think should be done instead?

Two options come to mind.

1. Obviously it's desirable for users to RTFM as soon as possible so perhaps adding a little notion about this change in the post_upgrade or dumping a news article on this upgrade would be usefull.

2. Alternatively, /etc/modprobe.d/modprobe.conf is still valid with kmod, why not keep it. The syntax for the configuration files hasn't changed thus there would be no need to merge.

Any subsequent fresh install can come without a provided *.conf if shipping essentially empty configuration files is unwanted, it's the moving of possible user configuration during the upgrade that seems non-arch to me.

Perhaps I'm trying to hold hands too much here, tell me if so. I've been known to do so.

darn typos

Last edited by stefanwilkens (2012-01-21 16:31:10)

Earnestly · 2012-01-21 16:37:53

karol wrote:

stefanwilkens wrote:
Moving out possible user config doesn't seem to match our usual modus operandi
And what do you think should be done instead?

Much like every other issue which needed more information, pacman did provide a decent amount of instruction. Infact, doesn't any [core] change deserve some attention if it requires user intervention?

Alternatively, /etc/modprobe.d/modprobe.conf is still valid with kmod, why not keep it. The syntax for the configuration files hasn't changed thus there would be no need to merge.

To be fair, it was a '.pacsav' and not '.pacnew' which should give it away, however it still amounts to guesswork on the user's side on what to do unless they subscribe to the MLs.

Edit: I'm not on my arch pc, but does kmod have a man page?

pacman -Syyu
...
Replace module-init-tools with kmod?
  >> kmod is an inplace replacement for module-init-tools, however, it doesn't
     ship with a default configuration file. Due to this pacman will save your
     /etc/modprobe.d/* files which can be used with kmod.
[Y/n]

Perhaps?

Last edited by Earnestly (2012-01-21 16:53:46)

stefanwilkens · 2012-01-21 16:52:43

Kaustic wrote:

Edit: I'm not on my arch pc, but does kmod have a man page?

Not currently, no. kmod --help is feature complete but doesn't mention this specifically.

Both the [testing] repository forum and mailing list saw a lot of action on the topic, with a very verbose mailing from falconindy. Non-subscribers would be a little surprised to find their config moved, but pacman mentions this.

If you're asking if there is a system-available answer to the question of where to place your configuration, then no. Not that I know of. The location for this has been /etc/modprobe.d/*.conf for a long time now, but oblivious users would not be able to find this out without some experience / common sense.

Mind you, with the ongoing topic spam on this google's "I'm feeling lucky" will provide the answer soon.

Last edited by stefanwilkens (2012-01-21 16:55:25)

Earnestly · 2012-01-21 16:59:22

stefanwilkens wrote:

but pacman mentions this.

Which is why I'm here, and thanks to Falconindy for the links to the Mailing Lists I'm a little more aware of the issue.

Mind you, with the ongoing topic spam on this google's "I'm feeling lucky" will provide the answer soon.

Which is probably why a change in [core] which requires manual intervention might have deserved a News Announcement, but alas.

karol · 2012-01-21 17:00:59

stefanwilkens wrote:

Kaustic wrote:
Edit: I'm not on my arch pc, but does kmod have a man page?
Not currently, no. kmod --help is feature complete but doesn't mention this specifically.

I disagree wrt feature completeness https://bbs.archlinux.org/viewtopic.php … 9#p1044979

PReP · 2012-01-23 11:32:19

I started piping out arch.org news in my bash_profile, instead of fortunes, just to have some heads up each day at login.

But yeah, some echo from pacman, just a quick link or attention, when critical updates happen, would be a nice function.
some small helpful output about certain package-upgrades.

By the way, aren't we using /etc/modprobe.d/xx-blabla_blacklist.conf, nowadays since some time?, or was it the other way around.

karol · 2012-01-23 11:34:57

PReP wrote:

By the way, aren't we using /etc/modprobe.d/xx-blabla_blacklist.conf, nowadays since some time?, or was it the other way around.

Do you mean http://www.archlinux.org/news/changes-t … cklisting/ ?
https://wiki.archlinux.org/index.php/Blacklisting

Last edited by karol (2012-01-23 11:36:34)

PReP · 2012-01-23 11:48:55

karol wrote:

PReP wrote:
By the way, aren't we using /etc/modprobe.d/xx-blabla_blacklist.conf, nowadays since some time?, or was it the other way around.
Do you mean http://www.archlinux.org/news/changes-t … cklisting/ ?
https://wiki.archlinux.org/index.php/Blacklisting

Yes, that, thanks.

As i figure it, having those separate configs are the way - instead of having lines in modprobe.conf itself (or in rc.conf) , - since then, anyways.

Just as xorg.conf.d/ rules and similar.

People could either mv /etc/modprobe.d/modprobe.conf, or take the opportunity to move to the new system
(unless there still are some other functions of modprobe.conf?)

But i still agree that it would make a lot of sense for pacman to be able to ouput some small notice on
the most critical issues and pointers.

karol · 2012-01-23 11:55:55

You can still use the same old /etc/modprobe.d/modprobe.conf.

tomk · 2012-01-23 13:43:38

Kaustic wrote:

Which is probably why a change in [core] which requires manual intervention might have deserved a News Announcement, but alas.

http://www.archlinux.org/news/kmod-repl … nit-tools/

Feel free to discuss as much as you want, but remember that a feature request is required if you want the devs to consider your opinions.

Arch Linux

#1 2012-01-21 14:11:21

Can we please communicate better?

#2 2012-01-21 14:51:43

Re: Can we please communicate better?

#3 2012-01-21 15:00:16

Re: Can we please communicate better?

#4 2012-01-21 15:00:55

Re: Can we please communicate better?

#5 2012-01-21 15:20:40

Re: Can we please communicate better?

#6 2012-01-21 15:27:54

Re: Can we please communicate better?

#7 2012-01-21 15:30:30

Re: Can we please communicate better?

#8 2012-01-21 15:33:08

Re: Can we please communicate better?

#9 2012-01-21 15:36:19

Re: Can we please communicate better?

#10 2012-01-21 16:13:06

Re: Can we please communicate better?

#11 2012-01-21 16:16:28

Re: Can we please communicate better?

#12 2012-01-21 16:26:03

Re: Can we please communicate better?

#13 2012-01-21 16:37:53

Re: Can we please communicate better?

#14 2012-01-21 16:52:43

Re: Can we please communicate better?

#15 2012-01-21 16:59:22

Re: Can we please communicate better?

#16 2012-01-21 17:00:59

Re: Can we please communicate better?

#17 2012-01-23 11:32:19

Re: Can we please communicate better?

#18 2012-01-23 11:34:57

Re: Can we please communicate better?

#19 2012-01-23 11:48:55

Re: Can we please communicate better?

#20 2012-01-23 11:55:55

Re: Can we please communicate better?

#21 2012-01-23 13:43:38

Re: Can we please communicate better?

Board footer