Per former discussion, better safe than sorry - added a FFe request to
the description and subscribed the release-team.
** Description changed:
+ [FFe]
+ * (re-)introduce a feature to ensure the initial (boot time) kernel
+messages are preserved
+ * This existed up to Trusty (upstart) but
It would be the readdition of a feature that we lost as a feature
regression nine releases ago. I don't see why the release team would
object, but I can't speak for the release team. It feels like a feature
to me. In the general case, ignoring feature freeze for features being
readded that were
@xnox - thanks for your ping, I agree if we would have worked on this in Vivid
or at least Xenial.
But being so late I'd think to ask for an ack by the Release team is not wrong.
I thought here "better safe than sorry" somewhat applies.
OTOH fortunately the change itself isn't very invasive to an
I'm not sure why you think an FFe is needed for this. It is a simple
regression since move from upstart->systemd in the rsyslog package, and
we must SRU this back to all the releases back.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
As soon as something isn't urgent it falls off everyones lists :-/
I have found this old bug (again) in my notes, felt embarrassed and converted
the suggestion of xnox into an MP that we can ack and push to early 19.10 then
(hopefully not forgetting it again).
We probably will have to rebase
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/rsyslog/+git/rsyslog/+merge/364133
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1450588
Thanks Dimitri for all the pre-work and the suggested systemd unit matching the
old upstart job.
We really like that, especially as it avoids the concern of "just another
ongoing log" due to being an initial one-shot task that does not continue to
log the ongoing messages.
And yes - having
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: rsyslog (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
Marking as invalid for systemd package. As neither it, nor upstart
shipped the functionality in question. It is a regression in the rsyslog
package.
Or possibly makes sense to ship this in like util-linux which ships
/bin/dmesg.
** Changed in: rsyslog (Ubuntu)
Assignee: (unassigned) =>
./debian/rsyslog.dmesg.upstart was shipped by rsyslog package in Trusty
and/or other releases.
It was:
start on runlevel [2345]
task
script
savelog -q -p -c 5 /var/log/dmesg
dmesg -s 524288 > /var/log/dmesg
chgrp adm /var/log/dmesg
end script
Thus if such functionality is desired to
** Also affects: rsyslog (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1450588
Title:
/var/log/dmesg No Longer Being
Sorry but that argument is illogical. The only retention period that
would ensure that you always have the boot time kernel messages is
'infinity' and that's not a reasonable option for obvious reasons (c.f.
LP #1618188).
** Changed in: systemd (Ubuntu)
Status: Won't Fix => New
--
You
No.
Adjust your journal config for longer retention, if so desired.
http://manpages.ubuntu.com/manpages/xenial/man5/journald.conf.5.html
** Changed in: systemd (Ubuntu)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Right, /var/log/dmesg was an upstart specific file. There is little
point in writing yet another log file, given that all the information is
already available in the systemd journal, /var/log/kern.log, and
/var/log/syslog.
** Changed in: systemd (Ubuntu)
Status: New = Won't Fix
--
You
14 matches
Mail list logo
