Until leap-156 i used the following bootloader configuration in GRUB2:
[not selected ] boot from partition
boot from master-boot-record
no trusted boot
no generic boot code
no activ flag
flag protected mbr “do not change”
How can I do that in Agama?
I did the installation with “automatic” in Agama but it doenst boot, so no menu displayed. It only boots leap16 with the following workaround: put in the leap16 installation dvd, choose “boot form hard disk” (instead of installation).
Optional information:
On this computer is no other operating systems. But on another computer where I use the same bootloader confugration is also windows installed. On all computers there is only one hdd drive. So selecting the disc in Agama makes no sense for me.
Boot process: Agama lets me only choose between automatic and selecting the disc . source: https://agama-project.github.io/docs/user/guides/storage.
Another question: Until leap 156 the installation process allowed to import all existing users. Agama doesn’t allow this it. But there is no yast user management to add users. How can I add them in order to login to the other existing user profiles and its home directories?
Under Storage options when configuring the disk you have to select include the /boot/efi and set to not format when using one ESP and a single storage device.
Add additional users via Cockpit which is the new management tool, or command line…
I know that people will cry: Cockpit. I did not use Cockpit for User Management until now. But be careful, because in your case you already have the users and thus their home directories. Which means that e.g. the UIDs must be the same as before. So at least look at the old /etc/passwd so you know what they new entries should look like. So, not obvious (that is why I love the feature in the old installer).
I am open minded for new things - even for cockpit. But I need to get used to it.
Could you please give me more information what you mean with your quote above (/etc/passwd). What are the keywords I have to search for? Because probably i’ll find a short tutorial for that.
So, when it goes, just like a larger /boot/efi we will endure the endless complaints. Why can’t folks just get with the times and look at future product developments.
Well to understand what is in /etc/passwd, you can consult of course
man passwd
Because the determining element of a user is the UID. (the third field) and all the files in a users home directory are owned by that UID. When when you simply add a new user with any high level tool (like Cockpit), you, the new user will have a UID as thought out by that tool and thus more likely not being the one you need. Also the tool will create a new home directory, which is also something you do not want. Also the default action in connecting a primary group (GID, the third field) has chaged lately. Thus probably your former users may all have usersas groupname and the belonging GID, but the tool will create a new group for every new user with the same group name as the user name and of course a new free GID. Result: all the files in the old home directory will have the wrong group attached.
As said, I did not use Cockpit for this, so I do not know if it has any features to adapt things to what is needed. Maybe it does, but without doubt you will have to find out how (if possible) to configure away from the defaults.
Well using that is another way of attacking the problem. In that case you create the users anew and then adapt the ownership by user and group to the new users.
In any case it will help if you really understand what the Unix concept is for users, groups and file ownership.
In such a case maybe the old friend useradd is easier if the users to re-create are just a handful.
Print down a table of the existing accounts, like <UID> <username> (assuming that for each account a corresponding /home/<username> exists).
Then a sequence of:
useradd -u <UID> -m -G <username> <username>
should do the trick; please note the -G <username> part might be omitted if the existing install is new enough and already uses the “new default” of username:username instead of the old username:users.
[DISCLAIMER] : since I don’t do such things on an everyday base, comments from more experienced users are welcome.
As you said, a carefull examination of the current users and groups is needed. And as useradd (which I probably also would use) has now defaults (like the user=group syndrome) that differ from before and thus most probably of what the OP has, the use of other options may be needed. So study man useradd. An important (for his case) starter there is:
By default, a group will also be created for the new user (see -g, -N, -U, and USERGROUPS_ENAB).
Also a pitfall I see is the user that the installer forces you to create. It may occupy places (like GID) that one needs for one of the old users.
Yes, the loss of the feature to take over the old user population is a real regression.
BTW @OrsoBruno , the -G is probably not what you wanted to use.
The “first user” that agama forces to create should have UID=1000, so the corresponding username should be used for that even if that is not the “everyday user” of the system.
I do not understand you. It will have UID 1000, but it will not have many things your old user 1000 had. I would remove that forced user1000 asap and then create my former users 1000, 1002, 1003, (or what numbers were used) etc.
OK, better still just define a password for root and do not create a first user at all in the installer (which is allowed by agama), then recreate users 1000, 1002, etc. etc.
And you are right about -G, so there are two cases:
1- the existing install is old enough and has username:users: useradd -u <UID> -U -m <username>
2- the existing install is new enough and already has username:username: useradd -u <UID> -m -g <username> <username>
Well current state of installing is:
Change bios settings to uefi works fine with booting.
But reinstalling leap 16 using/setting the username to an existing user with an existing home directory under /home/username won’t work because after login, there was a volley of error messages that file xy under .config could not be written. Probably because of your topic with the user rights / user groups.
No I am reinstalling it because I cannot do anything. I even cannot open the bash. Iam setting another user.
@OrsoBruno@hcvv
Is it a good idea to create a new fresh user with no existing /home/username and then copy data in dolphin e.g. from /home/differenusername into the currentusername. will that be a workaround? But I guess the “chmods”/user rights/user groups won’t be right either
On the computer Iam currently installing leap 16 there are 2 users. But one main user and another one which really isn’t needed.
On another computer where I want to install leap16, there are more users but only 1 mainly and 2 from time to time - so 3 are really needed:
Reading here several topics about the new installer, I would plan for a new install (which I didn’t until now), to
see that I get a root user that works as it did all the years (when this is not possible during installation, then immediately after);
create the user I have to with a different name then any of the “existing” users;
after installation remove that “forced” user, probably with userdel;
create all the “existing” users with the correct UID, the correct GID (users, which will probably created with the first user when not already existing) and the NOT creating home directories;
check and double check if the /etc/passwd entries for those users are the same as they were in the old installation (so make a backup of that if it is not included in your normal backup).
Take care, I did not execute this path, but that would be my starting point.
And what was your path?
Kind of surprising for me that others may not continue using their existing user and /home/user. Because otherwise there would be more information about that.
print out the result of cat /etc/passwd |grep -E "user1|user2|user3|user4|user5"(of course use the real names of the users involved);
that should show something like user1:x:1000:100:User1:/home/user1:/bin/bashetc., showing that user1 has UID=1000, GID=100 etc.
during install define only a password for root, do not define any new user
after the first reboot, go to a Virtual Terminal (CTRL+ALT+F4, for instance) and login as root
at this point I would keep the existing users on the “old default” to avoid permission problems with their existing ~homes and files, so issue:
useradd -u 1000 -g 100 -G wheel -m user1
with that you re-create user1:users with /home/user1/ as an administrative account (wheel); if user1/UID=1000 is not “you” (as a system administrator) adjust username/UID accordingly;
at this point you should be able to switch to the graphical login screen (usually at CTRL+ALT+F7) and login as user1 and even do further admin work from there if you like to;
if not so, write here for help
then re-create the other users like useradd -u 1001 -g 100 -m user2etc. (be careful matching username and UID as per your previous printout);
at this point also the other users should be able to login and find their files where they left them;
if not so, write here for help
If any user belongs to important additional groups you may add a corresponding -G groupxxat user creation, or adding via cockpit-accounts once the system is up and running.
Sorry for the long post, but it is easier done than written about.
[DISCLAIMER]: I didn’t check that workflow, so consider it only as a starting point; after all, you may have different ideas about your system.
The one that I most use, is to import users. Unfortunately the Agama installer does not seem to support that.
My other strategy, is that the user with UID=1000 is a limited user. My normal account has UID=1001. So on a new install, I go with that limited user. I call it “Support Account” (for the full name), and “support” for the login user. I do use that occasionally as an administrative account, mostly during initial setup.
