Bug #9149
Random Pidgin nicknames are not generated on boot when the system clock is wrong
100%
Description
Macbook Pro (Retina, I guess all of them)
isn’t generating random nicknames on boot in Pidgin.
Tested XX times. Nicknames on IRC’s are always just XXX_NICK_XXX
What is the issue? I have no idea.
Subtasks
Related issues
Related to Tails - Bug #9234: Abort boot when any live-config hook fails | Confirmed | 2015-04-15 |
History
#1 Updated by uiop 2015-04-01 20:46:33
is screenshot required?
If there are any other Mac users, can they approve this bug?
#2 Updated by BitingBird 2015-04-01 20:53:46
Please report a bug using whisperback: https://tails.boum.org/doc/first_steps/bug_reporting
#3 Updated by BitingBird 2015-04-01 20:54:09
- Assignee set to uiop
- QA Check set to Info Needed
#4 Updated by sajolida 2015-04-06 14:23:17
We add similar things happen in the past, see Bug #6273. But that could be caused by weird conditions that indeed a WhisperBack bug will hopefully clarify. Make sure to mention this ticket number (Bug #9149) in your bug report.
#5 Updated by sajolida 2015-04-08 18:23:40
- Status changed from New to Confirmed
- Priority changed from Normal to Elevated
- Target version set to Tails_1.4
We received report b4fa244d96fa1462bef1419ef6eaf839.
The log for /var/log/live/config.log stop with:
gpg: key 0xDBB802B258ACD84F was created 32925448 seconds in the future (time warp or clock problem)
gpg: key 0xDBB802B258ACD84F: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 5
gpg: w/o user IDs: 3
gpg: imported: 2 (RSA: 2)
gpg: no ultimately trusted keys found
:ERROR
while they usually say:
gpg: key 58ACD84F: public key "Tails developers (offline long-term identity key) <tails@boum.org>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
gpg: no ultimately trusted keys found
- configuring Pidgin
- fixing permissions
So could a bad clock at startup cause this?
Marking as Elevated until some discards this as not being a regression.
#6 Updated by anonym 2015-04-09 14:15:30
- Assignee deleted (
uiop)
sajolida wrote:
> So could a bad clock at startup cause this?
That looks like a very plausible explanation, and I can reproduce this by booting with nosplash break=bottom
on the kernel cmdline, running something like date --set "Jan 1 00:00:00 2000"
, and then continue booting.
I guess we could add another live-config hook that runs before anything else, e.g. config/chroot_local-includes/lib/live/config/0001-sane-time
that looks like this:
#!/bin/sh
BUILD_DATE="$(sed -n -e '1s/^.* - \([0-9]\+\)$/\1/p;q' /tmp/version)"
if [ "$(date +%s)" +%s)" -lt "$(date -d "${BUILD_DATE} +%s" ]; then
date --set "${BUILD_DATE}"
fi
I.e. if the system clock is set to before the image build date, then we set it to the build date. Unless we have screwed up majorly, this will ensure that the keys/uids are valid, and possibly help with other issues too (like time syncing!). However, I’m tempted to allow the system clock to be up to 1 day before the build date to deal with potential issues from timezones when an image is booted immediately after it’s built (especially around the edge cases, i.e. just before and after 00:00:00). I actually didn’t look if such a problem could arise, but I’d rather skip that and stay on the safe side so we don’t make this time fix trigger unnecessarily all the time one our autobuild + autotest dream comes true. Does this make sense?
On a related note, I’m not sure I loke how live-config aborts the rest of our hooks if one fails. Perhaps we should do something about it? For instance, in all our hooks we could:
- Add
set +e
at the top (live-config runs withset -e
) - Add
set -e
(to set it back in live-config) andexit 0
(to ensure script “success”) at the bottom
Thoughts?
#7 Updated by intrigeri 2015-04-14 13:15:26
> I actually didn’t look if such a problem could arise, but I’d rather skip that and
> stay on the safe side so we don’t make this time fix trigger unnecessarily all the
> time one our autobuild + autotest dream comes true. Does this make sense?
It does make sense to me.
> On a related note, I’m not sure I loke how live-config aborts the rest of our hooks
> if one fails. Perhaps we should do something about it? For instance, in all our hooks
> we could:
> # Add set +e
at the top (live-config runs with set -e
)
> # Add set -e
(to set it back in live-config) and exit 0
(to ensure script “success”) at the bottom
I dislike getting rid of catching all errors the programmer didn’t carefully check for, which set -e
gives us. But on error, we should abort the boot and display a useful error message, instead of going on booting a misconfigured Tails.
#8 Updated by anonym 2015-04-15 10:53:16
- Status changed from Confirmed to In Progress
Applied in changeset commit:88a59388c736ae21fdcde426a08703dbb6bd867a.
#9 Updated by anonym 2015-04-15 10:53:58
- % Done changed from 0 to 50
- QA Check changed from Info Needed to Ready for QA
- Feature Branch set to bugfix/9149-set-sane-clock-at-early-boot
intrigeri wrote:
> > I actually didn’t look if such a problem could arise, but I’d rather skip that and
> > stay on the safe side so we don’t make this time fix trigger unnecessarily all the
> > time one our autobuild + autotest dream comes true. Does this make sense?
>
> It does make sense to me.
Implemented.
> > On a related note, I’m not sure I loke how live-config aborts the rest of our hooks
> > if one fails. Perhaps we should do something about it? For instance, in all our hooks
> > we could:
>
> > # Add set +e
at the top (live-config runs with set -e
)
> > # Add set -e
(to set it back in live-config) and exit 0
(to ensure script “success”) at the bottom
>
> I dislike getting rid of catching all errors the programmer didn’t carefully check for, which set -e
gives us. But on error, we should abort the boot and display a useful error message, instead of going on booting a misconfigured Tails.
Filed as Bug #9234.
#10 Updated by BitingBird 2015-04-15 14:47:52
- related to Bug #9234: Abort boot when any live-config hook fails added
#11 Updated by intrigeri 2015-04-17 12:11:50
- Subject changed from [MAC] Pidgin not generating random nicknames on boot to Random Pidgin nicknames are not generated on boot when the system clock is wrong
#12 Updated by intrigeri 2015-04-17 19:22:44
- Assignee set to intrigeri
#13 Updated by intrigeri 2015-04-18 08:00:58
- Status changed from In Progress to Fix committed
- % Done changed from 50 to 100
Applied in changeset commit:bd3c9b13bd2066f339ca6d4f719d50932fa64430.
#14 Updated by intrigeri 2015-04-18 08:01:30
- Assignee deleted (
intrigeri) - QA Check changed from Ready for QA to Pass
#15 Updated by BitingBird 2015-05-12 18:39:06
- Status changed from Fix committed to Resolved