Bug 1225709 - tik mounts the wrong path onto usb sticks installations
Summary: tik mounts the wrong path onto usb sticks installations
Status: RESOLVED FIXED
Alias: None
Product: openSUSE Aeon
Classification: openSUSE
Component: Installation (show other bugs)
Version: Current
Hardware: x86-64 Other
: P4 - Low : Normal
Target Milestone: ---
Assignee: Richard Brown
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-31 09:19 UTC by Müller
Modified: 2024-06-18 03:30 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
tik.log of installation atempt on USB-SSD (2.24 KB, text/x-log)
2024-05-31 10:07 UTC, Martin Abele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Müller 2024-05-31 09:19:53 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0
Build Identifier: 

tik tries to mount ‘/usr/bin/mount -o compress=zstd:1 /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_60A44C3FAD9EE791C9291FA8-0’ but the correct path to mount would be ‘/dev/disk/by-id/usb-Kingston_DataTraveler_3.0_60A44C3FAD9EE791C9291FA8-0\:0’
it seems as if tik just stops indicating the path at \

Reproducible: Always

Steps to Reproduce:
try to install aeon onto a usb stick
Actual Results:  
mount: /var/lib/tik/mig/mnt: special device /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_60A44C3FAD9EE791C9291FA8-0 does not exist.
       dmesg(1) may have more information after failed mount system call.
[/usr/lib/tik/modules/pre/20-mig][20240531-08:43:17][LOG] [pkexec][32] /usr/bin/mount -o compress=zstd:1 /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_60A44C3FAD9EE791C9291FA8-0 /var/lib/tik/mig/mnt
[/usr/lib/tik/modules/pre/20-mig][20240531-08:43:17][ERROR] Command <tt>/usr/bin/mount -o compress=zstd:1 /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_60A44C3FAD9EE791C9291FA8-0 /var/lib/tik/mig/mnt</tt> FAILED
[/usr/lib/tik/modules/pre/20-mig][20240531-08:43:20][LOG] [zenity][0][] --error --text Command <tt>/usr/bin/mount -o compress=zstd:1 /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_60A44C3FAD9EE791C9291FA8-0 /var/lib/tik/mig/mnt</tt> FAILED
[/usr/lib/tik/modules/pre/20-mig][20240531-08:43:20][LOG] [STOP][1] /usr/bin/tik

Expected Results:  
Successful mounting
Comment 1 Richard Brown 2024-05-31 09:23:22 UTC
This is because we use : as a delimiter where analysing the disk metadata..so the :0 is interpetted as the next field, not as part of the device

Either we'll need to rework that functionality, or just filter out all usb- devices so the problem doesn't occur

Given the UEFI ESP standard we use is for permenant installations, some UEFI firmwares may not appreciate an Aeon OS disk being removed, so maybe we shouldn't support removable devices

Leaving these thoughts here for discussion, not expecting to move on this bug quickly
Comment 2 Müller 2024-05-31 09:27:57 UTC
I understand your thought but maybe people have a windows pc without 2 ssd where they just slap an external ssd in the back that always stays on, then it would also be permanent
Comment 3 Martin Abele 2024-05-31 10:07:35 UTC
Created attachment 875244 [details]
tik.log of installation atempt on USB-SSD

I had an SSD with Aeon RC1 installed and tried to migrate to RC2. The installation failed. The log is attached. It seems to be the same issue with using ":" as a delimiter to slice lsblk output.
Comment 4 Müller 2024-05-31 10:15:12 UTC
a possible solution would be to execute another check in the tik-functions at line 171 which triggers the fallback to unix path (which doesn't contain a :) if the by-id path contains :0
Comment 5 Martin Abele 2024-05-31 10:20:23 UTC
I can see in the code where it happens. I guess it would be possible to use another character as delimiter to fix the issue if the decision is to allow USB connected devices.

Allowing USB devices like external SSD's would make testing the things a lot easier for people like me who have only one laptop with one hard drive. But testing is not the goal of Aeon. Aeon should be idiot-proof. An elegant solution could be to allow USB devices for testing by a configuration entry or when debug is set. If this is easy enough to implement.
Comment 6 Müller 2024-05-31 10:22:07 UTC
# Fallback to unix device in case by-id does not exist or contains :0
if [[ ! -e "${TIK_INSTALL_DEVICE}" || "${TIK_INSTALL_DEVICE}" == *":0"* ]]; then
    TIK_INSTALL_DEVICE="/dev/${result}"
fi

if the code is correct this change is also a solution
https://github.com/sysrich/tik/blob/main/usr/lib/tik/lib/tik-functions#L171
Comment 7 Müller 2024-05-31 10:23:57 UTC
if richard confirms that it would work and this solution would be acceptable i could make a PR
Comment 8 Müller 2024-05-31 10:30:34 UTC
i have made a PR so that it is easier to judge what my train of thought is
https://github.com/sysrich/tik/pull/24
Comment 9 Müller 2024-05-31 10:58:52 UTC
oh i don't think that works because the : is not in the variable, right..? sad
Comment 10 Müller 2024-05-31 11:29:35 UTC
i tested it and it gave a pretty interesting result, it more or less worked. it doesn't take the by-id path anymore but a completely wrong other path

[/usr/lib/tik/modules/pre/20-mig][20240531-11:24:18][LOG] [STOP] /usr/lib/tik/modules/pre//usr/lib/tik/modules/pre/20-mig
[tik][20240531-11:24:18][ERROR] Given device <tt>/dev/usb-Kingston_DataTraveler_3.0_60A44C3FAD9EE791C9291FA8-0:0</tt> does not exist.
[tik][20240531-11:25:24][LOG] [zenity][0][] --error --text Given device <tt>/dev/usb-Kingston_DataTraveler_3.0_60A44C3FAD9EE791C9291FA8-0:0</tt> does not exist.
[tik][20240531-11:25:24][LOG] [STOP][1] /usr/bin/tik

btw: normal disk installations were not destroyed by my code
Comment 11 Müller 2024-05-31 11:48:49 UTC
okayy so the trigger for the fallback works but the fallback doesn't work
Comment 12 Martin Abele 2024-06-18 03:30:29 UTC
Should be fixed with https://github.com/sysrich/tik/pull/28