MX Linux Forum

Posted: **Thu Aug 17, 2023 5:18 am**

Hello people,
Many thanks for the new MX23. It looks to run very smoothly on my machine. But I have a problem. Here's the quick system info:

Code: Select all

System:
  Kernel: 6.1.0-10-amd64 [6.1.38-2] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/antiX/vmlinuz quiet splasht nosplash lang=en_AU kbd=us
    tz=Australia/Brisbane persist_static from=usb splasht
  Desktop: KDE Plasma v: 5.27.5 wm: kwin_x11 vt: 7 dm: SDDM Distro: MX-23_KDE_x64 Libretto July
    31 2023 base: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Desktop Mobo: Gigabyte model: Z390 D v: x.x serial: <superuser required>
    UEFI: American Megatrends v: F3c date: 12/18/2019
CPU:
  Info: model: Intel Core i5-9400F bits: 64 type: MCP arch: Coffee Lake gen: core 9 level: v3
    note: check built: 2018 process: Intel 14nm family: 6 model-id: 0x9E (158) stepping: 0xA (10)
    microcode: 0xC6
  Topology: cpus: 1x cores: 6 smt: <unsupported> cache: L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB
    L2: 1.5 MiB desc: 6x256 KiB L3: 9 MiB desc: 1x9 MiB
  Speed (MHz): avg: 2276 high: 2900 min/max: 800/4100 scaling: driver: intel_pstate
    governor: powersave cores: 1: 2900 2: 2900 3: 2900 4: 1101 5: 958 6: 2900 bogomips: 34798
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
  Type: mds mitigation: Clear CPU buffers; SMT disabled
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data mitigation: Clear CPU buffers; SMT disabled
  Type: retbleed mitigation: IBRS
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: IBRS, IBPB: conditional, STIBP: disabled, RSB filling,
    PBRSB-eIBRS: Not affected
  Type: srbds status: Vulnerable: No microcode
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: NVIDIA GK208B [GeForce GT 710] vendor: ASUSTeK driver: nouveau v: kernel non-free:
    series: 470.xx+ status: legacy-active (EOL~2023/24) arch: Fermi 2 code: GF119/GK208
    process: TSMC 28nm built: 2010-16 pcie: gen: 1 speed: 2.5 GT/s lanes: 8 link-max: gen: 3
    speed: 8 GT/s ports: active: HDMI-A-1 empty: DVI-D-1,VGA-1 bus-ID: 01:00.0 chip-ID: 10de:128b
    class-ID: 0300 temp: 46.0 C
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 compositor: kwin_x11 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: nouveau gpu: nouveau display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22") s-diag: 582mm (22.93")
  Monitor-1: HDMI-A-1 mapped: HDMI-1 model: Samsung S22B300 serial: <filter> built: 2012
    res: 1920x1080 hz: 60 dpi: 102 gamma: 1.2 size: 477x268mm (18.78x10.55") diag: 547mm (21.5")
    ratio: 16:9 modes: max: 1920x1080 min: 720x400
  API: OpenGL v: 4.3 Mesa 22.3.6 renderer: NV106 direct-render: Yes
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: Gigabyte driver: snd_hda_intel v: kernel
    alternate: snd_soc_skl,snd_sof_pci_intel_cnl bus-ID: 00:1f.3 chip-ID: 8086:a348 class-ID: 0403
  Device-2: NVIDIA GK208 HDMI/DP Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel pcie:
    gen: 1 speed: 2.5 GT/s lanes: 8 link-max: gen: 3 speed: 8 GT/s bus-ID: 01:00.1 chip-ID: 10de:0e0f
    class-ID: 0403
  API: ALSA v: k6.1.0-10-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 0.3.65 status: active with: 1: pipewire-pulse status: active
    2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Gigabyte driver: r8169
    v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: 3000 bus-ID: 04:00.0 chip-ID: 10ec:8168
    class-ID: 0200
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 966.73 GiB used: 172.62 GiB (17.9%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/sda maj-min: 8:0 vendor: Kingston model: SA400S37240G size: 223.57 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: B1E1 scheme: GPT
  ID-2: /dev/sdb maj-min: 8:16 vendor: Kingston model: SA400S37240G size: 223.57 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: B1E1 scheme: GPT
  ID-3: /dev/sdc maj-min: 8:32 vendor: Kingston model: SA400S37240G size: 223.57 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: B1E1 scheme: GPT
  ID-4: /dev/sdd maj-min: 8:48 vendor: Kingston model: SA400S37240G size: 223.57 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: B1E1 scheme: MBR
  ID-5: /dev/sde maj-min: 8:64 type: USB vendor: SanDisk model: Cruzer Glide 3.0 size: 58.12 GiB
    block-size: physical: 512 B logical: 512 B type: N/A serial: <filter> rev: 1.00 scheme: MBR
  SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
  ID-6: /dev/sdf maj-min: 8:80 type: USB vendor: SanDisk model: Cruzer Blade size: 14.32 GiB
    block-size: physical: 512 B logical: 512 B type: N/A serial: <filter> rev: 1.00 scheme: MBR
  SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
Partition:
  Message: No partition data found.
Swap:
  Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: file size: 5 GiB used: 0 KiB (0.0%) priority: -2
    file: /live/boot-dev/swap-file
Sensors:
  System Temperatures: cpu: 33.0 C pch: 37.0 C mobo: N/A gpu: nouveau temp: 45.0 C
  Fan Speeds (RPM): N/A
Repos:
  Packages: pm: dpkg pkgs: 2616 libs: 1436 tools: apt,apt-get,aptitude,nala pm: rpm pkgs: 0
    pm: flatpak pkgs: 0
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://mx.debian.nz/mx/repo/ bookworm main non-free
    2: deb http://mx.debian.nz/mx/repo/ bookworm ahs
Info:
  Processes: 249 Uptime: 25m wakeups: 1 Memory: 15.55 GiB used: 2.5 GiB (16.1%) Init: SysVinit
  v: 3.06 runlevel: 5 default: graphical tool: systemctl Compilers: gcc: 12 Client: shell wrapper
  v: 5.2.15-release inxi: 3.3.26
Boot Mode: UEFI

I've taken two pics from KDE Partition manager - one from the boot I'm posting this message in (Log-in 18:20), the other from the previous boot (Log-in 18:00).

partitions-2023-08-17-1800.jpg

partitions-2023-08-17-1820.jpg

I have four SSDs. sda contains (per the MX21 I've been using for some time) the files for MX19 that I no longer use. sdb contains the files for the MX21 that I currently use. sdc contains the files for a version of Ubuntu I was looking at and which failed to boot after update. That's where I'm planning to put MX23. sdd contains my data files. When I first started last night to boot from USB I got different disks registered as sda etc at different boots. Sometimes all were different. Then, earlier today, the boots all consistently gave me what I'm used to with MX21 (also KDE). Now, later in the day, I'm getting different allocations of sda,b,c and d to different disks again.

The two pics show that sda and sdb were the same during both boots but that sdc and sdd were swapped around. I have three users on my system. They perform different functions and I'm trying to allocate access permissions according to how I use the users and what I want them to access. This isn't possible when the disks get mounted as different drive IDs on different boots.

Any help please?

I don't know whether it's relevant but I've lost the ability to right click a desktop and select 'Log off'. I have to use the MX button that I have at the bottom left and select a Power option. I'm not worried about this at present, though.

Any help would be greatly appreciated.

Thanks in advance.

O

Posted: **Thu Aug 17, 2023 5:33 am**

Therefore it's better to use uuid numbers when possible , to make sure what device it is.

Posted: **Thu Aug 17, 2023 5:40 am**

Same thing happens to me, with 4 drives. There is a long thread on this here:

viewtopic.php?t=74881

Posted: **Thu Aug 17, 2023 5:42 am**

Thanks, people.

I haven't used UUIDs before. But I'll research them and the thread from Eadwine Rose and let you know.

Cheers.

O

Posted: **Thu Aug 17, 2023 5:44 am**

Mind.. I have solved this the doofus way: keep rebooting till they sit right. I didn't dare adjusting things in fstab or somesuch.

Posted: **Thu Aug 17, 2023 5:46 am**

@Eadwine Rose links may die in time

Posted: **Thu Aug 17, 2023 5:48 am**

There is no solution in there, so I cannot repost the solution

Posted: **Thu Aug 17, 2023 5:56 am**

This can be a simple/quick remedy (inspired by @m_pav )

Code: Select all
```
lsblk -f
```
Note (just once) somewhere which's which (uuid numbers , also labels)

Before giving permissions:
Code: Select all
```
ls -la /dev/disk/by-uuid/
```
Then go on as you're used to, sdc2 etc. , looking at your note ...

Posted: **Thu Aug 17, 2023 6:14 am**

In case that works, you can also create an alias for ls -la /dev/disk/by-uuid/ with something simple for that command, say: qq

Then just qq in a terminal :)

( "Bash Config" from menu )

(... Also you can create a shortcut key for your note file, then it'll be fast, not boring )

Posted: **Thu Aug 17, 2023 6:29 am**

Thanks Charlie Brown. I know how to change a disk owner using chown: chown -R username /dev/(say) sdd1. What command do I use to change the owner using the UUID?

Thanks.

Posted: **Thu Aug 17, 2023 6:47 am**

In fact, the above is assuming you change the permissions frequently / daily etc..

Otherwise, once you do it correctly they'll stay so (no matter it's now assigned as sdb4 but next time as sdc4 etc...)

Say, sdd1 needs to be permitted to user charlie .. just do it once checking as above .. that's it .. that device (uuid) will be permitted to charlie no matter it shows sdc1 next time ...

P.S. But.. rather than /dev/.. looking at the (current) mountpoint, also using the user id may be better. Say:

Code: Select all

id

And Charlie is 1003 , then:

sudo chown -R 1003:1003 /media/xxx/xxx

Posted: **Thu Aug 17, 2023 7:07 am**

I've found that when I allocate the permission using chown and a disk identifier such as sdd1 the permission does't stay the same. For example the user I'm using right now cannot see my data files. But last time I logged on I could. So the chown to a disk ID doesn't survive reboot. Is there a command that I can use to allocate ownership to the UUID rather than to the disk identifier such as sdc2? And that command will survive reboot?

More importantly, though, is this problem likely to disappear if I install MX23? As I read Edawine Rose's thread he supplied earlier, the problem doesn't disappear: he just reboots until he gets the configuration he's set his permissions for.

I think I may be missing something here? Alas, I do need first principles please.

Thanks heaps.

Posted: **Thu Aug 17, 2023 7:10 am**

Yes, was just editing :)

First mount them all (or one by one) and when mounted: lsblk -f

... once you do it correctly, it should be ok ..

i.e.

sudo chown -R 1003:1003 /media/ornithorhynchus/Ubuntu/*

or you can do it just changing the ownership of the "dot" file:

sudo chown -R 1003:1003 /media/ornithorhynchus/Ubuntu/.

Posted: **Thu Aug 17, 2023 7:28 am**

... But, this is ok for data partitions ...

If you do it on system-related ones, then there'll be serious problems: say rootMX... homeMX.. also other distros (the above Ubuntu was just for demonstration)..

If what you like is just to prevent users from accessing partitions: Encrypt (and just that user knows the encryption pw. for that partition).

Posted: **Thu Aug 17, 2023 7:36 am**

Apologies, Charlie Brown. I don't follow. Say my user is ornithorhynchus, the disk I want to give permission for is sda2 and the UUID for the disk, obtained using, say, lsblk -f is 12345ASDFG. Then to give the ownership of that drive as required do I use the command chown -R ornithorhynchis 12345ASDFG /media/ornithorhynchus/sda2? (Taking care to ensure there's no gap between the first slash and media.)

Apologies, too: I don't know what you mean by the "dot" file?

Thanks.

Posted: **Thu Aug 17, 2023 7:41 am**

"dot file" is a hidden one, the owner of that owns the whole ...

Whatever..

But, again, these are just for data partitions. And, no matter data or not: If your aim is to prevent access, just encrypt.

(Yes, it won't let you encrypt current ones, so, you may create new partitions using the unallocated spaces and after encryption copy/move data there)

Posted: **Thu Aug 17, 2023 7:42 am**

You don't need the uuid for the above examples. Just the current mountpoints, (hence lsblk -f)

Posted: **Thu Aug 17, 2023 7:48 am**

For example if it was me:

My sda7 is a data partition labeled as Data and with lsblk -f (just lsblk is also enough) the mountpoint shows: /media/charlie/Data

Then I would (Charlie's id is 1000)

sudo chown -R 1000:1000 /media/charlie/Data

or.. to another user whose id is 1004:

sudo chown -R 1004:1004 /media/charlie/Data

Posted: **Thu Aug 17, 2023 8:26 am**

... Or, simply using the "MX User Manager" :

you can create new group(s), say, one is xyz

then add the user(s) to be permitted to that group (just tick xyz for that user in the last tab, apply)

and give the ownership to the "group" xyz :

sudo chown -R :xyz /media/charlie/Data

Posted: **Thu Aug 17, 2023 10:33 am**

Don't know KDE
Another option is:

it can be done an any internal or external drive/partition, whether it's fresh or already used, though, if it's already used, you'll have to do the command twice, once with the dot and another the asterisk .

per: viewtopic.php?p=709022#p709022
I think this works OK with your UUID, and I think you're UUID issue is just how they are identified in the /etc/fstab/ file - BUT I am not positive of this!
Maybe provide output of: cat /etc/fstab
HTH

Posted: **Thu Aug 17, 2023 2:59 pm**

Thanks, people. There's a lot for me to think about here. To summarise. My problem isn't finding out what disk IDs or UUIDs are or allocating ownership. My problem is that disk IDs and the ownerships I assign to them often don't survive reboot when I'm using the live MX23 USB to boot from.

Posted: **Thu Aug 17, 2023 6:02 pm**

With modern Linux Kernels using Dynamically Assigned SATA Device Paths, I no longer bother with fstab for non-critical drives and have adapted to only using Disk Labels. By non-critical, I am excluding everything but the boot device. To put it simply, I've adapted my ways to work WITH the newer ways and have come to appreciate the beautiful simplicity it afforded.

Years back I setup a Desktop File Server on a machine with 2 x small 64GB SSD's, one for the original Windows (never used, don't know why I bothered) and another for MX Linux. The machine had 4 x identical Enterprise 2TB Spinning Platter drives for storage which I initially setup as RAID 0+1 to give me speed and redundancy, but this setup was no longer necessary after I sold my IT shop.

Instead of using RAID, I simply switched to individual drives and like others, I initially had issues with drives being assigned inconsistent drive paths at each boot, but only because I was being the "quintessentially anal Systems Administrator" who wanted to control every single aspect of my machine, shunning all modern advances, essentially making a rod for my own back. I've cooled down a little since then and now I leave fstab alone and use mount-on-demand through very clear partition labels.

In the Desktop Server machine which is really old now, (AMD Phenom 6-core) I now have only 1 sda that never changes, my MX-Linux boot drive, the others can be wherever they turn up, but their partition labels will always make them "appear" to be fully consistent to the operator at all times. To overcome my own weakness, I put physical labels on each drive that matched the label of the first primary partition on each drive so if there was an fault, I could address it without having to rely on ever-changing dynamic device paths.

Dynamically assigned SATA device paths have been in use for quite some time now so it's way past time to get over it all because the new way is beautifully simple and very intuitive to use when you "walk in it". This makes it super easy to simply click on a drive label as displayed in the File Browsers left pane to mount the drive. Once mounted, you can assign the dot file permission and allow non-root users to mount internal drives through MX Tweak > Other

MX Linux Forum

Reboot from live MX23 USB and disk IDs change

Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change

Re: Reboot from live MX23 USB and disk IDs change