• Projects
  • $(whoami)

Soliloquies

  • Dual boot, secure boot & bitlocker

    February 8th, 2023

    I have installed GNU/Linux on many a computers in ~20 years (some automated, most individually). In the University, I used to be woken past midnight by someone knocking at the door — who reinstalled Windows — and now they can’t boot because grub was overwritten. I’d rub the eyes, pickup the bunch latest Fedora CDs and go rescue the beast machine. Linux installation, customization and grub-recovery was my specialization (no, the course didn’t have credit for that).

    Technologies (libre & otherwise) have improved since then. Instead of MBR, there’s GPT (no, not that one). Instead of BIOS, there’s UEFI. Dual booting Windows with GNU/Linux has become mostly painless. Then there’s Secure Boot. Libre software works with that too. You may still run into issues; I ran into one recently and if someone is in the same position I hope this helps:

    A friend of mine got an Ideapad 3 Gaming laptop (which was preinstalled with Windows 11) and we tried to install Fedora 37 on it (of course, remotely; thanks to screensharing and cameras on mobile phones). The bootable USB pendrive was not being listed in boot options (F12), so we fiddled with TPM & Secure Boot settings in EFI settings (F2). No luck, and troubleshooting eventually concluded that the USB pendrive was faulty. Tried with another one, and this time it was detected, happily installed Fedora 37 (under 15 mins, because instead of spinning Hard Disks, there’s SSD). Fedora boots & works fine.

    A day later, the friend selects Windows to boot into (from grub menu) and gets greeted by a BitLocker message: “Enter bitlocker recovery key” because “Secure boot is disabled”.

    Dang. I thought we re-enabled Secure Boot, but apparently not. Go to EFI settings, and turn it back on; save & reboot; select Windows — but BitLocker kept asking for recovery key but with a different reason: “Secure Boot policy has unexpectedly changed”.

    That led to scrambling & searching, as BitLocker was not enabled by the user but OEM, and thus there was no recovery key in the user’s Microsoft online account (if the user had enabled it manually, they can find the key there).

    The nature of the error message made me conclude that Fedora installation with secure boot disabled has somehow altered the TPM settings and Windows (rightfully) refuses to boot. EFI settings has an option to ‘Restore Factory Keys’ which will reset the secure boot DB. I could try that to remove Fedora keys, pray Windows boots and if it works, recover grub (my specialty) or reinstall Fedora in the worst case scenario.

    Enter Matthew Garret. Matthew was instrumental in making GNU/Linux systems to work with Secure Boot (and was awarded the prestigious Free Software Foundation Award). He is a security researcher who frequently writes about computer security.

    I have sought Matthew’s advice before trying anything stupid, and he suggested thus (reproduced with permission):

    First, how are you attempting to boot Windows? If you’re
    doing this via grub then this will result in the secure boot
    measurements changing and this error occurring – if you pick Windows
    from the firmware boot menu (which I think should appear if you hit F12
    on an Ideapad?) then this might solve the problem.

    Secondly, if the owner added a Microsoft account when setting up the
    Windows system, they can visit
    https://account.microsoft.com/devices/recoverykey and a recovery key
    should be available there.

    If neither of these approaches work, then please try resetting the
    factory keys, reset the firmware to its default settings, and delete any
    Fedora boot entries from the firmware (you can recover them later), and
    with luck that’ll work.

    Thankfully, the first option of booting Windows directly via F12 — without involving grub — works. And the first thing the user does after logging in is back up the recovery keys.

    Advertisement
  • RIT Rachana & MeeraNew fonts version 1.4 released

    November 12th, 2022

    The Malayalam serif font RIT Rachana and its sans-serif counterpart MeeraNew have enjoyed a wide array of improvements in the past months; and are available now for download and use.

    Some notable improvements are listed here:

    1. Entire Malayalam character set defined in Unicode 15, including archaic and vedic characters.
    2. All characters — especially vowel signs — now belong to proper Unicode category GDEF class (thanks to Liang Hai for pointing out the correction), removing a workaround put in place just for Adobe InDesign. This workaround is not required when using HarfBuzz shaping engine (which you should anyway).
    3. Improved design of old-style figures 0, 1 & 2 in RIT-Rachana.
    4. Standalone dependent glyphs of pre-base ra (reph) and below-base la can be displayed with ‘zwj+് +‌ ര/ല’ respectively, useful for informational purpose (when writing a typography specific article, for instance). These characters otherwise always conjoin with the base character.
    Reph and below base La standalone glyphs
    1. Major improvements in shaping rules to adhere to language rules even better: double consonants are always joined properly in context; even for unusual combinations. Correct shaping for below instance can be obtained by adding a ZWNJ before ണ but the advanced shaping rule is smarter to not require encoding corrections.
    Double consonants are shaped first..
    1. Improved underline position (although thou shalt question thyself why use underline in Indic scripts), which is now also respected by LibreOffice 7.5 thanks to Khaled Hosny. This bug was reported many years ago.
    Underline position improved
    1. ന്‍ +‌ ് + റ → ന്റ (Unicode 5.1 atomic chillu nta) support added upon request.

    … kerning improvements and many more tweaks and fine tuning. As usual, both typefaces are free & open source software, available at Rachana website. They will be available shortly in Fedora 36 & 37 as an update.

  • FontForge gains ability to reuse OpenType rules for different fonts

    September 22nd, 2022

    FontForge is the long standing libre font development tool: it can be used to design glyphs, import glyphs of many formats (svg, ps, pdf, …), write OpenType lookups or integrate Adobe feature files, and produce binary fonts (OTF, TTF, WOFF, …). It has excellent scripting abilities, especially Python library to manipulate fonts; which I extensively use in producing & testing fonts.

    When I wrote advanced definitive OpenType shaping rules for Malayalam and build scripts based on FontForge, I also wanted to reuse the comprehensive shaping rules in all the fonts RIT develop. The challenge in reusing the larger set of rules in a ‘limited’ character set font was that FontForge would (rightly) throw errors that such-and-such glyph does not exist in the font and thus the lookup is invalid. For instance, the definitive OTL shaping rules for Malayalam has nearly 950 glyphs and lookup rules; but a limited character set font like ‘Ezhuthu’ has about 740 glyphs.

    One fine morning in 2020, I set out to read FontForge’s source code to study if functionality to safely skip lookups that do not apply to a font (because the glyphs specified in the lookup are not present in the font, for instance) can be added. Few days later, I have modified the core functionality and adapted the Python interface (specifically, the Font.mergeFeature method) to do exactly that, preserving backward compatibility.

    Next, it was also needed to expose the same functionality in the graphical interface (via File→Merge Feature info menu). FontForge uses its own GUI toolkit (neither GTK nor Qt); but with helpful pointers from Fredrick Brennan, I have developed the GUI to take a flag (default ‘off’ to retain backward compatibility) that allows the users to try skipping lookup rules that do not apply to the current font. In the process, I had to touch the innards of FontForge’s low-level code and learn about it.

    Fig. 1: Fontforge now supports skipping non-existent glyphs when merging a comprehensive OpenType feature file.

    This worked fine for our use case, typically ignoring the GSUB lookups of type sub glyph1 glyph2 by glyph3 where glyph3 does not exist in the font. But it did not properly handle the cases when glyph1 or glyph2 were non-existent. I’ve tried to fix the issue but then was unable to spend more time to finish it as Real Life™ caught up; c’est la vie. It was later attempted as part of Free Software Camp mentoring program in 2021 but that didn’t bear fruit.

    A couple of weeks ago, Fred followed up now that this functionality is found very useful; so I set aside time again to finish the feature. With fresh eyes, I was able to fix remaining issues quickly, rebase the changes to current master and update the pull request.

    The merge request has landed in FontForge master branch this morning. There’s a follow up pull request to update the Python scripting documentation as well. I want to thank Fredrick Brennan and Jeremy Tan for the code reviews and suggestions, and KH Hussain and CVR for sharing the excitement.

    This functionality added to FontForge helps immensely in reusing the definitive Malayalam OpenType shaping rules without any modification for all the fonts! 🎉

1 2 3 … 29
Next Page→

Blog at WordPress.com.

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy
 

Loading Comments...
 

    • Follow Following
      • Soliloquies
      • Join 25 other followers
      • Already have a WordPress.com account? Log in now.
      • Soliloquies
      • Edit Site
      • Follow Following
      • Sign up
      • Log in
      • Report this content
      • View site in Reader
      • Manage subscriptions
      • Collapse this bar