markdown=true in HTML tags is ignored

[silverhook]

I am having issues with markdown=true being ignored in HTML tags. Sometimes I need to make use of <details><summary> and it comes very hand there. Lately I noticed that markdown is being ignored in there

E.g. the following <details> section from https://matija.suklje.name/backups-and-btrfs-raid1#add-a-new-device gets really garbled as can be seen in the screenshot (and the link itself).

What’s further odd is that the "```" was translated into a code block, but nothing else was taken into account.

<details markdown=true>
<summary>Expand if you are curious about how **removing and re-creating the swap partition caused me over two days of fixing the mess**.</summary>

While the gurus at Btrfs assured me it would totally work, if I just had two differently-sized Btrfs partitions put into one RAID1, as long as I do not care some part of the larger partition will not be used, I still wanted to try to resize the partitions on Goodram SSD.

Did I ignore this good advice?

Oh yes!

I am not a total maniac though, so just in case, before I did anything, I made backups, and ran both `btrfs scrub` and `btrfs balance` (within [Btrfs Assistant][btrfs_assistant], so I do not mess anything up).

The big complication here is that this is a multi-step approach, depending on many tools, as one needs to resize the LUKS partition as well as Btrfs within it, and _there are several points where one can mess up things royally_, ending with a corrupt file system.

One option would be to go the manual way through CLI commands and risk messing up myself.

The other option would be to use a GUI to make things easier, but risk that the GUI did not anticipate such a complex task and will mess things up.

After much back and forth, I still **decided to give [KDE Partition Manager][kdepm] a go** and see if I can simply resize a Btrfs partition within LUKS there. In the worst case, I already had backups.

… and here is where I messed things up.

!!! note "Mea culpa!"

    Honestly, I would have messed things up the same way if I did it in CLI.

    If anything, I am impressed how well [KDE Partition Manager][kdepm] handled such a complex task in a very intuitive fashion.

What I did then was:

1. Resized luks+btrfs (`nvme0n1p2`) on Goodram to be 20 GiB smaller – this is where I thought things would break, but KDE Partition Manager handled it fine. But now I had 20 GiB of unused disk space between `nvme0n1p2` (btrfs) and `nvme0n1p3` (swap).
1. To fix this I decided to simply remove the swap (`nvme0n1p3`) and create a new one to fill the whole remaning space.
1. (While I was at it, I added and changed a few partition labels, but that did not affect anything.)

So, I ended up with:

**Goodram PX500**:

| partition     | size         | file system    | mount point   |
|---------------|-------------:|----------------|---------------|
| unallocated   |     1,00 MiB | unallocated    |               |
| nvme0n1p1     | 1.000,00 MiB | fat32          | /boot/efi     |
| nvme0n1p2     |   924,55 GiB | btrfs (luks)   | /             |
| nvme0n1p3     |    28,34 GiB | swap (luks)    | swap          |


**Samsung 970 Evo Plus**:

| partition     | size         | file system    | mount point       |
|---------------|-------------:|----------------|-------------------|
| nvme1n1p1     | 1.000,00 MiB | fat32          | /mnt/backup_efi   |
| nvme1n1p2     |   920,77 GiB | btrfs (luks)   |                   |
| nvme1n1p3     |     9,77 GiB | swap (luks)    | swap              |


At first things were peachy fine.

… and then I rebooted and was greeted with several pages of Dracut essentially warning me that it cannot open an encrypted partition.

![Several lines of dracut-initqueue warnings about a hook timing out.]({static}/images/slimbook/dracut_complaint_1.jpg)
![Dracut gives up and offers logging into an emergency shell.]({static}/images/slimbook/dracut_complaint_2.jpg)

So what happened was that I forgot that since I removed and re-created `nvme0n1p3` (swap), it now has a different UUID – which is why Dracut could not find it. 😅

After much trial and error and **massive** help from _TC_, we managed to identify the problem and solution through the emergency shell. It would have been possible to do that – and probably faster – by booting from LiveUSB too, but both TC and I were already deeply invested and had (some kind of twisted) fun doing it the emergency shell[^no_editor].  Luckily the Btrfs partition got unencrypted, so we could use `chroot`.

[^no_editor]: The emergency shell was quite a pain, as it did not even have a text editor. So we had to be creative.

Long story short, this was the solution:

1. Reboot and in GRUB edit the boot command to remove the non-existing swap partition from the kernel line.
1. Wait during boot that systemd gives up on the non-existing swap partition.
1. When in my normal system `sudoedit /mnt/rootfs/etc/crypttab` and `sudoedit /mnt/rootfs/etc/fstab` to change the UUID of the encrypted swap partition to the new partition’s UUID.
1. `sudoedit /etc/dracut.conf.d/calamares-luks.conf` to change the swap partition’s UUID for the new one.
1. `sudo dracut-rebuild`
1. `sudoedit /etc/default/grub` – specifically the `GRUB_CMDLINE_LINUX_DEFAULT` line – to change the swap partition’s UUID for the new one, as well as make sure every LUKS-encrypted partition’s UUID has a `rd.luks.uuid=` entry there.
1. `sudo grub-install` (just in case) and `sudo grub-mkconfig`.
1. Reboot 😄

There was another self-caused issue that took me way too long to figure out, until someone on the `#btrfs` IRC channel pointed it out. I **forgot the closing `'`** in the `linux` (a.k.a. “kernel”) line in GRUB, which is why `grub-install` would fail me,  complaining about `GRUB_ENABLE_CRYPTODISK=y` missing, while it was clearly there in `/etc/default/grub`. I just had to add that `'` at the end of `GRUB_CMDLINE_LINUX_DEFAULT` in `/etc/default/grub` and GRUB was happy again.

That was essentially the big oops and how it got fixed.

In the now my `/etc/dracut.conf.d/*` looks like:
[…]

This used to work fine before. But I recently moved my blog from one server (Pelican 4.7.1 on Armbian @ ARM) to another one (Pelican 4.9.1 on YuNoHost @ AMD64), so it’s hard to tell what could have caused this issue.

Looking forward to suggestions how I should fix this. I’m 90% sure it’s a problem on my end, but I haven’t figured out what yet.

[avaris]

Not included a markdown extension: md_in_html?

[avaris]

I don't personally use it so not sure, but extension documentation says it should be <summary markdown="1"> (not true).

[silverhook]

I’d assume them to be equal, but I’ll try "1" too.

[silverhook]

That did in fact fix it, thanks, @avaris !

[leekimber]

Funny, I drafted out almost the same question two weeks ago but found a possible way through just seconds before hitting the 'FGS Help Me!' button. So passing the following on in case it helps.

I found md_in_html wasn't necessary because apparently it is a pelican default. My pelicanconf.py now contains:

# Below from:
# https://docs.getpelican.com/en/stable/settings.html#basic-settings
# and some details from:
# https://jackdewinter.github.io/2019/10/16/fine-tuning-pelican-markdown-configuration/#markdownextensionsextra
# to enable markdown (wrapped) in HTML:
# https://python-markdown.github.io/extensions/md_in_html/
MARKDOWN = {
    'extension_configs': {
        'markdown.extensions.extra': {},
        'markdown.extensions.meta': {},
    },
    'output_format': 'html5',
}
# Next line temp removed while testing result
#        'markdown.extensions.codehilite': {'css_class': 'highlight'},
# About the above:
# https://github.com/getpelican/pelican/issues/2091 has things to say about format

And I'm not sure how much of that is necessary. It seems to be the stock MARKDOWN dict that shows up in response to questions about pelican's markdown extensions.

I also found I needed

markdown="1"

as the last element of every block-level tag before any markdown content. Testing so far shows that if any one block-level tag is missing 'markdown="1"', then any subsequent HTML-wrapped markdown doesn't get parsed by python-markdown correctly.

From reading around, I gather there is nuance to how different markdown parsers implement #markdown="1" directives.

I'm using it to rough out a pelican webslides theme so there are many, many <section> and <div> tags presenting many, many opportunities for 'markdown="1"' nuances to discard their nuance. :)

[silverhook]

as the last element of every block-level tag before any markdown content. Testing so far shows that if any one block-level tag is missing 'markdown="1"', then any subsequent HTML-wrapped markdown doesn't get parsed by python-markdown correctly.

Yes, that is a bit annoying, agreed.