#18 Örülök. Sok sikert a továbbiakban!

Szia Kimarite!

Úgy tűnik, hogy a tesztelés során sikerült mindent megvalósítani. Az a wine változat amit ajánlottál jül műxik. A winbind telepítés szükségességét most vettem csak észre. Szóval így teljesen jó minden, futnak az egyfile-os *.exe programok is.

Köszönöm a segítséget!

#19.1.1 Megnézted, hogy pontosan mit ír ki? Segítene.

#19.1.1.1 Előfordulhat, hogy a Windows partíciót is nézi, ha az ntfs-3g csomag telepítve van: „Esetleg még arra tudok gondolni, hogy az SSD win10 partíciója nagyon megtelt és ez okozhat problémát, bár ezt magam sem értem, hogy tehetné.” De részemről ez csak egy tipp most.

Ha a Windows alatt megpróbálsz fájlrendszert javítani?

#19.1.1

Sajnos a windows szabályos leállításával is garantált a hibajelenség.

#19.1

Köszönöm! Szuper! Öröm van! :-)

Dualbootom van. Azt vettem észre ha Tara után reboottal win-t indítok, majd újabb reboottal Tara-t, akkor csinálja. Valószínűnek tartom, hogy Tara nem szereti ha reboot után más valaki következik. Ezt majd még tesztelem, de előbb csinálok egy EFI boot pendrive-ot, mert a DVD-ről való betöltést nem lehet kivárni (ha tesztelgetni akar az ember).

Esetleg még arra tudok gondolni, hogy az SSD win10 partíciója nagyon megtelt és ez okozhat problémát, bár ezt magam sem értem, hogy tehetné.

Más típusú hibát jelez, mint amit belinkeltél, az ellenőrző összegekkel van valami baja, de legközelebb hibajavításkor pontosabban megnézem majd mit ír ki.

#19.1.1.1.1.1 Mutatnál egy ilyen kimenetet?

df -h ; df -i

#19.1.1.1.1

Azt tudtam eddig kipróbálni, hogy Tara-t leállítással kapcsoltam ki (sda5 partíción van), majd Win10 elindítása és normál kikapcsolása következett (sda4) (sda1 basic data, sda2 EFI, sda3 Microsoft reserved). Majd amikor újra bekapcsoltam a gépet sajnos megint nem Tara fogadott.

Javítás boot pendrive fsck -y /dev/sda5

Win alól nem próbáltam meg javítani, ez eddig eszembe sem jutott, mivel a win partíciónak semmi baja. Gondolod érdemes lenne? Ha igen mivel?

----------

Ismételt próba után: nagyon hosszú a bejegyzés. Nem másolnám be ide csak az elejét és a végét.

mint@mint:~$ sudo fsck -y #19.1.1.1.1 /dev/sda5
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Superblock checksum does not match superblock
fsck.ext4: Superblock invalid, trying backup blocks...
/dev/sda5 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23497, counted=15338).
Fix? yesitt nagyon sok blokkot javít, majd a végén ez következik:

itt nagyon sok blokkot javít, majd a végén ez következik:

Inode bitmap differences: Group 0 inode bitmap does not match checksum.
FIXED.
Block bitmap differences: Group 0 block bitmap does not match checksum.
FIXED.

/dev/sda5: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda5: 900248/8224768 files (0.2% non-contiguous), 19862675/32882769 blocks

Ha esetleg a köztük lévő sorok is érdekesek lehetnek, légyszives írd meg, hogy hová küldjem el a file-t amibe kimásoltam a teljes szöveget, ide nem tenném fel mert direktben bemásolva hosszú.

#21.1.1.1.1 Korábban kérdezted, hogyan ossz meg hosszú szövegeket. A https://paste.ubuntu.com/ segítségével, a megosztás módját több helyen leírtuk.
Az a dolog kéne, amit említesz, hogy kiír a gép. És eddig nem láttuk.

 

#21.1.1.1

Természetesen nem lett teljesen felhasználva, volt még néhány GB szabad. De 24 GB szabad hellyel ne tudna működni? Ez teljesen ellentétes az eddigi tapasztalataimmal. Amíg a másik partíción Sylvia "lakott" ennél jóval kevesebb szabad hely sem okozott problémát az "ablakos"-nak. Azt szerintem kár latolgatni, hogy mi van ha jön rá nagyobb frissítés, azt megoldom, ahogy eddig is, itt most az a problémám hogy a két rendszer együttélésével komoly gondok vannak.

A 74 GB az 74 GB. Természetesen ki lehet tenni külső tárolóra, de semmi nem indokolja. Amit írtál az azt jelenti, hogy Linux partíción nem szabad nagyobb mennyiségű adatot tárolni? Az nagyon gáz lenne, az a Linux Mint, de egyben az Ubuntu végét is jelentené. És ennek még mindig ellent mond az, hogy Sylvia jól működött ezzel a tárolt adatmennyiséggel is, hiszen azt mentettem át Tara-ba. Itt valami bug van, csak azt nem tudom még, hogy mi.

Ha lesz egy kis időm rá, vissza rakom lemezképből Sylviát, lefrissítem a GRUB-ot, és ki fog derülni hogy ki a hunyó. A nagyobb bajom, hogy a megoldáshoz nem leszek azzal sem sokkal közelebb, max. használható lesz a dualbootos rendszerem.

#19.1.1.1.1.1 Erre lennék kíváncsi:
„Más típusú hibát jelez, mint amit belinkeltél, az ellenőrző összegekkel van valami baja, de legközelebb hibajavításkor pontosabban megnézem majd mit ír ki.”
Egyszer már említettem, a válaszod a „Show responses” szöveg „mögött” van, a korábbi válszom nem részltezném újra. Jó lenne ezt megjegyezni és nem megkérdezni újra és újra. Blogot is írtam erről.

Írod, megoldódott:
„Hirtelen beparáztam, de egy Live CD és egy fsck megoldott mindent. Ez még a rendszer friss voltának tudható be vajon? Igazából semmi olyat nem csináltam ami miatt ennek kellett volna történnie -szerintem.”
Most igen, vagy nem? Ha nem, mi a jelenség?

#19.1.1.1.1

Azt tudtam eddig kipróbálni, hogy Tara-t leállítással kapcsoltam ki (sda5 partíción van), majd Win10 elindítása és normál kikapcsolása következett (sda4) (sda1 basic data, sda2 EFI, sda3 Microsoft reserved). Majd amikor újra bekapcsoltam a gépet sajnos megint nem Tara fogadott.

Javítás boot pendrive fsck -y /dev/sda5

Win alól nem próbáltam meg javítani, ez eddig eszembe sem jutott, mivel a win partíciónak semmi baja. Gondolod érdemes lenne? Ha igen mivel?

----------

Ismételt próba után: nagyon hosszú a bejegyzés. Nem másolnám be ide csak az elejét és a végét.

mint@mint:~$ sudo fsck -y #19.1.1.1.1 /dev/sda5
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Superblock checksum does not match superblock
fsck.ext4: Superblock invalid, trying backup blocks...
/dev/sda5 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23497, counted=15338).
Fix? yesitt nagyon sok blokkot javít, majd a végén ez következik:

itt nagyon sok blokkot javít, majd a végén ez következik:

Inode bitmap differences: Group 0 inode bitmap does not match checksum.
FIXED.
Block bitmap differences: Group 0 block bitmap does not match checksum.
FIXED.

/dev/sda5: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda5: 900248/8224768 files (0.2% non-contiguous), 19862675/32882769 blocks

Ha esetleg a köztük lévő sorok is érdekesek lehetnek, légyszives írd meg, hogy hová küldjem el a file-t amibe kimásoltam a teljes szöveget, ide nem tenném fel mert direktben bemásolva hosszú.

#19.1.1 „Más típusú hibát jelez, mint amit belinkeltél, az ellenőrző összegekkel van valami baja, de legközelebb hibajavításkor pontosabban megnézem majd mit ír ki.”

-- de mit ír ki a boot-kor? ;) :)

-----

A trimmelésről:
(forrás: közösségi csoport)

SSD felhasználók, ön hogy szokott trimmelni?

... az /etc/fstab-ban megadott discard-ot (ami egy folyamatos trim, ha jól értettem minden file törlés után) nem annyira szokták ajánlani.

Olvasnivaló:
https://en.wikipedia.org/wiki/Trim_(computing)
http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-o...
https://wiki.archlinux.org/index.php/Solid_State_Drive#Periodic_TRIM

systemd esetén az fstrim.timer-rel lehet időnként (alapból hetente) trimmeltetni.

- lekérdezés:

systemctl is-enabled fstrim.timer

- beállítás

sudo systemctl enable --now fstrim.timer

- log nézegetés:

journalctl -u fstrim.timer

Párbeszéd_01:

-- Legjobb tudomásom szerint a modern ssdkben nincs szükség szoftveres trimre. Hardverből oldják meg ezt.

-- De ha az OS nem mondja meg neki, hogy milyen területek szabadulnak fel egy törlés során, honnan fogja tudni szerencsétlen SSD? Pont erre való a trim.
Vagy ismernek minden filerendszer allokációs táblát?
Lszi olvassd el a write amplification részt.

Párbeszéd_02:

-- Sziasztok! Én is így oldottam meg a saját rendszereimen a dolgot, a trim timert használva heti rendszerességgel beállítva. Viszont az lenne a kérdésem, hogy fstabban az ssd-n lévő csatolási pontok csatolási paraméterei közé melyik paramétert javasoljátok inkább: a noatime-ot vagy a relatime-ot, vagy esetleg egyiket sem szükséges megadni fstabban ha az fstrim.timer be van állítva? Ha valaki tudna segíteni ebben a dilemmában, hálás lennék érte. Köszönöm szépen előre is a válaszokat/segítségeteket.

-- Engem nem igazan erdekel, hogy mikor lettek a file-ok utoljara beolvasva. Ezert a noatime javasolt. A relatime max naponta frissitgeti, ha jol ertettem (ld. pl. https://blog.confirm.ch/mount-options-atime-vs-relatime/), de nekem az is felesleges. Szoval noatime.
És magát az ssd élettartamát, illetve teljesítményét befolyásolja bármelyik opció is? Vagy ilyen szempontból mindegy melyiket használja az ember?

-- Ha nem állítod be a noatime-ot, akkor minden egyes file olvasás esetén lesz egy írás is az SSD-re: felírja az access time-ot, azaz a hozzáférési időt, ami valószínüleg egyáltalán nem érdekel téged, tehát felesleges írás, potencionálisan rövidítheti az SSD élettartamát. Tehát ha inkább állítsd be a noatime-ot.

-- És azt még megkérdezhetem, hogy ha a noatime helyett a relatimeot választom, akkor is megrövidítem az ssd élettartamát? Vagy az sem végez írási műveletet az SSD-re? Ne haragudj ha sok a kérdés, csak szeretnék képben lenni ezzel a dologgal, mert eddig még sosem foglalkoztam vele, nem tudtam hogy érdemes.

Párbeszéd_03:

-- Nem foglalkozom vele. Intel enterspájz SSD-ket használok, hamarabb kellett nagyobbra cserélni, mint baja lett volna.

-- De ahogy nézem, ez a trim nem az elromlásról, hanem az írási teljesítményről szól.

:::::

Mindenesetre a linkek jól jönnek. :)

#19.1

Köszönöm! Szuper! Öröm van! :-)

Dualbootom van. Azt vettem észre ha Tara után reboottal win-t indítok, majd újabb reboottal Tara-t, akkor csinálja. Valószínűnek tartom, hogy Tara nem szereti ha reboot után más valaki következik. Ezt majd még tesztelem, de előbb csinálok egy EFI boot pendrive-ot, mert a DVD-ről való betöltést nem lehet kivárni (ha tesztelgetni akar az ember).

Esetleg még arra tudok gondolni, hogy az SSD win10 partíciója nagyon megtelt és ez okozhat problémát, bár ezt magam sem értem, hogy tehetné.

Más típusú hibát jelez, mint amit belinkeltél, az ellenőrző összegekkel van valami baja, de legközelebb hibajavításkor pontosabban megnézem majd mit ír ki.

#21.1.1.1.1.1.2 „Ha nem muszály szándékosan nem szivatnám megamat hogy újra előidézzem.”
Ha nem zavar, hogy kihúzok belőled minden szót, akkor mondhatjuk-e, hogy jó már a gép, hiszen a boot-hiba nem jön elő ismét? Van-e más probléma vagy kérdés?

#21.1.1.1.1.1

Ezt most miért mondod? Júl 9-én 21:41-kor írtam:

"BusyBox V X.X.X (Ubuntu XXXXX ubuntuX) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs):"

Gondolom, amit ki "X"-eltem nincs különösebb jelentősége. De megjegyezni nem jegyeztem meg, és fotót sem készítettem róla, de a szöveg a fenti volt. Ha nem muszály szándékosan nem szivatnám megamat hogy újra előidézzem.

#26.1.1 Hát én nem tudom, a Windows, mennyire tenné be magát az fstab-ba, de nincs ott. A Linux sem.

A Windows rendszer betöltőjét használod, és nem a GRUB-ot (a Linux rendszer betöltőjét)?

Az fstab-od:

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda5 during installation
UUID=e59363b1-6a67-4f18-9186-94db5effd108 /               ext4    discard,noatime,errors=remount-ro 0       1
# /boot/efi was on /dev/sda2 during installation
UUID=722A-AAE9  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0

Az fdisk parancs kimenetét mutató URL végé van pár fura és felesleges karakter. Az URL helyesen: https://paste.ubuntu.com/p/GxZCzCyfwP/

#26.1

Parancsolj:

https://paste.ubuntu.com/p/52MwyRXwDv/

https://paste.ubuntu.com/p/GxZCzCyfwP/   (az sdb egy pendrive, ami épp egy másolás miatt épp be volt dugva)

Azért nincs swap partícióm, mert azt olvastam anno, hogy nincs rá szükség, swap file-t használ a 18.04 Ububntu.

Nem tudom, hogy a fenti infók miben tudnak segíteni, mert a linuxot akár leállítást követően, akár újraindítással indítom mindig tökéletesen elindul. De ha a Win10-et használom és azután akarok linuxot indítani, akkor minden esetben szívás van vele. Ez a 18.03-nál még extrém lemezfoglaltság (minimális, néhány GB-os SSD szabad hely) esetén sem fordult elő.

#27 Szerintem várd meg, amig Windows-t is használó fórumtársaink valamelyike feltűnik és tanácsot ad ebben. Nem használok jó ideje Windows-t, elég fáradt vagyok, ma nem tudok rákeresni a megoldásra (és nem tudom, jó lenne, amit mondanék). Különben nagyon nem zavarja ez a Linux használatát, azaz „ráér”.

A Grubot használom (UEFI). Mindig a linuxot telepítem utoljára és ő megcsinálja magának, nem kell vele külön szöszölni. Lila gőzöm sincs mit lehetne tenni. Esetleg a rendszerbetöltőbe egy fsck -y parancsot be lehetne szúrni valahová?