[ARM] I need help resolving a newly incurred bug in the image scripts

ARM Installation
1

I need help in troubleshooting a bug that just cropped up. Everything was working until just recently. So obviously something changed, but I cannot figure out what.

A little background

Basically the script creates a loop device, named test.img and the loop device is partitioned and formatted.

Then pacstrap is run and installs all the packages necessary for an operating system.
Next various configuration files and other files are copied to test.img in preparation for arch-chroot.

In chroot, a new user named ā€œalarmā€ is created right at the beginning and for troubleshooting the results are displayed. Following are the scriptā€™s commands for creating a user named alarm

useradd -d /home/alarm -m -u 1001 alarm
echo alarm:alarm | chpasswd
echo root:root | chpasswd

I created a break point in the script that displays the results. commands are indented

 ls /home
total 4
drwx------ 3 alarm alarm 4096 Aug  9 19:44 alarm

 id alarm
uid=1001(alarm) gid=1001(alarm) groups=1001(alarm)

 passwd & Shadow results for alarm
alarm:x:1001:1001::/home/alarm:/bin/bash

alarm:$6$6aGiB2Y84awl4rF0$bSGdQHjsG3pl4BwVn3tVDdBwT0WYtEiXVTI8RkcJDyinQk7pE/BSZyc6Gk0FBJkYl/JZ/yLc1ITlzyGoS2E.40:19578:0:99999:7:::

 passwd & Shadow results for root
root:x:0:0::/root:/bin/bash
root:$6$36B4a.KCC4LrF/mx$NinXn2DIfiyezXyFM3iugBd/VaqSzu1eztgBIe8qmiGvonfrHxMyqZmf7YZ3nvM..fAl0eBrbefmAxov83GzK.:19578::::::

The results shows that user ā€œalarmā€ was created, alarmā€™s home directory is established, UID & GID are there, and /bin/bash is the desired shell. the passwd file shows alarm:x: in which the x indicates the alarm passwd is in the shadow file. Everything looks OK.

Still in chroot, some more user configuration occurs

printf "alarm ALL=(ALL:ALL) NOPASSWD: ALL\n" >> /etc/sudoers
gpasswd -a alarm wheel
printf "export DISPLAY=':0'\nxhost +SI:localuser:alarm\nxhost +SI:localuser:root\nexec openbox-session\n" >> /home/alarm/.xinitrc
printf "if [ -z \"\${DISPLAY}\" ] && [ \"\${XDG_VTNR}\" -eq 1 ]; then\n  exec startx\nfi\n" >> /home/alarm/.bash_profile
chown alarm:alarm /home/alarm/.xinitrc
chmod 644 /home/alarm/.xinitrc

then more configurations. As part of trouble shooting, the last thing done in chroot is to repeat the break point and display alarmā€™s settings/

alarmā€™s settings are stil displayed as above. So user alarm still exists and is unchanged at this point

CHROOT exited.

at this point, the only thing that occures is compressing test.img to either a rootfs image with bsdtar or into a dd compatible image using xz

The problem is when the image (either rootfs or xz image) is copied to a uSD card, and when the completed uSD card is booted it should auto login user ā€˜alarmā€™, start openbox, and present the launch.sh script. Instead when trying to auto login, it gives the following error.

ā€œUser not known to the underlying authentication moduleā€

If I then take the uSD card and mount the partitions, arch-chroot into the uSD and ls -l /home yields nothing. The user alarm is not there anymore.

I donā€™t think the problem occurs during compression as I can dd the non-compressed test.img to a uSD and still get the same results.

If interested, the scripts are available at

and the main script is ā€œeos-arm-buildā€ and the chroot script is ā€œeos-arm-chrootā€.

I donā€™t know what changed, but I would like to fix it. So far it has me stumped. I guess I should look for a work around.

If you got to here, thank you for your time and interest.

Pudge

2

Took a very quick look at file eos-arm-build. Lines 66 and 171 look suspicious.

  • 66: quotes mismatch?
  • 171: create folder after copying to it?

Edit: Iā€™m still trying to sleep (it is 5.42 a.m.). Iā€™ll try to look at those files a bit more after waking upā€¦ :wink:

BTW, sometimes printf may cause surprises if not used with a format string like

printf ā€%s %s\nā€ ā€$var1ā€ ā€$var2ā€
1 Like
3

Thank you for your input.

I have a copy of that repo on my computer where I am trying to get the RADXA Rock 5b ARM device working when I found this problem.

In my work version, I already fixed

  • 171: create folder after copying to it?

You were correct about that. Good proof reading on your part.

  • 66: quotes mismatch

I will have to check into that tomorrow. Itā€™s almost my bedtime and my brain is currently mush.

Thanks again.

Pudge

1 Like
4

I am currently thinking that the problem might be in eos-arm-chroot at or around lines 8 to about 13.

Line eight is using printf to alter the /etc/sudoers file. I thought that visudo had to be used for editing /etc/sudoers file. Not sure how to do that in a script. I may have to invoke visudo in the script, then manually type in the needed input.

Line 14 looks suspicious but I put in a break point that lists /endeavouros* then issued a
read z
so as to look at it. I got

ls: cannot access "/endeavouros*' : No such file or directory

I have to look into this more tomorrow.

Pudge

5

Looked at the file, and found something I didnā€™t understand, maybe Iā€™m missing somethingā€¦

  • lines 10 and 11: DISPLAY is set and then tested for -z, so it is always false and startx will never be executed?
  • line 14: where is /endeavouros*?
6

BTW, if you have the possibility to use bashdb debugger, it may help a lot.

Also shellcheck may be useful to check potential issues. But that tool gives some less useful warnings too. Still Iā€™d recommend it.