MX-23 RC2 (KDE) feedback thread

[CharlesV]

Where is that minstall.log located ? I am not finding one.

only failures I am seeing in the live log are:

partprobe -s
FAILED Phase 2 - Failed to prepare required partitions.
Failed to copy the installation log to the target.

[CharlesV]

found it.

[fehlix]

found it.

Yeah, thst the same issue, I see:

Code: Select all

2023-07-15 18:05:35.535 DBG default: SErr #46: "Error: Partition(s) 1 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.\n"

I guess, the installer should try to not touch the liveUSB in any way.
But it does at least here:

Code: Select all

2023-07-15 18:05:17.009 DBG default: Exec #5: grub-probe -d /dev/sda2

and

Code: Select all

2023-07-15 18:05:32.645 DBG default: Exec #19: smartctl -H /dev/sda

and later fails.
So I guess with boot parameter "toram" and pull-out the liveUSB it would not make the installation fail.

[CharlesV]

Roger that. or writing ISO with Full-Featured mode :-)

Interesting that when on non writable mode the install defaults to the same USB - showing both USB and nvme in the drop down... however when its writable only the nvme shows up. ( probably failing some place before that, but I found that interesting. )

[dolphin_oracle]

We are in the esp thing. Might be a day or two. It’s actually trying to touch all the esps. Doesn’t format them just remarks as esp but that fails on read only devices. Ak-47 is changing that so only what’s marked to use actually gets touched.

[Danathar]

This is not so much a KDE bug as it is an overall issue that I was unable to test in the Beta release. I am testing this on the KDE RC2 currently.

I purchased an NVME thunderbolt USB-C enclosure (capable of USB 3, thunderbolt 3 and 4 connections). My plan was to put a 512GB NVMe drive in the enclosure, format it as a live USB drive with persistence, and use it by moving things like Steam game libraries over to the Live-USB drive folder. Alternatively, I wanted to try running it as p_static_root directly off of the drive.

The first problem is that when making the live USB drive with the utility, it can't see the thunderbolt drive when plugged into the usb-c port that has thunderbolt capability. It can see the drive if I plug it into the USB-A port instead.

The second issue is that after successfully creating a live USB with persistence using the USB-A port, when I rebooted I could select the thunderbolt-connected drive from the BIOS menu, but the bootloader was unable to see the drive.

I'm unsure if this is a kernel problem/configuration issue, or if booting a USB drive in Linux via a thunderbolt connection was never possible.

[andy]

Hello dear developers,
thank you for steady progress on release.
I was checking BTRFS with LUKS install. (it was on friday with RC1)

First, of course, I checked the ISO file copied into Ventoy, and a boot built in integrity check, too.
I did update before running installer.
(AFAI remeber, the first try running installer was without update, then thought about it, cancelled the process, did update and rerun the process. It was canceled after LUKS containers were created.)
And this brings me to my questions:

1. Install process last much longer, than in Beta2. Is this a feature, or a bug?
2. Where is the option to fill the containers with random data prior to LUKS format? (Security requirement to conceal usage pattern of a disk https://security.stackexchange.com/ques ... encryption). Is it done automatically without an option, hence the reason for longer install time? (should not be this case, as it seems the copying phase is slower, not formatting).
3. If the fill with random data is not done, MX installer should definitely allow user to prepare containers by himself, and do install into them without formatting them, by just picking-up their parameters such as device names/GUIDs, and passwords.
4. This seems not possible, as I tried to recycle root partition and separate home partition done by first install (I did not try to clear filesystem content though, right after cancelling of the first install try).
Installer allowed me to choose the ready LUKS containers, allow to unlock them, but did not allow to mark them for use as root or home.

Please, address these issues, to provide better encryption standards.
(I recall there was an option user can input additional encryption parameters, even random data overwrite, in the past versions of installer)
@dolphin_oracle , I remember you answered me, that you removed it, because there was not apparent use of it.
IMHO, the seeming absence of "real usage" does not mean there is no real usage. Not everyone who needs or wants better security will scream around about it, like me , and will boast what he uses. Do you remember, that a part of the security is to not letting the attacker know the internals of your system?

Thank you,
Regards,
Andy

[fehlix]

This is not so much a KDE bug as it is an overall issue that I was unable to test in the Beta release. I am testing this on the KDE RC2 currently.

I purchased an NVME thunderbolt USB-C enclosure (capable of USB 3, thunderbolt 3 and 4 connections). My plan was to put a 512GB NVMe drive in the enclosure, format it as a live USB drive with persistence, and use it by moving things like Steam game libraries over to the Live-USB drive folder. Alternatively, I wanted to try running it as p_static_root directly off of the drive.

The first problem is that when making the live USB drive with the utility, it can't see the thunderbolt drive when plugged into the usb-c port that has thunderbolt capability. It can see the drive if I plug it into the USB-A port instead.

The second issue is that after successfully creating a live USB with persistence using the USB-A port, when I rebooted I could select the thunderbolt-connected drive from the BIOS menu, but the bootloader was unable to see the drive.

What was the error message you got for this "unable to see the drive"?
Also, you may post this, when the USB-device is plugged into the thunderbolt.

Code: Select all

lsblk   -o NAME,FSTYPE,FSVER,LABEL,MAJ:MIN,RM,HOTPLUG

[Danathar]

This is not so much a KDE bug as it is an overall issue that I was unable to test in the Beta release. I am testing this on the KDE RC2 currently.

I purchased an NVME thunderbolt USB-C enclosure (capable of USB 3, thunderbolt 3 and 4 connections). My plan was to put a 512GB NVMe drive in the enclosure, format it as a live USB drive with persistence, and use it by moving things like Steam game libraries over to the Live-USB drive folder. Alternatively, I wanted to try running it as p_static_root directly off of the drive.

The first problem is that when making the live USB drive with the utility, it can't see the thunderbolt drive when plugged into the usb-c port that has thunderbolt capability. It can see the drive if I plug it into the USB-A port instead.

The second issue is that after successfully creating a live USB with persistence using the USB-A port, when I rebooted I could select the thunderbolt-connected drive from the BIOS menu, but the bootloader was unable to see the drive.

What was the error message you got for this "unable to see the drive"?
Also, you may post this, when the USB-device is plugged into the thunderbolt.

Code: Select all

lsblk   -o NAME,FSTYPE,FSVER,LABEL,MAJ:MIN,RM,HOTPLUG

This is the output when booted off of a non-persistent usb stick in the USB-A stick, nvme0n1 is the usb drive, nvme1n1 is my internal drive I've got Debian 12 on.

Code: Select all

NAME        FSTYPE      FSVER            LABEL       MAJ:MIN RM HOTPLUG
loop0       squashfs    4.0                            7:0    0       0
sda         iso9660     Joliet Extension MX-Live       8:0    1       1
├─sda1      iso9660     Joliet Extension MX-Live       8:1    1       1
└─sda2      vfat        FAT16            EFI-LIVE      8:2    1       1
nvme0n1                                              259:0    0       0
├─nvme0n1p1 ext4        1.0              MX-Live-usb 259:1    0       0
├─nvme0n1p2 crypto_LUKS 1                            259:2    0       0
└─nvme0n1p3 vfat        FAT32            MX-UEFI     259:3    0       0
nvme1n1                                              259:4    0       0
├─nvme1n1p1 vfat        FAT32                        259:5    0       0
├─nvme1n1p2 ext2        1.0                          259:6    0       0
└─nvme1n1p3 crypto_LUKS 2                            259:7    0       0

The error code if I boot off of the thunderbolt enclosure is:

Code: Select all

Fatal Error
No usb.cd devices found
	p = power off
	r = reboot
Select  p or r then press <enter>

I guess the live USB creator would be a separate issue that it can't see the enclosure drive?

[fehlix]

This is the output when booted off of a non-persistent usb stick in the USB-A stick, nvme0n1 is the usb drive, nvme1n1 is my internal drive I've got Debian 12 on.

Code: Select all

NAME        FSTYPE      FSVER            LABEL       MAJ:MIN RM HOTPLUG
loop0       squashfs    4.0                            7:0    0       0
sda         iso9660     Joliet Extension MX-Live       8:0    1       1
├─sda1      iso9660     Joliet Extension MX-Live       8:1    1       1
└─sda2      vfat        FAT16            EFI-LIVE      8:2    1       1
nvme0n1                                              259:0    0       0
├─nvme0n1p1 ext4        1.0              MX-Live-usb 259:1    0       0
├─nvme0n1p2 crypto_LUKS 1                            259:2    0       0
└─nvme0n1p3 vfat        FAT32            MX-UEFI     259:3    0       0
nvme1n1                                              259:4    0       0
├─nvme1n1p1 vfat        FAT32                        259:5    0       0
├─nvme1n1p2 ext2        1.0                          259:6    0       0
└─nvme1n1p3 crypto_LUKS 2                            259:7    0       0

The error code if I boot off of the thunderbolt enclosure is:

Code: Select all

Fatal Error
No usb.cd devices found
	p = power off
	r = reboot
Select  p or r then press <enter>

I guess the live USB creator would be a separate issue that it can't see the enclosure drive?

May be add/select from=all boot parameter.