skidoo wrote:MX-15-b2_x64.iso
using the same scenario (root persistence, aka =root!,home)(...and forego creation of a separate homefs)

mx installer presents the same workflow as antix

screen #6 invites adjustment of startup services. After I do so, a non-numbered"Reminders" title is displayed + a"Do you want to reboot now?" modal popup.
Regardless whether response to the popup is yes, or no, the installer app autocloses immediately when I respond to the popup.

d_o are you diving right into the installer during initial live boot (skipping persistence setup)?
That would explain (to me) why, in your testing, the installer is inviting root account password setup and asking you to setup a"default user".

just tried with a 32 bit antix-15 full iso. used persistence, setup root password, setup some apps. ran the installer, and I was presented with the user account creation screen as per normal.

skidoo, what other steps have you taken? creation of a second user? I will test that. have you remastered? upgraded the installer (apt-get dist-upgrade?).

Ok just ran thru a couple of trials. Looks.like the user account screen of the installer is not offered if another user is created on the live usb.

The accounts are present and you can log in from the cli (init 3). Creating a new user gets you home folders and allows slim login of the new user. But the demo and other created user do not have home folders do slim doesn't have anywhere for the x authority files.

same behavior, mx15 with a remastered linuxfs but no second account

Finally I got my persistent USB and was able to install. My steps on the secon attempt (first didn't work):
1. Burned antix15_base_a1_64bit.iso to USB1 with SUSE Image burner.
2. Formatted USB2 with Gparted (not working on antiX 15 a1 live session).
3. Booted with USB1, installed Unetbootin. (because antix2usb not working, also not in live session)
4. Transfered the ISO to USB2 with Unetbootin
5. Booted with USB2 and 'root persistence', created rootfs and homefs, changed the wallpaper, tweaked the conky, launched the installer.
6. Got the screen 7b and 7b, see screenshot. Last checkbox is 'save changes from the live desktop'.
7. Will reboot to the disk and see the result.

I wasn't able to see the result, because I was getting a kernel panic three times. I adjusted the fstab after two times, btrfs, compress, autodefragment, 0 0 - no joy. __{{emoticon}}__
I'm again in the live session, persistence worked, but not on the wallpaper and network connection with ceni. I will see if I get the 7a and 7b screen again, but won't install, because it is almost 3:00.
Update: Yes, the screen is there.

I chose not to install the bootloader again, will update-grub on Manjaro again. I did run the install, but this time without the compression trick. Let's see the result.

The same bloody kernel panic again! __{{emoticon}}__
This might be due to btrfs or that I installed on a logical partition.
Nevertheless I showed that I'm getting the screen 7b in live persistent session.

Looks.like the user account screen of the installer is not offered if another user is created on the live usb.

Thank you for finding what triggers the conditional behavior.
Across each of my trials reported here, I had strictly adhered to the steps/parameters described in post#1 (so that others could verify/refute the result).
Too many permutations, too few testers.

eugen_b, I chuckled at your joke but any tests which introduce further variables (pdqzs filesystem, this time without the compression trick???) serve to muddy the water.

The accounts are present and you can log in from the cli (init 3).
Creating a new user gets you home folders and allows slim login of the new user.
But the demo and other created user do not have home folders so slim doesn't have anywhere for the x authority files.

I understand the quoted line1.
In line2, I guess your referring to the result of"creating a new user via the installer 7a screen" ~~ which, until your post, I didn't even realize was possible.
Line3, again I'm left guessing whether your tested adding the new user via controlPanel or via installer 7a screen, or both.
Either way, we've confirmed that a conditional installer bug exists.

To fix the"failed to execute login command" following testdriving then purging lightdm, I foggily recall that it was something simple,
like"need to run update-alternatives" or, need to edit/remove something with a hyphenated name (? display-manager)
I'll dig through my pile of notes...

I understand what you said about"no place to write the .Xauthority files"
but don't understand why my attempted workaround (boot from pendrive post-install, mount hdd, and copy the missing /home subdirs into place) fails to achieve a fix.
-=-
Aha. click. ding!
Makes sense that I'll need to followup, manually removing the files which would have been filtered/nixed via .excludes list and/or live-to-installed script.
I'll try that and report back.

eugen_b, I chuckled at your joke but any tests which introduce further variables (pdqzs filesystem, this time without the compression trick???) serve to muddy the water.

Yeah, man, it wasn't helpful as it could have been with ext4, but I couldn't expect that this xould play a role. (Compression trick is a mount -o remount,compress-force=lzo command shown in the termonal in the first screenshot, it saves 30% disk space.) I will try with ext4 now.
But you can point me at what I did differently with persistence and install if anything. I would like to reproduce your bug.
Why do I get the user account creation screen (7a and 7b) on first run with persistence as well as on the second run?

In line2, I guess your referring to the result of"creating a new user via the installer 7a screen" ~~ which, until your post, I didn't even realize was possible.
Line3, again I'm left guessing whether your tested adding the new user via controlPanel or via installer 7a screen, or both.
Either way, we've confirmed that a conditional installer bug exists.

Since I coudn't get into a X session
I actually booted into init 3, and used

adduser username

to create a user (and home folders). then reboot and logged in with the just created user (so instead of 2 users from the liveusb, there are now 3).

but yeah, definite bug there. nice find skidoo!

I tried to install with both ext4 and btrfs, now choosing to install the bootloader to root. After update-grub on Manjaro I wasn't getting kernel panic anymore but such a line
/scripts/init-top/udev: line 14: can't create /sys/kernel/uevent_helper Permission denied
then a long time Scanning for BTRFS…
then (initramfs) and no reaction to keyboard input
What can I do next? I will take out my Manjaro SSD and install the bootloader to MBR. I will also try to install not on a logical partition but on a primary partition.
Well, no info on your issue, skidoo, but perhaps interestin for antiX 15.1 alpha1 testing. __{{emoticon}}__

Referring back to my chosen title for this thread, the central point is that a user (person performing an install)
needs to have a clear understanding of what to expect. As is, the docs simply (perhaps too simply) more or less state:
"changes and customizations you made during live persistence will be carried over to the installed version!"
Whatever the exact wording, IIRC it contains an exclamation point, suggesting"this is a BigDeal, a great feature".
It is a big deal, a great feature but, as-is, leads to the possibility of a user (person performing an install)"expecting too much".

If the feature description is revised to specify
"programs you've installed or removed and customizations to the"demo" user files during live persistence will be carried over to the installed version"
arguably, no bug exists.

I'm sympathetic to the chore involved, the added complexity of, dealing with wildcarded /home/*/* paths within the installer.
As testers, we often wander into corner-case scenarios. Is this one of those cases?
I don't know, can't guess, how many (or few) casual users would run live persistence using multiple user accounts.

Aaahhaaa! I do understand now where exactly the bug is. I was using demo as my persistent user, that's why I was getting the user creation screen in the installer. The idea to create another persistent user would never have come to my n00bish mind! I hope this is an indicator that such a case is really a corner case as you say.
Nevertheless I'll try to repair my install. I applied MX-14 (qt4) version of mx-bootrepair (installed on antiX15.1 live USB). I also will report a summary to the alpha testing thread.
Update: No, no fix possible. I installed even without booting into root persistence - the same boot error message. I'll report to alpha testing thread.