EasyOS Scarthgap-series version 6.3.1

[Federico]

I will have to do further testing.
As already said, it could be just related to my video chip (or other piece of hardware).
By the way: I've also set a file system encryption password.
Anyway, I will install it on another stick, so that we can exclude further possible causes, and I'll report back.

[Federico]

On my laptop the integrated touchpad did break, so I decided to disable it inside the BIOS and remove it physically from the chassis (to save weight and improve cooling), since I basically do not use it (only work with mouse).
Could it be that for some reason the Linux kernel 6 (and not the 5) or maybe the new X server does not like this situation? For checking this, someone should try to disable the touchpad from the bios and see what happens after 2 or 3 reboots. Will report back tomorrow.

Thanks in advance.

[Federico]

So, I tried to write the Easy Scarthgap image on an older 32 GB Lexar USB stick and it never booted. The boot process always ended up in a black screen or, jet worse, in kernel panic, saying in red that the file easy.sfs could not be found. I reformatted this stick several times and always got the same results. I had already used this stick in the past for Easy Dunfell and Easy Kirkstone.
At this point I'm starting to think that either all of my USB sticks are suddenly broken, all at once, or the new system uses a new file system or something new for which USB sticks are not usable any more (that is: USB flash support has been dropped as a whole), or for which newer and faster USB sticks are needed.
Easy Kirkstone still works correctly on Sandisk 128 GB Ultra Dual for me. I've been trying Easy Scarthgap on Sandisk 64 GB Ultra Flair and Lexar 32 GB JumpDrive M20c

This is my hardware:

Code: Select all

# lspci
0000:00:00.0 Host bridge: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers (rev 01)
0000:00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
0000:00:04.0 Signal processing controller: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant (rev 01)
0000:00:07.0 PCI bridge: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #0 (rev 01)
0000:00:07.2 PCI bridge: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #2 (rev 01)
0000:00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator module (rev 01)
0000:00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01)
0000:00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 (rev 01)
0000:00:0d.3 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #1 (rev 01)
0000:00:0e.0 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller
0000:00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller (rev 20)
0000:00:14.2 RAM memory: Intel Corporation Tiger Lake-LP Shared SRAM (rev 20)
0000:00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20)
0000:00:15.0 Serial bus controller: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 (rev 20)
0000:00:15.1 Serial bus controller: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1 (rev 20)
0000:00:16.0 Communication controller: Intel Corporation Tiger Lake-LP Management Engine Interface (rev 20)
0000:00:1c.0 PCI bridge: Intel Corporation Device a0bc (rev 20)
0000:00:1d.0 System peripheral: Intel Corporation RST VMD Managed Controller
0000:00:1f.0 ISA bridge: Intel Corporation Tiger Lake-LP LPC Controller (rev 20)
0000:00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)
0000:00:1f.4 SMBus: Intel Corporation Tiger Lake-LP SMBus Controller (rev 20)
0000:00:1f.5 Serial bus controller: Intel Corporation Tiger Lake-LP SPI Controller (rev 20)
0000:57:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)
10000:e0:1d.0 PCI bridge: Intel Corporation Tiger Lake-LP PCI Express Root Port #9 (rev 20)
10000:e1:00.0 Non-Volatile memory controller: Intel Corporation SSD 660P Series (rev 03)
# 

And, as already said, my internal pointing device has been disabled in BIOS. I'm investigating furtherly.
I would like to know make and model of the USB stick used by someone who successfully boots Scarthgap an indefinite amount on times from USB flash memory.

[williwaw]

So, I tried to write the Easy Scarthgap image on an older 32 GB Lexar USB stick and it never booted. The boot process always ended up in a black screen or, jet worse, in kernel panic, saying in red that the file easy.sfs could not be found.

"Easy.sfs could not be found" could more likely be a bootlaoder misconfiguration than a kernel panic.
can you describe your bootloader and configs. Did you install easy by dd'ing the easyos.img or extract the files from the image to make a frugal install?

[BarryK]

On my laptop the integrated touchpad did break, so I decided to disable it inside the BIOS and remove it physically from the chassis (to save weight and improve cooling), since I basically do not use it (only work with mouse).
Could it be that for some reason the Linux kernel 6 (and not the 5) or maybe the new X server does not like this situation? For checking this, someone should try to disable the touchpad from the bios and see what happens after 2 or 3 reboots. Will report back tomorrow.

Thanks in advance.

Note also, the menu "Desktop -> Toggle touchpad on or off"

If you have removed the touchpad, yet the interface chip is still there, it might be causing a problem.
Though, as you disabled it in bios, I don't see that as a problem.

Anyway, just in case, try that menu entry, to toggle touchpad off.

[Federico]

Thanks in advance. I'm just trying to understand what's gooing on.

I low level formatted the USB stick Lexar 32 GB JumpDrive M20c using diskpart and the clean all command on Windows, it took some time (about 10 minutes). Then I used once again USB Image Tool to rerstore the Easy Scarthgap image (Easy_Scarthgap_5.93-amd64.img) onto it. When I try to boot my laptop with it, this is, exactly, the consecutio temporum of the events:

1) I choose the keyboard layout:

1.jpg (36.65 KiB) Viewed 1224 times

2) easy.sfs is not found and then I get dropped to the command prompt, where I'm asked to type exit in order for the boot process to continue:

2.jpg (44.3 KiB) Viewed 1224 times

3) I get a red message stating: << Error: Failed to mount easy.sfs. Have now dropped into a shell in the initramfs. Please hit the CTRL-ALT-DEL key combination to reboot, or HOLD DOWN THE POWER BUTTON TO SHUTDOWN >> and << The following instructions are developers only: Line 1941: Failed to mount easy.sfs. Note 1: Type "exit", the init script will attempt to continue. Note 2: bla bla bla. Note 3: bla bla bla. Note 4: bla bla bla. Note 5: bla bla bla. >> If I type exit on the prompt once again I get kernel panic:

4.jpg (44.39 KiB) Viewed 1224 times

with the typical caps lock led blinking and the only thing I can do is keeping pressed the power button for shutting down.

Now, this all looks not normal to me. Either the kernel is buggy generally speaking, or developers have dropped the flash memory support as a whole, or faster / better USB flash drives are needed for booting the 6.x kernel.

[Federico]

I also expect someone to either have the same issues or tell me make and model of the USB stick being used.

[CF-DKS]

I also expect someone to either have the same issues or tell me make and model of the USB stick being used.

I have run into this myself, only happens on desktop computers and is intermittent, i.e. sometimes it boots fine, other times I get the error you got. Have had it occur with several Kirkstone editions, never with Dunfell, where everything is in the same partition. See my post about the problem. (I have yet to find a solution, but in most cases if I reboot a couple of times it comes up normally. And only occurs on my desktop computers, of which I have three) Using Kingston USB sticks, 32 and 64 G. Have not had it occur with Easy booting from the hard drive.

viewtopic.php?t=11015

[Federico]

Thank you very much. This is interesting.

Probably there is a minimum read / write speed problem when using USB flash memories. This would explain what I'm experiencing with the Lexar stick, which is in fact dated (although it used to work for testing in the past).

Now I'm trying to low level format the 64 GB SanDisk stick, on which I also tested Quantum Vis, and I'm seeing that diskpart isn't able to finish the execution of the command (no output for ever).
Everything is letting me think that the stick itself is broken / defective, and this would also explain why I had exactly the same issue with the X server not starting on both Quantum Vis and Scarthgap, because I have used for them the same USB stick. In that case, the stick itself would be defective and neither the kernel nor the video driver. I hope so. I didn't use it much but on the other hand these flash drives are quite fragile and tend to last even shorter when used only occasionally.
Anyway, to assure this I will have to buy a new stick, and since I'm facing financial difficulties at the moment, I don't know when I'll be able to report back.
I will try to give an answer as soon as possible.

Cheers

[CF-DKS]

Thank you very much. This is interesting.

Probably there is a minimum read / write speed problem when using USB flash memories. This would explain what I'm experiencing with the Lexar stick, which is in fact dated (although it used to work for testing in the past).

Now I'm trying to low level format the 64 GB SanDisk stick, on which I also tested Quantum Vis, and I'm seeing that diskpart isn't able to finish the execution of the command (no output for ever).
Everything is letting me think that the stick itself is broken / defective, and this would also explain why I had exactly the same issue with the X server not starting on both Quantum Vis and Scarthgap, because I have used for them the same USB stick. In that case, the stick itself would be defective and neither the kernel nor the video driver. I hope so. I didn't use it much but on the other hand these flash drives are quite fragile and tend to last even shorter when used only occasionally.
Anyway, to assure this I will have to buy a new stick, and since I'm facing financial difficulties at the moment, I don't know when I'll be able to report back.
I will try to give an answer as soon as possible.

Cheers

I don't know how much is about the USB sticks, since the only time I encounter a problem is on desktop computers, my three and my sister's one. And it is intermittent. The one I am currently using (Kirkstone 5.6.1) has never had this issue on any computer, but the 5.6.1. I gave to my sister has. Go figure.

[Federico]

The flash memory technology is not meant for hosting operating systems. Its correct usage would be theoretically just to store data of some kind, not be run operating systems on.
In fact, as you can read here on the section Limitations --> Memory wear, it has a finite number of program – erase cycles.
The fact that it works and that certain operating systems, like our beloved EasyOS, have been optimized as far as possible for usage on them does not directly imply that the problem doesn't exist.
During the Apollo 13 mission they used the landing engine of the lunar module to correct the route: it worked but that was not the usage that engine had been meant for. And this is quite exactly what people do when running operating systems from USB sticks.
If the PC is a desktop or a laptop, that does not make any difference. Important factors may be the USB type (USB 2.x can supply up to 2.5 Watts of power per port, whilst USB 3.x can supply up to 4.5 Watts of power per port), the age of the stick (newer sticks tend to be bigger, faster and more relyable) and for some reason, which I haven't identified jet, the frequency of use: it looks like the more often a stick is used, the longer will it last.

[CF-DKS]

The flash memory technology is not meant for hosting operating systems. Its correct usage would be theoretically just to store data of some kind, not be run operating systems on.
In fact, as you can read here on the section Limitations --> Memory wear, it has a finite number of program – erase cycles.
The fact that it works and that certain operating systems, like our beloved EasyOS, have been optimized as far as possible for usage on them does not directly imply that the problem doesn't exist.
During the Apollo 13 mission they used the landing engine of the lunar module to correct the route: it worked but that was not the usage that engine had been meant for. And this is quite exactly what people do when running operating systems from USB sticks.
If the PC is a desktop or a laptop, that does not make any difference. Important factors may be the USB type (USB 2.x can supply up to 2.5 Watts of power per port, whilst USB 3.x can supply up to 4.5 Watts of power per port), the age of the stick (newer sticks tend to be bigger, faster and more relyable) and for some reason, which I haven't identified jet, the frequency of use: it looks like the more often a stick is used, the longer will it last.

I have only my own experience to go on, but I have been using USB flash drives for 12 years, overwriting the data lots of times for use in playing videos on my TV and for audio use in my car, not to mention using the same one booting Easy Dunfell 3.4.3 as my daily driver for the past two and a half years on my primary desktop computer. Haven't had any with an O/S installed fail yet, only the quirky behavior I outlined in my post. Those that gave me issues on my desktop computers have been reliable on my two laptops. Coincidence or is there something that causes the intermittent problem on desktops only? I do love a good mystery!

[BarryK]

@Federico
I regularly use very old usb sticks without any problems.

When it says has dropped you to a shell, and you have the "#" prompt, you can do some troubleshooting.

To find out what partitions the kernel is seeing:

Code: Select all

# blkid

LABEL="easy2" TYPE="ext4" will be the second partition of the usb stick.
Look at what device is being identified at start of that line, for example /dev/sdb2

Then attempt to mount it:

Code: Select all

# mkdir -p /mnt/test
# mount -t ext4 /dev/sdb2 /mnt/test

If that succeeds, it may indicate a timing problem, somehow the drive partition needs more time to be able to mount it.

Let me know result of above tests.

[BarryK]

@Federico ,
Also, I would like to know what usb socket you have plugged into.

Is it a usb hub?

Is it a usb2, usb3.0, usb3.1 or usb3.2 interface?

Is it a type-A or type-C socket?

[Federico]

Thank you so much Barry!

I will try those commands at the prompt on the older stick as soon as possible. It would be nice not to have to buy a new one but anyway, that's no catastrophe: there are worse things in life.

Now I'm still trying to understand if the SanDisk is totally broken or somehow recoverable. The diskpart has been running like this more than 1 hour long by now:

formatting stick.jpg (72.66 KiB) Viewed 1147 times

I think that we have found the reason of my trouble. It's always difficult to deal with these things because they tend not to break completely: they just slowly become defective.
And maybe this went bad exactly because having used it just for testing, I reformatted it many times. Who knows?
Anyway, now going out to buy a new one.

Ah yes, and:

- USB type A
- USB 3.0
- no hub --> direct connection

I will post a picture of the new stick, so that in case of problems we can agree on the suitability of the hardware.

Thanks again.

[BarryK]

@Federico
I have never low-level formatted a usb flash drive, it isn't necessary.

You just write the .img file to the drive. That's it.

You can use a Windows tool to do that, but if running EasyOS or Puppy, can use easydd, which has the advantage that it reads back what has been written, to verify correctly written.

[Flash]

Not only is it not necessary to format a flash drive, formatting it wears it out prematurely. Every erase-write cycle "wears out" a flash memory cell a little bit. From what I've read, they get around 100,000 to a million erase-write cycles before they begin to give errors. This would be decades of normal use. But they fail by gradually giving more and more errors; not like hard disk drives, which fail utterly, catastrophically and without warning.

[Federico]

Of course I only low-level-formatted it because I thought that something was not OK with the drive (or was left badly written onto the drive). Or, it's the same, to make 100% sure that the transcription of the image onto the drive through USB Image Tool would have been done correctly.

Anyway, I just bought my new testing stick: a very simple but effective choice:

IMG_20240615_200048.jpg (56.39 KiB) Viewed 1090 times

instead of the Ultra Flair this time I took the simpler (and slower) Ultra. Already installed Easy Scarthgap on it and now posting this message from Scarthgap.
There wasn't much choice at the store: only SanDisk and Intenso. My only concern now is the temperature, because plastic does not conduct heat.
Has anybody had bad experiences with this? If yes, speak now or never.
Anyway, now I should try to reboot 2 or 3 times and let's see what happens.

[williwaw]

@Federico , EasyDD also reports actual write speed which is a nice way of evaluating USB quality

[Federico]

@Federico , EasyDD also reports actual write speed which is a nice way of evaluating USB quality

Thank you for the tip. I will try the program. I will tell you all something: low-level-formatting a flash drive is also a way to check its physical integrity. Normally, if a drive is broken / defective it can't finish a low-level-format procedure. Either the system reports an irrecoverable error or the procedure simply freezes and lasts for ever.
Now watching the Le Mans 24 hours race. I'll be back tomorrow.

Good night everyone.

[Federico]

OK people,

I'm unhappy and also a little bit frustrated to communicate that the problem reappeared identical exactly at the third reboot, even by using this brand new stick. Now I have to verify if the stick is still fully functional (I hope so). But anyway, all these issues did never occur when using Easy Kirkstone for me. It is a little bit annoying, especially as long as no other people show up with the same symptoms.
Anyway, I think I have to report my experience as detailed as possible, regardless of the outcome.
My hardware:

Code: Select all

# lspci
0000:00:00.0 Host bridge: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers (rev 01)
0000:00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
0000:00:04.0 Signal processing controller: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant (rev 01)
0000:00:07.0 PCI bridge: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #0 (rev 01)
0000:00:07.2 PCI bridge: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #2 (rev 01)
0000:00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator module (rev 01)
0000:00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01)
0000:00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 (rev 01)
0000:00:0d.3 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #1 (rev 01)
0000:00:0e.0 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller
0000:00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller (rev 20)
0000:00:14.2 RAM memory: Intel Corporation Tiger Lake-LP Shared SRAM (rev 20)
0000:00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20)
0000:00:15.0 Serial bus controller: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 (rev 20)
0000:00:15.1 Serial bus controller: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1 (rev 20)
0000:00:16.0 Communication controller: Intel Corporation Tiger Lake-LP Management Engine Interface (rev 20)
0000:00:1c.0 PCI bridge: Intel Corporation Device a0bc (rev 20)
0000:00:1d.0 System peripheral: Intel Corporation RST VMD Managed Controller
0000:00:1f.0 ISA bridge: Intel Corporation Tiger Lake-LP LPC Controller (rev 20)
0000:00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)
0000:00:1f.4 SMBus: Intel Corporation Tiger Lake-LP SMBus Controller (rev 20)
0000:00:1f.5 Serial bus controller: Intel Corporation Tiger Lake-LP SPI Controller (rev 20)
0000:57:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)
10000:e0:1d.0 PCI bridge: Intel Corporation Tiger Lake-LP PCI Express Root Port #9 (rev 20)
10000:e1:00.0 Non-Volatile memory controller: Intel Corporation SSD 660P Series (rev 03)
# 

And I've tried Easy Scarthgap and Qauntum Vis on SanDisk Ultra Flair and SanDisk Ultra, both in the size of 64 GB. Actually running EasyOS Kirkstone 5.8.3 without problems on SanDisk Ultra Dual 128 GB and I've been running it since 2 years ago.

If anyone has any ideas, thank you very much in advance.

[bugnaw333]

I never low level format USB sticks ever since.
I use EasyDD and Rufus (Windows) for writing ISO and img. files on stick.

[tammi806]

I have had problems with SanDisk usb flash drives over the years.

It's been hit and miss for me when using SanDisk usb flash drives for installing and running Linux on.

Lexar and PNY 2.0 usb flash drives are what I've had the best luck using.

Most of my computers are old dual core with ddr2 memory and mechanical HDD.

I've never owned an SSD and closet thing to an SSD I've ever gotten are my usb flash drives.

[BarryK]

I'm unhappy and also a little bit frustrated to communicate that the problem reappeared identical exactly at the third reboot, even by using this brand new stick. Now I have to verify if the stick is still fully functional (I hope so). But anyway, all these issues did never occur when using Easy Kirkstone for me. It is a little bit annoying, especially as long as no other people show up with the same symptoms.

You haven't performed the test I requested earlier.

[Federico]

Hi Barry, here is morning.
of course will do. Will reply later with the corresponding outcome.

[bugnaw333]

@ETP

Startup_ Welcome_ Alert_ for_ EasyOS-2023MK3 is not working on Scarthgap version.

[Federico]

Sorry for being late, I wanted to watch the race.

So, I tried again to boot with my older 32 GB Lexar drive.

Screenshot(12).jpg (17.94 KiB) Viewed 885 times

I tried to issue the suggested commands, and this is the subsequent output:

Screenshot(11).jpg (91.1 KiB) Viewed 885 times

as you can see, no sdb2 partition is being detected at all, there is only zram0 and the integrated SSD.

Now I'm going to check the physical integrity of my brand new SanDisk Ultra and I'll report back.

[Federico]

First of all, I connected the stick to a second port and checked it (brand new SanDisk Ultra) on EasyOS Kirkstone through fsck:

Code: Select all

# blkid
/dev/sdb1: SEC_TYPE="msdos" UUID="7982-9D4D" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="fe5f3c11-01"
/dev/sdb2: LABEL="easy2" UUID="ceba2dd2-2803-11ef-ba2f-000f53b0173e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="fe5f3c11-02"
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="MYASUS" UUID="0022-7292" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="b41d4113-3fb0-4e06-badf-2219f64b5e0d"
/dev/nvme0n1p3: LABEL="OS" BLOCK_SIZE="512" UUID="92BAA91DBAA8FEBB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="9191f304-fb6f-4649-9bcc-9edef32aa7d9"
/dev/nvme0n1p1: LABEL="SYSTEM" UUID="16A7-5956" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="595beec2-6250-4a5d-91dc-b3a4238efd8d"
/dev/nvme0n1p4: LABEL="RECOVERY" BLOCK_SIZE="512" UUID="1AEA50ACEA508643" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="21333c7e-8422-4f0d-a0d0-f1d5e0fccc07"
/dev/zram1: LABEL="TOPLEVELZRAM" UUID="beb3d92b-93a7-421d-a80c-61582ee7a1e2" BLOCK_SIZE="4096" TYPE="ext2"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/sda2: LABEL="easy2" UUID="18c32b8a-ea53-11ed-a597-70a8d37a8aff" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cf4ab0bc-02"
/dev/sda1: SEC_TYPE="msdos" UUID="332D-1209" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="cf4ab0bc-01"
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="2e86ea69-e836-4b6c-9859-104c43f88f64"

# fsck /dev/sdb2
fsck von util-linux 2.37.4
e2fsck 1.46.5 (30-Dec-2021)
easy2 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create<y>? yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (13895758, counted=13895757).
Fix<y>? yes
Free inodes count wrong (3729932, counted=3729931).
Fix<y>? yes

easy2: ***** FILE SYSTEM WAS MODIFIED *****
easy2: 30197/3760128 files (0.9% non-contiguous), 1122739/15018496 blocks
# fsck /dev/sdb2
fsck von util-linux 2.37.4
e2fsck 1.46.5 (30-Dec-2021)
easy2: clean, 30197/3760128 files, 1122739/15018496 blocks
# 

as you can see, the file system was damaged. But the point is: why was it damaged? Even if the X server did not start at the 3rd attempt, I correctly pressed Ctrl+Alt+F2 and powered off the system regularly by issueing the poweroff command. So, something does not look to be working as expected. I can now try to boot once again and see if I reach the desktop but I fear that the loop repeats itself.

[Federico]

I retried to boot the system with the SanDisk Ultra and, as expected, the X server did not start:

Screenshot(13).jpg (45.83 KiB) Viewed 873 times

Afterwards, I rechecked the stick with fsck from EasyOS Kirkstone and it looks OK (clean). There is no damage / data corruption onto the drive. It looks to work fine physically. Still, I do not know / understand why the X server stops working after a short while.

[BarryK]

OK, your test running "lsblk" shows that the Linux kernel does not recognise the existence of the usb partitions.

As you have reported Kirkstone running, which has the 5.15.x kernel, it seems the problem is with the 6.6 kernel.

It would seem that one possible solution would be to run Scarthgap with the 5.15.x kernel.

I don't know why the 6.6 kernel has this problem, and it is especially strange that it worked the first few bootups.

You will probably find that if you install Scarthgap to the internal drive, it will work, as lsblk shows that it recognises it.