Friendly recovery uses invalid font

Bug #1675805 reported by Alkis Georgopoulos on 2017-03-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
friendly-recovery (Ubuntu)
Undecided
Dimitri John Ledkov

Bug Description

There are a lot of similar bug reports for this, but they all seem stalled.
Here's a specific issue with a proposed one-line patch that works.

When I boot my Ubuntu 16.04.2 and select recovery mode, the menu text is unreadable, showing boxes instead of characters, like console-setup hasn't ran, while it did.

Then I edit /lib/recovery-mode/recovery-menu and insert the following line at the top:
udevadm trigger && udevadm settle -t 10

After I reboot, the problem is gone.

I'll attach two screenshots, "before.png" and "after.png", showing the issue.

Some info for my localization setup; but it shouldn't matter, it should be the same in any locale.
$ cat /etc/default/locale
LANG="el_GR.UTF-8"
$ cat /etc/default/console-setup
ACTIVE_CONSOLES="/dev/tty[1-6]"
CHARMAP="UTF-8"
CODESET="guess"
FONTFACE="Fixed"
FONTSIZE="8x16"
VIDEOMODE=

Alkis Georgopoulos (alkisg) wrote :

I'm attaching a one-liner patch that calls `udevadm trigger` from the system service file instead, which is the same that the friendly-recovery upstart job does as well.

Note that there were 2 errors in the service file:
1) ExecStartPre=-/bin/udevadm settle
The path there is wrong, because udevadm is in /sbin. The attached patch solves this as well as the font issue, in one line.

2) ExecStartPre=-/bin/sh -e 'while systemctl list-jobs | grep -v friendly-recovery | grep -q running; do sleep 0.2; done'
The author there meant "sh -c", to run the command, instead of "sh -e". This is a separate issue. But since it's in the same .service file, maybe we can SRU both issues with one upload.
I suggest that this line is removed completely because it just hangs if "sh -c" is used.

tags: added: patch
Dimitri John Ledkov (xnox) wrote :

rather just use two ExecStartPre commands rather than /bin/sh as shown in the patch.

Changed in friendly-recovery (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
milestone: none → ubuntu-17.04
Alkis Georgopoulos (alkisg) wrote :

I'm afraid the ordering there won't be guaranteed, that udevadm --settle will indeed be called after udevadm --trigger. Will it?

On 28 March 2017 at 09:57, Alkis Georgopoulos
<email address hidden> wrote:
> I'm afraid the ordering there won't be guaranteed, that udevadm --settle
> will indeed be called after udevadm --trigger. Will it?
>

That would be crazy.... don't you think?!

https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStartPre=

Syntax is the same as for ExecStart=, except that multiple command
lines are allowed and the commands are executed one after the other,
serially.

--
Regards,

Dimitri.

Alkis Georgopoulos (alkisg) wrote :

Thank you Dimitri, I'm attaching the new patch.

Alkis Georgopoulos (alkisg) wrote :

And this one additionally solves the second syntax error, i.e. it completely removes:
-# let the console output settle down
-ExecStartPre=-/bin/sh -e 'while systemctl list-jobs | grep -v friendly-recovery | grep -q running; do sleep 0.2; done'

The first problem there is that "sh -e" should be "sh -c".
The second problem is that if we make it "sh -c", then sometimes it hangs because it matches "No services running."
So I propose we completely remove those 2 lines instead.

Changed in friendly-recovery (Ubuntu):
status: New → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package friendly-recovery - 0.2.35

---------------
friendly-recovery (0.2.35) experimental; urgency=medium

  * friendly-recovery.service: trigger and settle udevadm before
    launching, drop broken settle down commands. Thanks to Alkis
    Georgopoulos. LP: #1675805
  * system-summary: improve cpu_freq reading, and make the script
    resilient to failures of reading cpu_freq. LP: #1675824

 -- Dimitri John Ledkov <email address hidden> Wed, 29 Mar 2017 17:04:51 +0100

Changed in friendly-recovery (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers