Mounts are "unmounted".
Swaps are "deactivated", not "turned off" nor "disabled".
Loop and DM devices are "detached", not "deleted".
Especially the deleting sounded a bit scary.
In bugreports about hangs during the late shutdown we are often missing
important information - what were we trying to unmount/detach when it hung.
Instead of printing what we successfully unmounted, print what we are
going to unmount/detach. And add messages to mark the completion of
categories (mount/swap/loop/DM).
On Thu, Dec 6, 2012 at 9:20 AM, Robert Milasan <rmilasan@suse.com> wrote:
> It seems that the added rules:
>
> ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="046b",
> ATTR{idProduct}=="ff10", TEST=="power/control",
> ATTR{power/control}="auto"
>
> creates problems for people with Supermicro X8ST3 mb (and maybe
> other Supermicro mb's) and renders the KVM-over-IP unusable, at BIOS
> and GRUB the KVM works perfectly, but after that the device is unusable.
>
> Dropping the rule fixes the issue.
>
> Reference bug: https://bugzilla.novell.com/show_bug.cgi?id=792576
People still don't understand what the message implies.
We have to be more verbose (or more intelligent and detect some of the
cases automatically, but that's not so easy).
https://bugzilla.redhat.com/show_bug.cgi?id=884438
The individual address block is a poor man's organizationally unique
identifier.
Perhaps we should change the udev key from ID_OUI_FROM_DATABASE to
something like ID_IEEE_VENDOR_FROM_DATABASE?
Suggested-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>
Fix the fallowing error when no system dbus available:
Failed to get system D-Bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
process 14920: arguments to dbus_connection_close() were incorrect, assertion "connection != NULL" failed in file ../../dbus/dbus-connection.c line 2889.
This is normally a bug in some application using the D-Bus library.
process 14920: arguments to dbus_connection_unref() were incorrect, assertion "connection != NULL" failed in file ../../dbus/dbus-connection.c line 2776.
This is normally a bug in some application using the D-Bus library.
If the system does not have any active console, we should not try to
create an empty symlink. Instead, create no symlink at all.
Otherwise, on systems with CONFIG_VT=n and no serial console, we will
create a symlink with an empty template parameter.
This saves test output to individual .log files.
The driver is only used in /Makefile.am, not in
/docs/*udev/Makefile.am because the latter don't seem to work with
this driver. They don't produce much output anyway.
.gitignore is alphabetized, and .log files are added to it.
Generated files from /build-aux are removed from the list.
f33d3ec1 (move more common files to shared/ and add them to shared.la,
2012-04-12) moved src/hostname-setup.c to src/shared/hostname-setup.c,
but did not update DISTRO_PORTING accordingly. Fix this.
Currently, keymaps are provided only for the NP90X3A laptop. Samsung
introduced updated models, codenamed 900X3B, 900X3C, 900X4B, 900X4C,
which are currently not matched by udev rules. This patch includes the
newer modules in udev rules and move the samsung-n90x3a file defining
keys to a more generic samsung-series-9 file.
The patch was tested on a 900X4C laptop, and other people reported
that the rules also work for 900X3B and 900X3C ones.
In the words of Homer: If you don't try, you can't fail.
This is a revert of 9279749b84.
It used to be necessary to consider the umounting failed to make sure /
and /usr were remounted read-only, but that is no longer necessary as
everything is now remounted read-only anyway.
Moreover, this avoids a warning at shutdown saying a filesystem was not
unmounted. As the umounting of / is never attempted there was no
corresponding warning message saying which fs that failed. This caused some
spurious bug-reports from concerned users.
Cc: Michael Biebl <biebl@debian.org>
Traditional sysvinit systems would not complain about duplicates in
fstab. Rather it (through monut -a) would mount one fs on top of another,
in effect the last entry taking precedent.
In systemd, the first entry takes precedent, all subsequent ones are
ignored and an error is printed.
The change of behavior and the source of this error message was causing
some confusion, so give a hint what migt be wrong.
Michal Schmidt