Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On Wed Apr 24, 2024 at 1:50 PM BST, Richard wrote: > upon gathering my thoughts for answering to you I found the solution to > this: update-initramfs can't handle the case that crypttab ends in the line > of the last entry and not in a new line character. I think there either > should be a fix for this or at least a way to handle this case with a much > clearer error message. So I'll probably open a bug report for the package > and the maintainer can decide if that should be forwarded upstream. Such a > rather trivial case shouldn't be resulting in such fatal errors. That's very interesting. I'd definitely suggest filing a bug for this, if there isn't one already. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On 26/04/2024 12:56, David Wright wrote: On Fri 26 Apr 2024 at 11:27:24 (+0900), John Crawley wrote: Innocent question: what difference does the comment make vs just ending the file with an empty line? Nothing for the computer, but visibility for me. Say you print the file on paper. All you see is white space after the end of the printed text. Is there an empty line? Or take, for instance, my example above, and think back to those VDUs, as we called them, where the firmware added a newline as soon as the cursor reached the right side of the screen, without waiting to see whether the next character was itself a newline or not.¹ So using an empty line approach, you might find yourself looking at a screen like: Last character position on the screen ---↓ swap LABEL= … … … … … … … … … … … … … … … … … … … … … =512 $ Now, is that an empty line before the prompt, or did the terminal add the extra newline itself because the swap line was exactly 80 characters long? Thanks! And nano is worse: to know you've reached the bottom, you have to check the cursor doesn't advance when you pound on the downarrow key. Yes, that's what I usually do. :) -- John
Last line [was: Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition]
On 26/04/2024 10:56, David Wright wrote: Editor examples: a windowed emacs buffer has a ≣ decoration at the extreme left edge after the last line of text, so that you can distinguish an absence of lines from empty lines. Perhaps that decoration should be explicitly enabled. However it reminded me the following: (info "(elisp) Library-Headers") https://www.gnu.org/software/emacs/manual/html_node/elisp/Library-Headers.html "D.8 Conventional Headers for Emacs Libraries" ‘;;; filename ends here’ This is the footer line; it appears at the very end of the file. Its purpose is to enable people to detect truncated versions of the file from the lack of a footer line. As to some ignored line at the end of a file: https://mywiki.wooledge.org/BashFAQ/005#Handling_newlines_.28or_lack_thereof.29_at_the_end_of_a_file "2.1.1. Handling newlines (or lack thereof) at the end of a file" in BASH FAQ "How can I use array variables?" `read` returns false when it reads the last line of a file. This presents a problem: if the file contains a trailing newline, then read will be false when reading/assigning that final line, otherwise, it will be false when reading/assigning the last line of data. Without a special check for these cases, no matter what logic is used, you will always end up either with an extra blank element in the resulting array, or a missing final element.
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On Fri 26 Apr 2024 at 11:27:24 (+0900), John Crawley wrote: > On 24/04/2024 22:37, David Wright wrote: > > On Wed 24 Apr 2024 at 14:50:36 (+0200), Richard wrote: > > > upon gathering my thoughts for answering to you I found the solution to > > > this: update-initramfs can't handle the case that crypttab ends in the > > > line > > > of the last entry and not in a new line character. I think there either > > > should be a fix for this or at least a way to handle this case with a much > > > clearer error message. So I'll probably open a bug report for the package > > > and the maintainer can decide if that should be forwarded upstream. Such a > > > rather trivial case shouldn't be resulting in such fatal errors. > > > > Some time at the end of the last century, I remember some startup script > > that cat'd its configuration file for that very reason. It taught me > > the habit of always finishing files with a blank comment line: > > > > $ cat /etc/crypttab > > # > > swapLABEL=cryptswap /dev/urandom > > swap,offset=2048,cipher=aes-xts-plain64,size=512 > > # > > $ > > > > Innocent question: what difference does the comment make vs just ending the > file with an empty line? Nothing for the computer, but visibility for me. Say you print the file on paper. All you see is white space after the end of the printed text. Is there an empty line? Or take, for instance, my example above, and think back to those VDUs, as we called them, where the firmware added a newline as soon as the cursor reached the right side of the screen, without waiting to see whether the next character was itself a newline or not.¹ So using an empty line approach, you might find yourself looking at a screen like: Last character position on the screen ---↓ swap LABEL= … … … … … … … … … … … … … … … … … … … … … =512 $ Now, is that an empty line before the prompt, or did the terminal add the extra newline itself because the swap line was exactly 80 characters long? Editor examples: a windowed emacs buffer has a ≣ decoration at the extreme left edge after the last line of text, so that you can distinguish an absence of lines from empty lines. However, a non-windowed emacs in an xterm has no such decoration: you have to provoke an "end of buffer" message to be certain where the file ends. And nano is worse: to know you've reached the bottom, you have to check the cursor doesn't advance when you pound on the downarrow key. ¹ IIRC, there's a terminfo capability, am, to work around this. Cheers, David.
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On 24/04/2024 22:37, David Wright wrote: On Wed 24 Apr 2024 at 14:50:36 (+0200), Richard wrote: upon gathering my thoughts for answering to you I found the solution to this: update-initramfs can't handle the case that crypttab ends in the line of the last entry and not in a new line character. I think there either should be a fix for this or at least a way to handle this case with a much clearer error message. So I'll probably open a bug report for the package and the maintainer can decide if that should be forwarded upstream. Such a rather trivial case shouldn't be resulting in such fatal errors. Some time at the end of the last century, I remember some startup script that cat'd its configuration file for that very reason. It taught me the habit of always finishing files with a blank comment line: $ cat /etc/crypttab # swapLABEL=cryptswap /dev/urandom swap,offset=2048,cipher=aes-xts-plain64,size=512 # $ Innocent question: what difference does the comment make vs just ending the file with an empty line? -- John
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On Wed 24 Apr 2024 at 14:50:36 (+0200), Richard wrote: > upon gathering my thoughts for answering to you I found the solution to > this: update-initramfs can't handle the case that crypttab ends in the line > of the last entry and not in a new line character. I think there either > should be a fix for this or at least a way to handle this case with a much > clearer error message. So I'll probably open a bug report for the package > and the maintainer can decide if that should be forwarded upstream. Such a > rather trivial case shouldn't be resulting in such fatal errors. Some time at the end of the last century, I remember some startup script that cat'd its configuration file for that very reason. It taught me the habit of always finishing files with a blank comment line: $ cat /etc/crypttab # swapLABEL=cryptswap /dev/urandom swap,offset=2048,cipher=aes-xts-plain64,size=512 # $ Cheers, David.
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
Hi Michel, upon gathering my thoughts for answering to you I found the solution to this: update-initramfs can't handle the case that crypttab ends in the line of the last entry and not in a new line character. I think there either should be a fix for this or at least a way to handle this case with a much clearer error message. So I'll probably open a bug report for the package and the maintainer can decide if that should be forwarded upstream. Such a rather trivial case shouldn't be resulting in such fatal errors. Best Richard On Wed, Apr 24, 2024, 14:23 Michel Verdier wrote: > On 2024-04-23, Richard wrote: > > > luks-775ea946-6797-4c4d-a042-72924309f3d2 > > UUID=775ea946-6797-4c4d-a042-72924309f3d2 /crypto_keyfile.bin > > luks,keyscript=/bin/cat > > luks-78362aa3-760c-41de-b911-6531b684e3f7 > > UUID=78362aa3-760c-41de-b911-6531b684e3f7 /crypto_keyfile.bin > > luks,keyscript=/bin/cat > > initramfs extract line from /etc/crypttab to create its own crypttab > as you have seen in main/cryptroot/crypttab, and only for rootfs, not for > swap > > > Now, is this a bug in the package or am I missing something? And how do I > > create a working initramfs now? > > swap is usually mounted after rootfs is mounted, thus using > /etc/crypttab. If you want to resume from swap you have to follow > paragraph 2.2.1 on > https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption > > If you don't need to resume you can follow the much easier chapter 1 on > the same url, using /dev/urandom as a keyfile. > > >
