Enterre továbbment abba nem volt hiba de nem lehetett beállítani 30 helyett 5 másodpercet.

Erre semmit nem produkál, csak egy kötőjelet ad vissza,

tibi@TibiXubuntu:~$ stat -c %w /
-
tibi@TibiXubuntu:~$

sudo dumpe2fs /dev/sda1 | grep 'Filesystem created:'

Egyebkent nalam ez is mukodik:
stat -c %w /

Nálam (Fedora 39 alatt) van ilyen fájl:

root@fujitsu-fedora:/etc/grub.d$ ls
00_header 08_fallback_counting 10_reset_boot_success 14_menu_show_once 20_ppc_terminfo 30_uefi-firmware 40_custom README
01_users 10_linux 12_menu_auto_hide 20_linux_xen 30_os-prober 35_fwupd 41_custom

De egyébként ez egy bug Grub-ban Ubuntuban. A GRUB_RECORDFAIL_TIMEOUT paraméter állítható (lenne, ha jól működne) az /etc/default/grub-ban, és biztos, hogy köze van az EFI-hez, mert eleve egy [ \$grub_platform = efi ] feltételben van az egész.
Itt van a leírás erről az egészről: https://nelsonslog.wordpress.com/2022/08/16/grub-recordfail-30-seconds/

Az más kérdés, hogy a GRUB_RECORDFAIL_TIMEOUT paramétert csak akkor szabadna számításba vennie a Grub-nak, ha hibásan áll le a rendszer, alapesetben nem.

Egyébként a stat -c %w / nálam 2023-09-02 13:26:46.472632875 +0200-t ad vissza, ez biztos, hogy nem jó. A sudo dumpe2fs /dev/sda1 | grep 'Filesystem created:' pedig azt, hogy dumpe2fs: Hibás bűvös szám a szuperblokkban a(z) /dev/sda1 megnyitására tett kísérlet közben

[ Szerkesztve ]

A /dev/sda1 a rendszerparticio?
[link]

[ Szerkesztve ]

Ez már működik és reálisnak is tűnik.

tibi@TibiXubuntu:~$ sudo dumpe2fs /dev/sda1 | grep 'Filesystem created:'
[sudo] tibi jelszava:
dumpe2fs 1.44.1 (24-Mar-2018)
dumpe2fs: Hibás bűvös szám a szuperblokkban a(z) /dev/sda1 megnyitására
tett kísérlet közben
tibi@TibiXubuntu:~$

Ez most az a gépem a melóhelyen ami tényleg a legelső telepítés, még 2 másikra lett klónozva.
Hazaérek megnézem a másik kettőt de ugyanaz lesz gondolom a végeredmény.

Ez a zarojelben levo (24-Mar-2018) idopont, a dumpe2fs 1.44.1 verzioszam
kiadasanak idejere utalhat.
Nem a telepites idejere - szerintem.
Nalam a telepites idejet ilyen formaban irja ki:
Filesystem created: Sat Sep 16 19:20:16 2023

Fura, nálam az a rövid parancs működött innen

How To Find Exact Installation Date And Time Of Your Linux OS

Amit growler kolléga írt, az is jó. Nekem ezek nem írtak ki semmit:

ubyegon@ubyMintC-212:~$ stat / | grep "Birth" | sed 's/Birth: //g' | cut -b 2-11
ubyegon@ubyMintC-212:~$ stat / | awk '/Birth: /{print $2}'
ubyegon@ubyMintC-212:~$ sudo stat / | awk '/Birth: /{print $2}'

Akkor ez a GRUB probléma tényleg Ubuntu bug lehet.

Lehet hogy nalunk azert mukodik mindket fenntebbi parancs, mert
Linuxot hasznalunk?
(Nem hagyhattam ki ezt a ziccert!)

[ Szerkesztve ]

Akkor passz. Nálam ezekszerint nem lehet megnézni.

A kötőjel az jelenti, hogy ismertelen. A stat --help leírja. Virtualboxos Xubuntu nekem is ezt dobja, míg a natív Lubuntu korrekt értéket ad.

Okos mérnök a hülyeséggel is kalkulál. Avagy, a "Figyelj oda jobban" tábla nem munkavédelmi eszköz....

Ha hazaértem, megnézem. De gyanítom, hogy az sda1 az efi partíció lesz, most így fejből nem tudom.

Viszont itt, a céges gépemen mindkét parancs jó adatot ad vissza:

Filesystem created: Thu Dec 21 11:54:11 2023

2023-12-21 11:54:14.026975227 +0100

Tuti nem állok a sötét oldalra, annyi pálinka a világon nincs! Amúgy először nem is magamra értettem a poent...

Leltem egy Ubuntut, azon meg ez mutatja, de nyilván ha logokat nyitogat az ember, term.log és társai, ott is megvan az első bejegyzés. Nálad szerintem az a sda1 nem valid, csak elsiklottál efelett kissé.

sudo grep 'RTC time' /var/log/installer/syslog

ubyegon@UbMte2204-8570p:~$ sudo grep 'RTC time' /var/log/installer/syslog
Apr 30 18:12:19 ubuntu-mate kernel: [ 0.153557] PM: RTC time: 18:12:00, date: 2023-04-30

Ez valamilyen Ubuntu humor? Képzetlen vagyok az értelmezésére.

sda 8:0 0 119,2G 0 disk
├─sda1 8:1 0 600M 0 part /boot/efi
├─sda2 8:2 0 1G 0 part /boot
└─sda3 8:3 0 117,7G 0 part /home

root@fujitsu-fedora:~$ dumpe2fs /dev/sda1 | grep 'Filesystem created:'
dumpe2fs 1.47.0 (5-Feb-2023)
dumpe2fs: Hibás bűvös szám a szuperblokkban a(z) /dev/sda1 megnyitására tett kísérlet közben
root@fujitsu-fedora:~$ dumpe2fs /dev/sda2 | grep 'Filesystem created:'
dumpe2fs 1.47.0 (5-Feb-2023)
Filesystem created: Sat Sep 2 13:26:45 2023
root@fujitsu-fedora:~$ dumpe2fs /dev/sda3 | grep 'Filesystem created:'
dumpe2fs 1.47.0 (5-Feb-2023)
dumpe2fs: Hibás bűvös szám a szuperblokkban a(z) /dev/sda3 megnyitására tett kísérlet közben
root@fujitsu-fedora:~$

Ubuntu 22.04.1
Asztali gépemen hibernálásból az usb billentyűzet is felébreszti a gépet. (Neken nem kívánt funkció, hogy a macska is kapcsolgasson.) A biosban kikapcsoltam az APM alatti lehetőségeket (pci, lan ébresztés stb.)
Hogy lehet ettől megszabadulni?

Az udev-re van szükség. Egy udev szabályt kell létrehozni a billentyűzetre, amiben letiltod a wakeup-ot. Én most ebben nem tudok segíteni, de délután/estefelé majd megírom, én hogyan oldottam meg.

Asztali gépen először használok ded. Nvidia kártyát.
A lenti infókat tudom adni. Mi ez a sokféle driver és miért nem a legújabbat használja az Ubi?
(A driverek telepítéskor (után) automatikusan kerültek fel.)

user@P8B75-V-desktop:~$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  535.161.07  Sat Feb 17 22:55:48 UTC 2024
GCC version:  gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04) 

user@P8B75-V-desktop:~$ sudo ubuntu-drivers list --gpgpu
nvidia-driver-535, (kernel modules provided by linux-modules-nvidia-535-generic-hwe-22.04)
nvidia-driver-418-server, (kernel modules provided by nvidia-dkms-418-server)
nvidia-driver-550-server, (kernel modules provided by nvidia-dkms-550-server)
nvidia-driver-450-server, (kernel modules provided by nvidia-dkms-450-server)
nvidia-driver-470-server, (kernel modules provided by linux-modules-nvidia-470-server-generic-hwe-22.04)
nvidia-driver-470, (kernel modules provided by linux-modules-nvidia-470-generic-hwe-22.04)
nvidia-driver-390, (kernel modules provided by nvidia-dkms-390)
nvidia-driver-545, (kernel modules provided by linux-modules-nvidia-545-generic-hwe-22.04)
nvidia-driver-535-server, (kernel modules provided by linux-modules-nvidia-535-server-generic-hwe-22.04)

Szerintem jó, hogy több van, mert, ha valamelyikkel gond van, ott a másik.

Azért elavultak, mert a 22.04 lts csomagjai mind megöregedtek. Április végén jön a 24.04 friss csomagokkal.

Mert vannak a központi tárolókban lévő driverek, meg vannak a nvidia által szállított dkms driverek. Ez utóbbit akkor használja, ha a beállítások-további illesztőprogramok részen kiválasztod a zárt meghajtók használatát.

Okos mérnök a hülyeséggel is kalkulál. Avagy, a "Figyelj oda jobban" tábla nem munkavédelmi eszköz....

Jah, ezt eddig nem vettem észre, hogy lehet csereberélni a drivereket. Laptopon ez a rész mindig üres volt. (Additional driver)

Értem és köszönöm mindenkinek.

Szóval, az udev.
Linuxban az udev képez hidat a kernel és az eszközök között. Ez felel többek közt azért, hogy mi történjen, amikor egy eszközt csatlakoztatsz vagy leválasztasz. Az udev működését szabályokkal lehet testreszabni.
Általában minden disztró gyárilag tartalmaz több-kevesebb szabályt a /usr/lib/udev/rules.d/ könyvtárban, de mi nem ide fogunk dolgozni, hanem az /etc/udev/rules.d könyvtárba.
Nekem Logitech wireless egér+billentyűzet kombóm van (az egerét nem használom, csak a billentyűzetet), ezért ide létrehoztam egy 99-logitech.rules nevű fájlt. A fájlnév elején a szám a végrehajtási sorrendet jelzi, ha több fájl van ebben a mappában, a legkisebb számtól haladva a legnagyobbig hajtódnak végre a szabályok.

Az én fájlomban egyetlen sor van:

ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c534", ATTR{power/wakeup}="disabled", ATTR{driver/2-1.2:1.1/power/wakeup}="disabled"

Ez annyit jelent, hogy állítsd be a következő attribútumokat a megadott eszközre akkor, amikor az csatlakoztatásra kerül. Csatlakoztatás esemény minden bootnál lefut, meg nyilván akkor is, amikor csatlakoztatod az eszköz.

A SUBSYSTEM, a DRIVERS, az ATTRS{idVendor} és ATTRS{idProduct} attribútumok határozzák meg, hogy mely eszközre kell alkalmazni a szabályt. USB eszközök esetén az idVendort és az idProduct-ot le lehet kérdezni pl. az lsusb paranccsal:

[root@fujitsu-fedora ~]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 17ef:608d Lenovo Optical Mouse
[B]Bus 001 Device 004: ID 046d:c534 Logitech, Inc. Unifying Receiver[/B]
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Ott van a 046d:c534 osztályú eszköz, ez az én egér+billentyűzet kombóm(nak az adóvevője).
Vagy ha kiadod az udevadm monitor parancsot, és közben bedugod az eszközt, akkor is kiírja az eszközosztály azonosítóját (meg még egy csomó mindent is).

Azt, hogy a megadott eszközzel mi történjen, az ATTR{power/wakeup}="disabled", ATTR{driver/2-1.2:1.1/power/wakeup}="disabled" attribútumok adják meg. Figyeld meg, ez fontos, hogy a SUBSYSTEM, a DRIVERS és a többi attribútumnál kettő egyenlőségjel van, mert ezek kiválasztják az eszközt, míg ennél a két utolsó attribútumnál egy egyenlőségjel van, mert ezek pedig megváltoztatják az attribútum értékét.
A power/wakeup és a driver/2-1.2:1.1/power/wakeup értékét is disabledre állítottam, emiatt nem fogja felébreszteni a gépet alvó állapotból.

Elméletileg elég lenne csak simán a power/wakeup-ot disabledre állítani, de ez nem mindig működik, úgyhogy én
a 2-1.2:1.1 azonosítójú (udevadm monitor-tól lehet megtudni) USB port wakeup-ját is disabledre tettem, így teljesen jól működik.

Neked is egy ilyen szabályt kell csinálnod, átírni az idVendor és az idProduct azonosítókat, valamint az USB portod azonosítóját (gondolom, nem dugdosod át egyik portból a másikba a billentyűzetet), majd kiadni az udevadm control --reload parancsot, ez újratölti az udev szabályokat. Lényegében ennyi.

Ami még érdekes lehet, az hogy az udevadm info --attribute-walk paranccsal le lehet kérdezni az eszköz összes attribútumát. Pl. név alapján:
udevadm info --attribute-walk --name=/dev/input/event4

A /dev/input/event4 az én egerem azonosítója (lshw -C input parancstól lehet megtudni).

Elérési út alapján:

udevadm info --attribute-walk --path=udevadm info --attribute-walk --path=/devices/p/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1/0003:24AE:2015.0018/input/input94/mouse0

A path-ot az udevadm monitor parancstól lehet megtudni.

Az ArchWiki cikkét is érdemes megnézegetni.

[ Szerkesztve ]

Köszönöm az információkat, neki kezdek.

Előtte azért nézd át a BIOS USB beállításait is. pl.

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

A 24.04 még béta. Gyakorlatilag megéri feltenni? Azt tudom, hogy elvileg beta, nem ajánlott napi használatra. De a gyakorlatban is?

Analógiának a Debian Unstable ágát mondanám. Az sem ajánlott napi használatra, mert nem stabil. Közben a gyakorlat meg az, hogy vidáman lehet vele dolgozni!

Nem. A számmisztikán kívül mi indokolja a feltételét? Tipikus virtuális farokméret, hogy "nekem már az új béta rendszer fut a gépemen"
Pontosan milyen hiba javítása, vagy új funkció bevezetése hiányzik annyira?
Még a kiadott verziókkal is van n+1 probléma (a legviccesebb talán az, hogy a snap store nem képes frisíteni saját magát, mert fut )

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

"A számmisztikán kívül mi indokolja a feltételét?" - Hát figyelj oda. Home user vagyok. Nem mission critical rendszert futtatok. Persze! Semmi gond a 22.04 LTS-el sem (nekem legalábbis), csak tetszik az új-(don)-ság.

"Pontosan milyen hiba javítása, vagy új funkció bevezetése hiányzik annyira?" - Nincs racionális válaszom! " Az újabb, jobb" reményében futok neki az ilyennek. Csak tetszik.

Mert az otthoni felhasználót nem zavarják a kiakadó/el nem induló programok, amik adott esetben még adatvesztést is okoznak?
Nem állítom, hogy ez lesz, de nagyobb az esélye mint a stabil kiadásnak.
Te nem tudod egyedül eldönteni milyen kockázatokat vállalsz be vele, és ha nem tetszik a válasz, hát rajta, frissíts!

Az újabb jobb? Erről mindég az Így jártam anyátokkal epizódja jut eszembe.

[ Szerkesztve ]

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

Ez teljesen jó időszak arra, hogy bátran kipróbálj valami újat, feltéve ha van egy szabad SSD-d. Én ilyen tesztelési célra vettem egy 60GB-os SSD-t pár gombóc fagyi áráért.

Az első 1-2 hétben az eredeti szoftvereket használom, majd a fájlkezelőtől a PDF megjelenítőn keresztül a média lejátszókig szinte minden programból kipróbálok 1-2 újat. Ez a tesztelési időszak akkor igazán hatásos, ha ez lesz az elsődleges operációs rendszernek, és jól be van lakva.

Sokan megvárják a 24.04.1-es verziót, és nyár végén felteszik azt.

Köszi!

Az április 25. mennyire hivatalos megjelenési infó a 24.04-hez? Valahol szembejött, de most keresgélem a hivatalos weblapon, de ott nem találok erről semmit.

A Slime draws near! Command?

Á, megvan közben, itt írják: Ubuntu Noble Numbat Release Schedule

A Slime draws near! Command?

[link]

Sziasztok.
Ha felrakom az új 24.04-et az jár valami hátránnyal? Olyanra gondolok, hogy pl frissül e majd a végleges verzióra?
Kicsit tülrelmetlen vagyok és már kipróbálnám. Jó operációs rendszer ez egyébként? Eddig csak Linux Mintet használtam.
A release candidate verzió már megjelent belőle, és ha igen akkor honnan lehet letölteni?

[ Szerkesztve ]

https://sites.google.com/view/saviorweboldala/home

"Ha felrakom az új 24.04-et az jár valami hátránnyal?" - Nem ajánlott napi használatra! Igen frissülni fog!
"Jó operációs rendszer ez egyébként?" - Attól függ! Mennyire vagy járatos a témában?Mire használnád az Ubuntut? Mik az elvárásaid, preferenciád a rendszerrel szemben?

A gnome felülete neked kézrefekvő?

Böngészés, Discord, játékfejlesztés (Unity 3d nevű programmal, Blender, Krita), néha egy kis játék(most pl Torchlight Infinite, Albion online). Ezeke nagyjából.

https://sites.google.com/view/saviorweboldala/home

Ezek a programok és játékok futni fognak!

Április 25. az jövő hét csütörtök. Akkor fog megjelenni a végleges verzió.
Megéri megvárni.
Az már nem sok idő, addig nézegess Ubuntu 24.04 témájú YouTube videókat. Legtöbb kérdésre megkapod a választ. Azokra is, amit fel se tettél.

Köszi mindkettőtöknek a válaszokat.

https://sites.google.com/view/saviorweboldala/home

(22.04LTS desktop)
Van egy zavaró hiba a terminal ablakban. Amikor megnyitok egy új terminal ablakot, akkor villámgyorsan reagál a billentyű leütésre, az autocomplete is gyors. Egyidő után olyan laggolóssá válik az egész. Nem csak az autocomplete, hanem a billentyű leütések is.
Már-már zavaróan késik. ('90-es évek bbs korszaka érzés)

Hallott ilyenről valaki?

Hétvégén próbaképp én is frissítettem a 24.04 LTS bétára (vagymi a neve) és telepítés után nem adott képet a laptop a külső monitorra. Próbáltam driver cseréket, egyik sem segített. Volt tegnap valami frissítés, azóta újra jó.

A Slime draws near! Command?

A többieket segítené, ha driver/GPU nevet is tennél hozzá.

Én akkor a szuperbátrak közé tartozom, daily image-t raktam fel még 1+ hónappal ezelőtt.

Tegnap még működött...

(22.0.4 lts desktop)
GTX 970 wayland módban nem tud visszatérni suspend vagy hibernált állapotból. Teljesen széthullott a kép. Kiváncsi leszek az új LTS tudja-e ezt orvosolni.