- This topic has 6 replies, 3 voices, and was last updated Aug 2-5:32 pm by olsztyn.
-
Posts
-
olsztyn
Currently, when initiating Live boot pointing to HD (from=hd) encrypted antiX partition, such boot results in a Fatal Error as it cannot find antiX/linuxfs and message:
”
Please contact BitJam at https://www.antixforum.com/
p=power off
r=reboot
”
This is because linuxfs cannot be found on an encrypted antiX partition and no decrypt key passphrase is provided.
It would be beneficial for an additional boot parameter to be implemented, namely to provide decrypting passphrase to the existing boot parameter ‘from=hd’, such as ‘pass=xxxxxx’.Current behavior exists both with the antiX 19 and Bullseye B1.
Considering great enhancements introduced in Bullseye B1 regarding finding all Frugal instances in addition to previously covered Grub entries, such support for finding and booting encrypted partition would be great to have, if not in antiX 19, then at least in antiX Bullseye B2…
This is just a kind request…
Thanks and Regards…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters
Xecure
I don’t think this would be as easy as you think. from=<list> will check each partition (first mounting it) of the devices listed to see if the file(s)/folder(s) it is looking for is/are present.
See the init function for finding files/folders. If it cannot mount a partition, it will ignore it (except if it a LUKS encrypted partition already configured). Imagine, if it has to check each partition, see if it can mount it, if it cannot, then it needs to figure out what encryption it is using, and then ask (for each encrypted partition) for the password to decrypt it. It is the least desirable thing a user wants to go through just to boot from their system.I think first we need to figure out what modules are needed for each kind of encryption method, figure out all the functions that the live init uses to check for encryption or identify partitions, and then explore how to add support for other encryption configurations. I would create a new boot option (like crypt=check) to specifically ask to not ignore encrypted partitions. And we would also need another boot option to provide the password, but it would be a headache (in my option), as at the boot menus (specifically in grub), the only valid keyboard layout IS the US layout (so the rest of us with different layout can go and cry in a corner).
As you see, it is not so easy.
When I say we, I mean you, me and others that are interested in these new options. Open source means that the source is available to anyone to explore and modify to what we want/need. The dev team is too small and they have more important things to do and test right now (like the betas for both antiX/MX).
antiX Live system enthusiast.
General Live Boot Parameters for antiX.Thank you Xecure for detailed assessment. It is greatly appreciated.
I understand (I think I do) this is not as simple as it seems. Admittedly, I did not think of variety of encryption schemes and configurations but rather was thinking of antiX default luks 1, as currently used used by antiX when creating encrypted luks partition by Live-USB-Maker and the most common use cases applicable to antiX implementations. So I apologize for not being specific.
Also, I do understand that antiX development team is small and there are more important priorities targeting strategic antiX direction and more common needs of antiX user base than such niche as encrypted antiX implementations. So I do not expect anything any time soon if considered at all. This was just for consideration.
Having said this, there was a reason I brought up the current use case, when booting antiX Live and pointing to an encrypted Live partition as outlined in my post, which too quickly led me to a more general request, not taking into account a myriad of configurations you outlined.
Namely:
– Pointing to an encrypted antiX instance from typical Live media (typical unencrypted setup), such as from=hd results in Fatal Error as it is not able to find antiX/linuxfs and asks to contact BitJam at http://www.linuxforum.com.
– Pointing to an encrypted antiX instance from antiX Live media set up as encrypted (so it included ‘encrypted’ text file with UUID, and again using e.g. from=hd: This results in much more expected behavior as it finds the antiX luks1 encrypted partition (such as sda3) and asks for encryption passphrase, upon which it proceeds to booting that partition.
– Complication arises though when kernel version initially used to boot (so the one on boot media) does not exactly match the one originally configured with linuxfs on the encrypted partition. The message comes back with ‘Kernel mismatch’ and in addition to the options ‘p’ and ‘r’ as above, the third option ‘c’ allows to continue. In this scenario the error message does not direct the user to contact BitJam though…
Selecting ‘c’ continue option, when there is a kernel version mismatch likely results in problematic desktop, so not quite optimal result.Having described the above use cases with their corresponding results I think that there are some opportunities to be perfected, not having in mind covering a myriad of booting configurations of encrypted partitions, but rather simple cases:
– Allow any Live boot media (including not initially set up as encrypted) to be pointed to an encrypted luks1 partion and ask for passphrase.
– Allow Live boot media (regardless of version of kernel with which initally booted) to boot linuxfs, where kernel associated with such linuxfs might be a different version.Regarding the second point above, which would resolve the ‘kernel mismatch’ boot error, I remember there was a discussion (late 2019), where BitJam explained that such scenario worked fine when including redundant vmlinuz files representing different kernel versions used by antiX, so matched kernel versions were found, therefore assuring successful booting in encrypted scenario.
Long story short, if there are low hanging fruits, where with relatively little configuration change of boot files, such boot process for encrypted partitions can be made more capable then this would be my modest request as originally intended.
This is kind of on the heels of similar improvements implemented in Bullseye antiX b1, with capability of discovering Frugal instances and presenting menu of them to boot as well as providing multiple kernel versions to chose for booting… Although understandably this was not the same level of difficulty…Thanks again Xecure and Regards…
- This reply was modified 1 year, 9 months ago by olsztyn.
- This reply was modified 1 year, 9 months ago by olsztyn.
Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters
anticapitalista
When you say ‘any Live boot media’ do you mean non-antiX based distros?
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
When you say ‘any Live boot media’ do you mean non-antiX based distros?
No, just antiX Live boot media, such as created with Live-USB-Maker. Sorry, I thought it was implied…
Additional clarification:
If inclusion of word ‘any’ caused such question, just want to further explain the reason for such inclusion:
E.g. Suppose we have Live antiX created on SATA hard disk via Live-USB-Maker –force=usb option. Such antiX Live install on SATA can be booted directly from HD or from ANY Live antiX USB stick, with ‘from=hd’ boot option. This is one of examples of flexibility of antiX after all…
Thanks and Regards.- This reply was modified 1 year, 9 months ago by olsztyn.
Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parametersanticapitalista
OK.
I’m very busy at the moment, but when I get time I’ll take a look and also let BitJam know.Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Thanks much for attention. Understandably there are more pressing and more strategic priorities. However with some progress in this area made in Bullseye antiX Live, such as inclusion of multiple choice of kernels to choose for booting, etc., it is already going in the direction of getting antiX to the level of ultimate perfection… In Live technology nothing comes close to antiX after all…
Regards.Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters
- You must be logged in to reply to this topic.
