> Also, if you have the time, it would be good if you could also open a Merge
> Request against the Debian smartmontools project on salsa:
>
> https://salsa.debian.org/debian/smartmontools
I'd love to, but how? What do you suggest?
-- salsa won't let me create a merge request, presumably becaus
Pushed upstream, as requested, just now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927980
Title:
smartd-runner bug causes loss of email recipients
To manage notifications about this bug go to:
Public bug reported:
*** Expected, documented, and desired behavior:
In /etc/smartd.conf it is permitted to specify multiple email recipients.
Here is the relevant snippet:
###
DEFAULT -d removable -n standby \
-a -M test \
-s S/..
Here is better evidence.
Just now I ran the experiment using same kernel version, 4.19.42,
as in the xenial experiment reported above.
My conclusions are unchanged. The newly-introduced incompatible
and inconsistent behavior depends on the modprobe release, not
on the kernel release. I knew this
I have conducted more investigation into the cause, resulting in a
significant restatement of the issue.
As far as this bug is concerned, it appears there has been no
regression, indeed no change in behavior in ifconfig (net-tools package)
or ifup (ifupdown package). However it could be argued th
Contrasting attachment, as discussed in previous comment.
** Attachment added: "bionic: insmod and modprobe behave differently"
https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1828749/+attachment/5264585/+files/dummy-bionic.logg
--
You received this bug notification because you are
To reiterate and clarify: net-tools and ifupdown both exhibit the bug
in bionic, whereas neither exhibits the bug in xenial. The bug is
observed in the following package versions:
:; apt-cache policy net-tools
net-tools:
Installed: 1.60+git20161116.90da8a0-1ubuntu1
Candidate: 1.60+git2016111
Message 2 of 2: This is easy to use and/or test ifup dummy0 and ifdown
dummy0
You don't need to know the complexities of the motivation for why this
is important; the test case is very simple.
In the context of the ifupdown package, this requires putting a stanza like
this in /etc/network/inte
Msg 1 of 2: Here is a use-case for ifup dummy0 and ifdown dummy0:
I have multiple laptops. Sally has multiple laptops. Sometimes they
are wired (for speed) and sometimes wireless (for portability).
Sometimes we are at the same workplace, or at my abode, or her abode, or
the local library, or th
Can you please transfer this to the ifupdown package?
Or should I just resubmit it from scratch?
The discussions of the importance of ifconfig are beside the point.
The problem presented itself during boot-up, in connection with
an "auto dummy0" directive in /etc/network/interfaces.
If "auto dummy
*) As for priority: It's not as low as you might imagine.
The problem affects not just ifconfig but also ifup, which is
indispensable. It also affects the "raise network interface"
target at boot time, as triggered by "auto dummy0" directives
in /etc/network/interfaces.
Symptom:
:; ifup dummy0
C
Public bug reported:
Desired behavior:
The ifconfig command should be able to deal with the
dummy device. This worked fine until recently.
Observed behavior:
:; ifconfig dummy0
dummy0: error fetching interface information: Device not found
This problem appeared when I upgraded to bion
Here's the workaround.
** Attachment added: "workaround for ifconfig dummy0 bug"
https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1828749/+attachment/5263317/+files/dummy-workaround
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I put the attached file in if-pre-up.d/dummy-workaround
to make my system work reliably.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828749
Title:
ifconfig dummy0 : Device not found
To manage no
Here's an even simpler argument why random-seed-load and random-seed-save should
be seen as two separate stateless services, not as the "start" and "stop" of
some
single long-lived service.
Suppose that during boot-up, random-seed-load fails for some reason. There are
definitely ways this could
OK, I implemented approach (2) from the previous comment.
The work consists of six steps, in two groups of three:
++ create system/systemd-random-seed-load.service
++ create system/systemd-random-seed-save.service
-- get rid of the old system/systemd-random-seed.service
++ create system/sysinit.t
I retract patch and recipe mentioned in the initial report. The
problem is messier than I initially thought.
One fundamental consideration is that apparently systemctl won't
start a service that is marked active, and won't stop a service
that is marked inactive. This is inconsistent with longsta
** Patch removed: "systematic way to refresh the randdom-seed"
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1652381/+attachment/4795907/+files/random-seed.patch
** Tags removed: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
The policy questions are only very distantly tangential to the topic of
this report.
The point is, no matter what policy is adopted, there needs to be a way
to *implement* the policy. There needs to be some concrete *command*
to put into the cron entry or whatever.
The logical, systematic, tradi
*** This bug is a security vulnerability ***
Public security bug reported:
Background and rationale: There ought to be a nice systematic way to
refresh the random-seed again and again, while the system is running
normally, not just at boot time or at shutdown time.
Sometimes a system may crash
I see the importance is still "undecided". Here is something that may
help:
Message from Rich Salz, 12/22/2016 10:06 AM:
> Feel free to quote me:
> This is very important.
[...]
> Rich Salz
>Senior Architect, Akamai Technologies
>Member, OpenSSL Dev Team
High-quality randomly-dist
I strongly agree with the main idea here:
"entropy pool should be seeded earlier in boot process"
Here are some numbers that quantify the magnitude
of the problem:
prior
startup script #bits
(mountall)
22 matches
Mail list logo
