I undestand, just think it should have stayed in Prepare Installation, instead of being prompted for at startup.
Actually you would normally be prompted right after initial language selection, which in your case is very likely hidden because your choice is remembered - I should do a similar thing for the keyboard settings and it won’t bother you again when you have run the program once on the host.
Also the window text I think can be more to the point than the inherited one currently is … I am just always hesitant with any text string changes because it means that all the translation files need to be updated aswell … by whom ever, whenever…
None of my four openrc installs were successful.
Installed bumblebee for all of them initially.
KDE and LxQt hung at boot, changing to video intel from bumblebee nvidia hybrid I could boot.
XFCE and Mate I could proceed to the login screen, but could not login with errors
Failed to connect to socket /tmp/dbus-hj-3Ry8KR7C: Connection refused
Unable to load failsafe session Unable to determine failsaft session name
Mate had a dbus related error and could not login.
So bumblebee seems to only hang when used with sddm, when used with lightdm at least the login screen was displayed, although login was not possible.
Did another LxQt systemd install, booted fine, and five minutes in the environment seemed okay.
Thank you. I’m not sure if I understand correctly:
Does that mean when switching to video-intel, do all of them work? Or do Xfce and Mate additionally have login issues even without bumblebee?
As DM displayed correctly I didn’t check, will change to video-intel now.
Changing the video driver doesn’t change XFCE errors, DM displays, after entering user password the error occurs.
Didn’t copy down the entire error message before, did this time.
Unable to determine failsafe session name. Possible causes: xfconfd isn't running (D-Bus setup problem); environment variable $XDG_CONFIG-DIRS is set incorrectly (must include "/etc"), or xfce4-session is installed incorrectly.
Reading the error message more carefully I presume it is related to this
(241/445) installing xdg-user-dirs /tmp/alpm_lFqi2c/.INSTALL: line 3: systemctl: command not found
Same issues with Mate as before.
Again, DM displays (no background image though - blank), after entering password
Could not connect to session bus: Failed to connect to socket ... Connection refused
Could not acquire name on session bus
Thanks Oberon, but i decided to give it a miss. It was most likely something i was doing wrong. I was using the netinstall iso for manjaro so maybe i download the manjaro-architect iso and give that way a try instead.
Okay i tried again and downloaded the manjaro-architect iso. Everything went smoothly as far as install but after grub boots i get this and it stops at “started TLP system startup/shutdown”.
I am using VB.
Screen dump of what i can grab, i dont know how to access those files /var/log files you mentioned Oberon, they are just not there and i dont know how i would be able to save them through VB.
Edit to add, lxqt minimal install, base-devel. 10 GB virtual disk. 2 Partitions, 1 root [ext4] and 1 swap, 7 GB for root and 3 GB for swap. partitioned using fdisk.
Similar issue described here (not using Manjaro-Architect):
As you all keep gradually fixing this m-a installer, just remember to “Log” it all, and I do mean ALL output should be “LOGGED”, in detail, to a readable file, be it /var/log/syslog or whatever,…
In the end, those huge detailed-installation output log files will prove invaluable. -You can NOT put the “fire” out, if you don’t know where it is.
So clearly, have ALL the installation output -> to a proper log file.
And if anyone thinks otherwise, then they just don’t know, or don’t feel others need to know?.
Sooo, Log it, or lose it, as they say.
And yes, I’m only gonna advise this warning once.
and keep up the happy testing.
I’ve been following this +1400 posts, and not just from this thread, but from 3 other thrads as well, and we really gotta settle this down now.
Is m-a an alternative to net-install ANY Manjaro iso, aka Desktop-Profile,…, be it Stable, Unstable, Testing ?
if so, then make it so.
'Cause in the end, the iso dev’s will have to, at the very least, collaborate here, and better yet, eventually take over.
What tool is this going to be for ?
If it\s a User CLI-Net-Installer, then ALL iso dev’s need to collaborate here.
Make it familiar, as it already is with iso’s, ie, choice of stable, unstable, testing, and let the user chips fall where they may. Desktop profiles, mhwd,…, are looming big here.
This m-a net installer should eventually be handed off to ALL the iso dev’s, constantly updated, or it won’t, -and if not, then it’ll fail just like the past Manjaro-Net-installer project has failed.
If there’s not 100% interest up the line, then this will likely stay a project amongst a very few, or maybe just a development CLI-net-installer tool, which although intellectually interesting, serves little long-term use for User’s who aren’t in the “club”?, depending on the user.
But then again, hat’s-off to this very interesting and, more-often-than-not successful project.
Time will tell.
Something we already knew, but need to revisit, now-n-then.
I would not say that the original net-installer failed. It served its purpose, but time marched past it.
The idea behind manjaro-architect is to benefit from the work that iso profile maintainers are already doing. Currently profiles can get broken somewhat frequently, because profiles don’t keep up with the changes in the repos (like the current openrc issues or when we dropped some Xorg input drivers from the repos). But I believe this will change for the better when we use predominently stable repos instead of unstable. Still, you are right that it will take more effort from profile maintainers than before to keep their profile up to date, because they need to be up to date constantly, not just when iso release is near.
yes, I worded that wrong, “fail” was the wrong word here, since I’ve installed succesfully using m-a, many times.
Keep up the great work here.
There have been so many little fixes and added tweaks since the 0.8.0 release, that it seems about time to release a new stable package.
0.8.1 is out and in unstable branch. Will be forwarded to testing and then hopefully soon to stable…
Just now installed XFCE minimal sysD successfully. last few days was having failures do to DM issues. Not sure if I was in time to use your latest updates will be trying again soon.
It has been a good while since I had time to write any code myself. I do have to say that @oberon and @papajoke have done some impressive work! Transition to using .ini file, command line arguments and dynamic menu has progressed faster than I could have imagined. Once we get dynamic menu coded, we can easily implement menu structure suggested by @sueridgepipe.
After that, all that is left is squashing some bugs and implementing btrfs subvolumes, hibernation and few other things. I’m hoping we can get the installer to 1.0 before summer. Then it should be ready to be distributed with stable isos (or perhaps even earlier).
Sounds like great progress is being made…
A couple of possible additions to manjaro-architect through command line parameters have been previously discussed
- pipe all text output to an external file for debugging reasons
sudo manjaro-architect --debug <filename> (or -d)
- insert a “pause to continue” after each command execution, again for debugging reasons
sudo manjaro-architect --pause (or -p)
Is this the sort of thing you guys are implementing, or just the cli parameter framework?
Are you guys using a wrapper function for the execution of explicit installation commands?
If a wrapper function is used this could be a fairly straight forward change in theory, albeit after the conversion to use it… just thinking out loud.
How about each language has a default keymap setting and the user then has the option to change that in Prepare Installation, with a menu item like Change Default Keymap, or whatever description fits best.
Having to choose manually from what seems like a hundred different keymap options each launch is not the right way to go IMHO. This way each language should be handled correctly by m-a OOTB, without having to manually set it up. If the user then wants to tweak it they have the option to do so.
Thanks for the point of view, I had not considered that many users will not know how to properly navigate the list. Myself I usually just type ‘f’ to preselect ‘fi’ keymap, but this is probably not common knowledge, especially for us keymap users.
A bit like when spatry reviewed pacli, and found it difficult because he thought the package search field was just scrollable list…
Language selection should be expected.
Yeah, I just think this will be confusing for a lot of users, myself included initially… amiga, atari, applkey, ansi dvorak, azerty, bashkir, bg-bds-cp1251?
There are 8 items currently displayed in that list, and this is only 3% of available items… no user should have to choose from 264 different obscurely named items when an installer first launches.
Just my 2c.
yes. a automatic keymap selection per language would be good, followed bye a prompt informing about the default and offering the option to change that. Should be quite simple to do.
All I can say to you guys is thank you. Without the m-a installer, I would not have been able to get Manjaro installed on my machine because of what’s going on in this thread.
With the m-a installer, I was able to skip the Install Display Driver section and avoid MHWD’s automatic configuration of bumblebee, which locks up my system (a Dell Precision 5520).
So the Manjaro-Architect installer definitely has a role: for users who need to customize their installs because of problematic hardware. Because of that, I say thank you for doing this. It’s obviously a ton of work, but it’s really important work.