CHOROBA: ok díky, skočim pro noý ssd

Celej dmesg vypis v priloze, kdyby se na to nekdo chtel kouknout, ja z toho nic nevyctu

• dmesg.txt

CHOROBA: mint@mint:~$ sudo dmesg | grep -i sata
[ 0.766718] ahci 0000:01:00.1: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[ 0.768294] ata1: SATA max UDMA/133 abar m131072@0xfc480000 port 0xfc480100 irq 38 lpm-pol 0
[ 0.768297] ata2: SATA max UDMA/133 abar m131072@0xfc480000 port 0xfc480180 irq 38 lpm-pol 0
[ 0.768300] ata3: SATA max UDMA/133 abar m131072@0xfc480000 port 0xfc480200 irq 38 lpm-pol 0
[ 0.768302] ata4: SATA max UDMA/133 abar m131072@0xfc480000 port 0xfc480280 irq 38 lpm-pol 0
[ 0.768305] ata5: SATA max UDMA/133 abar m131072@0xfc480000 port 0xfc480300 irq 38 lpm-pol 0
[ 0.768307] ata6: SATA max UDMA/133 abar m131072@0xfc480000 port 0xfc480380 irq 38 lpm-pol 0
[ 1.075473] ata1: SATA link down (SStatus 0 SControl 300)
[ 1.549306] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 56.997783] ata3: limiting SATA link speed to 3.0 Gbps
[ 62.510982] ata4: SATA link down (SStatus 0 SControl 300)
[ 62.822996] ata5: SATA link down (SStatus 0 SControl 300)
[ 63.134952] ata6: SATA link down (SStatus 0 SControl 300)

no a dmesg? tam asi bude napsano proc se disk nepripoji.
kaxdoropadne to vypada ze je nejak umrelej

CHOROBA: to jsem zkoušel, systém ten disk vůbec nevidí. Měl by to být 256GB ssd, ale vidím jen toto:

mint@mint:~$ sudo fdisk -l
Disk /dev/loop0: 2.29 GiB, 2456621056 bytes, 4798088 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EZBX-00A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xe0efe9fb

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 3907026943 3907024896 1.8T 7 HPFS/NTFS/exFAT


Disk /dev/sdb: 28.87 GiB, 30995907072 bytes, 60538881 sectors
Disk model: DataTraveler 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x712697c0

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 64 5679359 5679296 2.7G 0 Empty
/dev/sdb2 8644 18883 10240 5M ef EFI (FAT-12/16/32)
/dev/sdb3 5681152 60538880 54857729 26.2G 83 Linux

nabootuj z flash a mrkni co vypise dmesg, tam urcite bude nejaka hlaska co se stalo, fdisk -l taky pomuze, pripadne pak smartctl -a /dev/XXX

Ahoj, znicehonic mi zamrzl mint na savescreenu, po resetu zamrzá na blackscreenu před bootem. Po stisktnutí shiftu naběhne grub (?) boot menu, ale úplně stejně to zamrzne i při pokusu o recovery mode nebo s boot parametrem "nomodeset". Systémové SSD vidím v biosu, ale zaboha ho nevidím v linuxu po naběhnutí live usb, vidím jen datový disk, flešku a nějaký particle /dev/loop0: 2.29GiB, který nevím, co je.
SATA slot jsem změnil. V Biosu by všechno mělo být ok, koneckonců to běželo několik posledních měsíců bez problémů. Poslední updaty jsem dělal už před několika dny.
Je to disk v prdeli? U toho mi ale nesedí, že naběhne to grub boot menu.

BOD1E: jo, takhle by to melo fungovat. zkus, uvidis.

BOD1E: vyberes si nejakou jinou sluzbu, co startuje hodne pomalu ;-) pokud vim, neexistuje direktiva, ktera by rikala 'nastartuj neco jako posledni'

PUPU: OK, takže u aplikace nastavím (DB servis se jmenuje postship.service):

After=postship.service

ale co nastavím u postship.service, když chci dosáhnout toho aby startovala až na samé finále?

BOD1E: man systemd.unit

Before=, After=
A space-separated list of unit names. Configures ordering dependencies between units. If a unit foo.service contains a setting Before=bar.service and both units are being
started, bar.service's start-up is delayed until foo.service is started up. Note that this setting is independent of and orthogonal to the requirement dependencies as
configured by Requires=. It is a common pattern to include a unit name in both the After= and Requires= option, in which case the unit listed will be started before the unit
that is configured with these options. This option may be specified more than once, in which case ordering dependencies for all listed names are created. After= is the
inverse of Before=, i.e. while After= ensures that the configured unit is started after the listed unit finished starting up, Before= ensures the opposite, i.e. that the
configured unit is fully started up before the listed unit is started. Note that when two units with an ordering dependency between them are shut down, the inverse of the
start-up order is applied. i.e. if a unit is configured with After= on another unit, the former is stopped before the latter if both are shut down. If one unit with an
ordering dependency on another unit is shut down while the latter is started up, the shut down is ordered before the start-up regardless of whether the ordering dependency
is actually of type After= or Before=. If two units have no ordering dependencies between them, they are shut down or started up simultaneously, and no ordering takes place.

Ahojte, mám takovýto problém. Na RHEL 8 mi běží aplikační server, který sestává (jak už to tak bývá) z databáze (postgres, resp. jeho fork), do níž se spojí po startu aplikace. Máme nastaveno tak, aby při bootu server vše naběhlo automaticky. Bohužel, databáze při autostartu vždycky spadne s nějakým záhadným problémem s uživatelem.

Manuální start po bootu serveru už proběhne v pořádku.

Já se domnívám, že databáze startuje příliš brzy, když ještě není plně vytvořené multiuživatelské prostředí, nejsou přimontované filesystémy atd. A chtěl bych dosáhnout toho, aby tady v tom systemd prostředí databáze a aplikace startovaly jako předposlední a poslední služby. A nevím jak na to a náš Linux support team z Indie taky ne.
Poradíte?

DANIELSOFT: právě že kompatibilitu jsem řešil a tenhle vypadal ok. Jedu na Manjaro a kernel je 6.12.1-4, ale kernel jsem už měnil.

B3TL: s těma herníma periferiema je to všelijaký: já měl normální Logitech gamepad, ale po update na novou verzi Xubuntu mi přestal fungovat, tak jsem koupil novej gamepad od jiného výrobce a ten jede, ale v některých emulátorech (např. fuse: emulátor ZX Spectra) to furt všelijak blbne, tak bych se nedivil, že když jsou problémy s tak relativně jednoduchýma periferiema, že s volantem může být problém

driver je v jádře, čili pokud máš nějakou možnost nové verze linuxového jádra (ale zas to asi nestojí za to rozšmelcovat si celý systém: nenapsal jsi co používáš za distro Linuxu, například v Ubuntu se dají novější jádra zapnout, hledej "Ubuntu HWE")

dále je samozřejmě hraběcí rada koupit novej volant jiné značky a nějak si před tím vygooglit tu kompatibilitu s Linuxem a tenhle třeba prodat abys nebyl škodnej

zdarec, řeším problém s volantem od Logitechu. Volant jsem koupil někdy v létě a běžně jsem ho používal. Od začátku bylo potřeba po připojení spustit příkaz $ sudo usb_modeswitch -v 046d -p c26d -M 0f00010142 -C 0x03 -m 01 -r 01 , jinak se volant po zapnutí při kalibraci otočil do jedný krajní polohy a pak nic nedělal. Ten příkaz způsobil, že se volant normálně zkalibroval a v centrální poloze ho normálně držel motor a tak by to mělo být. Volant jsem teď tak dva měsíce nepoužil a nyní po zapnutí je chování téměř stejné, jen volant po kalibraci zůstane v centrální poloze, ale zhasne a motor je vypnutý. Takže volant ma vypnutý ffb. V Oversteer jsou vidět funkční všechny osy a test taky proběhne ok. Volant ale po testu je zase bez FFB.... Zkoušel jsem to i v AssetoCorsa, nebo BeamNG a FFB prostě nejde...
Prosím netušíte někdo jakým směrem se mám vydat?


Takhle to vypada v terminálu:

sudo usb_modeswitch -v 046d -p c26d -M 0f00010142 -C 0x03 -m 01 -r 01  ✔
[sudo] heslo pro martin:
Look for target devices ...
No devices in target mode or class found
Look for default devices ...
Found devices in default mode (1)
Access device 009 on bus 005
Get the current device configuration ...
Current configuration number is 1
Use interface number 0
with class 255
Use endpoints 0x01 (out) and 0x01 (in)
Looking for active drivers ...
Set up interface 0
Use endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent

Reset response endpoint 0x01
Reset message endpoint 0x01
-> Run lsusb to note any changes. Bye!

A ješte lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 003: ID 0b05:19af ASUSTek Computer, Inc. AURA LED Controller
Bus 001 Device 004: ID 046d:c33f Logitech, Inc. G815 Mechanical Keyboard
Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub
Bus 005 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 005 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 005 Device 005: ID 08bb:2902 Texas Instruments PCM2902 Audio Codec
Bus 005 Device 006: ID 046d:c08b Logitech, Inc. G502 SE HERO Gaming Mouse
Bus 005 Device 007: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
Bus 005 Device 008: ID 0d8c:0012 C-Media Electronics, Inc. MARANTZ M4U
Bus 005 Device 010: ID 046d:c26e Logitech, Inc. G923 Racing Wheel for Xbox One and PC
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 006 Device 002: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub
Bus 006 Device 003: ID 0bda:0411 Realtek Semiconductor Corp. Hub

SUCHRE: MC se zapnutým 'lynx like motions' na rychle proběhnutí se po nějake adresařove struktuře pro zakladni prehled jak asi vypadá
jinak je to v podstatě k ničemu.