Hi there,
during a fresh installation of MX-17 I've noticed a couple of things, which I think I should report to you.
First, a minor one: although user/root passwords are entered after the desired keyboard layout is chosen, when you type them in the default (i.e. 'us', I guess) keyboard layout is actually used; therefore, if you enter special characters and don't check the 'show password' box you won't notice that, and eventually find yourself locked out after reboot (which is what happened to me).
Then, a (IMHO) not so minor thing: I chose to encrypt the /home folder but I found out that, while the swap partition had actually been encrypted, the /home/<username> folder hadn't. As a matter of fact, I found
a) /home/.ecryptfs/<username>/.ecryptfs/ folder, which was empty, and
b) /home/<username> unencrypted folder
Having noticed that, I repeated the installation more than once, to make sure I didn't make mistakes, and unfortunately the results have always been the same. On a side note, I'd like to add that encrypting the home folder with 'ecryptfs-migrate-home' afterwards did work.
Finally, I'd like to point out that I've been using the 'MX-17_x64.iso' released on 15 December 2017.
TIA
Leo
MX-17 installer issues (passwords/encryption)
Re: MX-17 installer issues (passwords/encryption)
I can not confirm the thing with the keyboard layout and special characters in passwords, as it
has been in many occasions everywhere... just don't use special characters ;-)
My issue was another one, and that was that the keyboard layout was never set to
de-latin1-nodeadkeys, neither in the life system nor in an installed instance. While the life-image
has the corresponding file in its squashfs, it never finds its way onto an installation file system.
Even in the life system, i did not find a way (neither console nor under X11) to get that layout
activated. In an installed instance only after installing the Trinity Desktop my desired keyboard
layout became available.
Also the default layout imposed some nasty mapping with my actual keyboard; for instance I found
three(!!!) keys by which the '\' and '|' characters could be typed, but not a single one which provided
me with a '=' character, leaving me bar the possibility to even edit config files or defining aliases in
the shell.
And yeah, the encryption thing is really nasty... I didn't really look for an ecryptfs feature, as the
only user on my systems is the same person that is root, and thus cryptsetup is the better option
and the one i'm used to, indeed.
Seeing that the swap is encrypted via cryptsetup, I wonder why the same isn't at least an option
for /home, possibly also with a user-supplied key that is _not_ stored in the system configs, so
that it must be entered (or as a keyfile provided on a USB thumb drive or SD card or whatever),
when the system boots. That is invaluable for portable devices in case of loss or theft. (Of course
ecryptfs is an alternative for those used to it... when it works...)
The partitioning policy is completely nuts... i can custom-partition via gparted, and even format
the filesystems like i desire, but the rest of the installer happily ignores my choices and forces
me to format all partitions (except swap, of course) again using any one of a choice of filesystem
types, but that one for each and every partition... nobody needs (or even wants) journaling on
/boot (but fortunately, /boot isn't supported as a filesystem on its own), but it's a feature of choice
for at least user data, that continuously change, and may be suitable for system fs like /var and
even for /usr in case a large update goes wrong...
The choice of swap is also poor, either a new one can be created (which is apparently not accepted
when there are others on the system (but i tried that only once, because they became encrypted
during the process, which could render another installed OS, which is currently in hibernation,
unwakeable).
Another danger could come from an LVM volume group for several VMs running under Xen (or
whatever), which all have (and need) their own swap LV/partition and don't want an installer in
another VM just claim all present swaps for itself, thereby crashing the already running VMs...
But ... again fortunately ... MX Linux doesn't support LVM (at least not at this level).
Would it be so hard to implement a simple GUI pane where one can select per partition the
file system type and where to mount it, whether to reformat at all, etc?
Honestly, with this installer I feel like back in 1995...
There are many other issues, the (maybe) most important being, that not even sshd is available
in an installed instance (didn't check the life, but i can make an educated guess). It's not just
not activated, it's not even installed... But Samba, yeah, Samba is important... :-/ Did I mention
1995 already?
And I wonder, why most everyone just ignores this thread... ~200 views? I'm pretty sure that my
"little" contribution goes likewise unnoticed, but I've gotta take a chance ;-)
Seriously, I had big hope with MX Linux, but these issues should be worked over. The best point
of this distro (from my pov) is its systemd avoidance. +1 for that. But there are many things to
do (not even speaking about the oh-so-powerful MX tools :-/
BTW, where can i find the sources of minstaller? I'd like to take a look to see if I could contribute
the one or another improvement to it, just instead of only complaining...
have a nice time, til then...
has been in many occasions everywhere... just don't use special characters ;-)
My issue was another one, and that was that the keyboard layout was never set to
de-latin1-nodeadkeys, neither in the life system nor in an installed instance. While the life-image
has the corresponding file in its squashfs, it never finds its way onto an installation file system.
Even in the life system, i did not find a way (neither console nor under X11) to get that layout
activated. In an installed instance only after installing the Trinity Desktop my desired keyboard
layout became available.
Also the default layout imposed some nasty mapping with my actual keyboard; for instance I found
three(!!!) keys by which the '\' and '|' characters could be typed, but not a single one which provided
me with a '=' character, leaving me bar the possibility to even edit config files or defining aliases in
the shell.
And yeah, the encryption thing is really nasty... I didn't really look for an ecryptfs feature, as the
only user on my systems is the same person that is root, and thus cryptsetup is the better option
and the one i'm used to, indeed.
Seeing that the swap is encrypted via cryptsetup, I wonder why the same isn't at least an option
for /home, possibly also with a user-supplied key that is _not_ stored in the system configs, so
that it must be entered (or as a keyfile provided on a USB thumb drive or SD card or whatever),
when the system boots. That is invaluable for portable devices in case of loss or theft. (Of course
ecryptfs is an alternative for those used to it... when it works...)
The partitioning policy is completely nuts... i can custom-partition via gparted, and even format
the filesystems like i desire, but the rest of the installer happily ignores my choices and forces
me to format all partitions (except swap, of course) again using any one of a choice of filesystem
types, but that one for each and every partition... nobody needs (or even wants) journaling on
/boot (but fortunately, /boot isn't supported as a filesystem on its own), but it's a feature of choice
for at least user data, that continuously change, and may be suitable for system fs like /var and
even for /usr in case a large update goes wrong...
The choice of swap is also poor, either a new one can be created (which is apparently not accepted
when there are others on the system (but i tried that only once, because they became encrypted
during the process, which could render another installed OS, which is currently in hibernation,
unwakeable).
Another danger could come from an LVM volume group for several VMs running under Xen (or
whatever), which all have (and need) their own swap LV/partition and don't want an installer in
another VM just claim all present swaps for itself, thereby crashing the already running VMs...
But ... again fortunately ... MX Linux doesn't support LVM (at least not at this level).
Would it be so hard to implement a simple GUI pane where one can select per partition the
file system type and where to mount it, whether to reformat at all, etc?
Honestly, with this installer I feel like back in 1995...
There are many other issues, the (maybe) most important being, that not even sshd is available
in an installed instance (didn't check the life, but i can make an educated guess). It's not just
not activated, it's not even installed... But Samba, yeah, Samba is important... :-/ Did I mention
1995 already?
And I wonder, why most everyone just ignores this thread... ~200 views? I'm pretty sure that my
"little" contribution goes likewise unnoticed, but I've gotta take a chance ;-)
Seriously, I had big hope with MX Linux, but these issues should be worked over. The best point
of this distro (from my pov) is its systemd avoidance. +1 for that. But there are many things to
do (not even speaking about the oh-so-powerful MX tools :-/
BTW, where can i find the sources of minstaller? I'd like to take a look to see if I could contribute
the one or another improvement to it, just instead of only complaining...
have a nice time, til then...
Re: MX-17 installer issues (passwords/encryption)
Honestly, with this installer I feel like back in 1995...
If you hate the installer and feel obligated to make fun of MX Tools, then this is probably not the distro for you.But there are many things to
do (not even speaking about the oh-so-powerful MX tools :-/
Production: 5.10, MX-23 Xfce, AMD FX-4130 Quad-Core, GeForce GT 630/PCIe/SSE2, 16 GB, SSD 120 GB, Data 1TB
Personal: Lenovo X1 Carbon with MX-23 Fluxbox
Other: Raspberry Pi 5 with MX-23 Xfce Raspberry Pi Respin
Personal: Lenovo X1 Carbon with MX-23 Fluxbox
Other: Raspberry Pi 5 with MX-23 Xfce Raspberry Pi Respin
- anticapitalista
- Developer
- Posts: 4284
- Joined: Sat Jul 15, 2006 10:40 am
Re: MX-17 installer issues (passwords/encryption)
anticapitalista
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
- dolphin_oracle
- Developer
- Posts: 22111
- Joined: Sun Dec 16, 2007 12:17 pm
Re: MX-17 installer issues (passwords/encryption)
we have already re-done the keyboard setup within the system and it will debut soon with the new installerfbc wrote:I can not confirm the thing with the keyboard layout and special characters in passwords, as it
has been in many occasions everywhere... just don't use special characters ;-)
My issue was another one, and that was that the keyboard layout was never set to
de-latin1-nodeadkeys, neither in the life system nor in an installed instance. While the life-image
has the corresponding file in its squashfs, it never finds its way onto an installation file system.
Even in the life system, i did not find a way (neither console nor under X11) to get that layout
activated. In an installed instance only after installing the Trinity Desktop my desired keyboard
layout became available.
Also the default layout imposed some nasty mapping with my actual keyboard; for instance I found
three(!!!) keys by which the '\' and '|' characters could be typed, but not a single one which provided
me with a '=' character, leaving me bar the possibility to even edit config files or defining aliases in
the shell.
And yeah, the encryption thing is really nasty... I didn't really look for an ecryptfs feature, as the
only user on my systems is the same person that is root, and thus cryptsetup is the better option
and the one i'm used to, indeed.
Seeing that the swap is encrypted via cryptsetup, I wonder why the same isn't at least an option
for /home, possibly also with a user-supplied key that is _not_ stored in the system configs, so
that it must be entered (or as a keyfile provided on a USB thumb drive or SD card or whatever),
when the system boots. That is invaluable for portable devices in case of loss or theft. (Of course
ecryptfs is an alternative for those used to it... when it works...)
the current encryption offering is similar to what ubuntu used to provide with their "encrypt home" option. However, its not bee real popular, and we are probably going to offer luks encryption options soon in the new installer.
the policy such as it is to format root, home if requested, and swap if a new one is made.The partitioning policy is completely nuts... i can custom-partition via gparted, and even format
the filesystems like i desire, but the rest of the installer happily ignores my choices and forces
me to format all partitions (except swap, of course) again using any one of a choice of filesystem
types, but that one for each and every partition... nobody needs (or even wants) journaling on
/boot (but fortunately, /boot isn't supported as a filesystem on its own), but it's a feature of choice
for at least user data, that continuously change, and may be suitable for system fs like /var and
even for /usr in case a large update goes wrong...
new swap should be able to be created from existing partitions, and all swap partitions should be picked up in fstab. However, it is possible the encyrption feature messes with that, I have no idea. See comment above.The choice of swap is also poor, either a new one can be created (which is apparently not accepted
when there are others on the system (but i tried that only once, because they became encrypted
during the process, which could render another installed OS, which is currently in hibernation,
unwakeable).
formatting per partition is a good idea.Would it be so hard to implement a simple GUI pane where one can select per partition the
file system type and where to mount it, whether to reformat at all, etc?
That's about when the installer was originally developed. The original author abandoned the project, and we of antiX and MX communities are continuing with it, mostly because its been around forever, but also because its capable of installing a running live system, including anything in the root persistence files if used (thanks to the antiX live-USB system).Honestly, with this installer I feel like back in 1995...
given the users of this forum, smb shares seem much more important to them than sshd. However, sshd (openssh-server) is totally installable. I do it all the time.There are many other issues, the (maybe) most important being, that not even sshd is available
in an installed instance (didn't check the life, but i can make an educated guess). It's not just
not activated, it's not even installed... But Samba, yeah, Samba is important... :-/ Did I mention
1995 already?
the original poster provided some comments, but did not actually ask for any help. But a lot about the keyboard has gone into the new installer already.And I wonder, why most everyone just ignores this thread... ~200 views? I'm pretty sure that my
"little" contribution goes likewise unnoticed, but I've gotta take a chance ;-)
thanks, I think.Seriously, I had big hope with MX Linux, but these issues should be worked over. The best point
of this distro (from my pov) is its systemd avoidance. +1 for that. But there are many things to
do (not even speaking about the oh-so-powerful MX tools :-/
we have a handy github link in the top right hand corner of the forum menu bar which will take you to the sources for all the mx-tools. the new installer is not there yet, but is available here: https://github.com/gazelle-installerBTW, where can i find the sources of minstaller? I'd like to take a look to see if I could contribute
the one or another improvement to it, just instead of only complaining...
have a nice time, til then...
As anti said above, contributions are welcome.
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.