YunoHost / issues

General issue tracker for the YunoHost project
71 stars 8 forks source link

Impossible to setup /boot & LUKS+LVM #1783

Open stdedos opened 3 years ago

stdedos commented 3 years ago

Using your image (https://yunohost.org/en/install/hardware:virtualbox), and the instructions from https://unix.stackexchange.com/a/577765/266638, it's impossible to achieve this:

image

image

Your result: image

zamentur commented 3 years ago

We have released recently some new images, we are not sure the new image fix this bug (we targeted an other one) but it may fix it ... Could you try with the new iso ?

JOduMonT commented 3 years ago

@stdedos you could install Debian with luks than yunohost on top of it; Debian handle pretty well this kind of situation.

or you could click on Continue and try...

mount your brand new partition and load your new system

# mount /dev/mapper/*--vg-root /target
# for n in proc sys dev etc/resolv.conf; do mount --rbind /$n /target/$n; done 
# chroot /target
# mount -a

Install cryptsetup for init

apt install -y cryptsetup-initramfs

define your partition in crypttab

echo "${DM}2_crypt UUID=$(blkid -s UUID -o value ${DEVP}2) none luks,discard" >> /etc/crypttab

update initram

update-initramfs -u -k all

exit your chroot and reboot

exit
reboot
stdedos commented 3 years ago

We have released recently some new images, we are not sure the new image fix this bug (we targeted an other one) but it may fix it ... Could you try with the new iso ?

No, it didn't. While it's not a problem for me to have tested, I don't think it's so hard for you to test it from your side either (as I assume the instructions provided are abundantly clear).

you could install Debian with luks than yunohost on top of it; Debian handle pretty well this kind of situation.

Sounds like a solution; however, your image appears to be in-operational. I don't know if that's because it's a little outdated (missing bugfixes), or you did something to the installer, breaking it (I am really not familiar with rebranding an OS, so don't send me dumpster diving.)

Anyhow, this is more of an FYI for you; it seems that for myself I got my workaround.

or you could click on Continue and try...

I didn't get the latter part. While the instructions seem very hack-fu, I am unable to follow how do they interact with my problem. If I click "Continue" after I failed to configure encrypted volumes, then there's nothing - I am back to the drive. You are providing terminal commands, which I don't know how to execute with the GUI installation, neither how do they interact with it.

JOduMonT commented 3 years ago

I didn't get the latter part. While the instructions seem very hack-fu, I am unable to follow how do they interact with my problem. If I click "Continue" after I failed to configure encrypted volumes, then there's nothing - I am back to the drive. You are providing terminal commands, which I don't know how to execute with the GUI installation, neither how do they interact with it.

It is not Hack-Fu, it's simply fixing a boot issue because the GRUB is unable to install ;) Yes these are command line and Yes my after you click "Continue" comment is based on your screenshot.

BTW: Why you want to encrypt your partition ? I mainly ask because whenever the system is running, this encryption is decrypted. While it limit people to reboot the machine and accessing your files from a Live OS, it won't protect your data from remote attack. It is also painfull whenever you have to reboot your server remotely and nobody is their to type de LUKS password ;)

stdedos commented 3 years ago

It is not Hack-Fu, it's simply fixing a boot issue because the GRUB is unable to install ;)

I am not even there; hence my confusion.

Yes my after you click "Continue" comment is based on your screenshot.

Uhm, no - after I click "Continue" I am back on the partitioning screen. I could do a video to prove it to you, if you insist.

BTW: Why you want to encrypt your partition ?

Exactly my point:

While it limit people to reboot the machine and accessing your files

Encrypted-at-rest.

It is also painfull whenever you have to reboot your server remotely and nobody is their to type de LUKS password ;)

Uhm, no it isn't 😛 You need to have faith in your computer.

JOduMonT commented 3 years ago

I could do a video to prove it to you, if you insist.

No need to do a video, I should be the one to make a video to help you more than just spreading my ancestral memories.

Uhm, no it isn't stuck_out_tongue You need to have faith in your computer. :P I'll start with the human

Believe me, I've had this kind of discussion before, like having a keypass file on a USB stick and testing it over and over again before going on a trip and then the day came, a power outage that lasted too long, my UPS shut down my server and restarted it and, well my USB stick with the keypass file was never recovered. Since then, I humbly try to consider what others says.

zamentur commented 2 years ago

Thanks for reporting this issue.

No, it didn't. While it's not a problem for me to have tested, I don't think it's so hard for you to test it from your side either (as I assume the instructions provided are abundantly clear).

Yes however the image release was not totally binded to this topic (but on an other grub issue), that's why i asked you. I can indeed test that on my side, however it take time and if i do that with all tickets on this bug tracker it will take me 3months instead of just 20hour to read and sort all this tickets ^^

But now, we know that there is an issue, and maybe one day someone will try to fix this issue. (Sadly, make easier encrypted server is not our top priority currently).