A céllemezre nem kell partíció. Sőt üres hely kell ahhoz hogy pésztelni tudja a kopizott partíciót.
Csak arra figyelj, hogy gparted copy&paste esetén megmarad a partíció uuid-je. Vagyis, a forrást töröld, mielőtt bebootolod a gépet.

Never let your sense of morals prevent you from doing what's right.

No, folyamatban.

Köszi, fontos infó.

(#30551) Syl
A céllemezre nem kell partíció. Sőt üres hely kell ahhoz hogy pésztelni tudja a kopizott partíciót.
Csak arra figyelj, hogy gparted copy&paste esetén megmarad a partíció uuid-je. Vagyis, a forrást töröld, mielőtt bebootolod a gépet.

Biztosan úgy van akkor, ahogyan Syl írta, de én múlt heti élő történetet írtam le, nekem kellett partíció, mert úgy vágtam le másikból, de ha nem csinálsz, ne csinálj, ugyanúgy átmásolja egy üres helyre is. Így akkor majd utólag igazítgatod a partíciót, tök mindegy.

Csak arra figyelj, hogy gparted copy&paste esetén megmarad a partíció uuid-je.

Ugyanaz marad, nem lehet más, de ellenőrizd persze. Nálam itt még látszik az eredeti sda5-ös bejegyzés és a célhely, a sdb9-es, egyértelműen ugyanaz.
A swap uuid-ját viszont valóban érdemes ellenőrizni, különben 1,5 perc várakozás lesz a boot-nál.

Vagyis, a forrást töröld, mielőtt bebootolod a gépet.

Ezt semmiképpen nem javasolnám, én se tettem, mert előtte le akartam ellenőrizni, hogy tökéletesen fut-e az átmásolt rendszer és csak miután lecsekkoltam, akkor töröltem. Most is erről írok.

Gondolod, hogy csak úgy leírom neked, miket csinálj, anélkül, hogy nem csináltam végig ugyanezt? Ezt csak azért írtam most, nehogy azt hidd, hogy megvezettelek, ahogy Syl fórumtárs ilyen esetekben írja rólam.

Ha az ő instrukciói szerint csinálod, akkor én már nem is kavarok bele.

Nemrég másoltam át a / és a /home-ot ssd-ről hdd-re és utána beindítottam a gépet hdd-ről. A rendszer hdd-ről indult el, de /home-ot már az ssd-ről csatolta fel. Ezért írtam, hogy nem szerencsés ha ugyanazzal az uuid-vel van több partíció a rendszerben.

szerk.
Mondjuk ha nem is törli, legalább új uuid-t generáljon neki a gparteddel.

[ Szerkesztve ]

Never let your sense of morals prevent you from doing what's right.

OK! Mondtam, hogy biztosan úgy is jó, de kétféleképpen ne navigáljuk tomtyi ft-t, mivel az általad javasoltak alapján kezdte, logikus, hogy én nem vauzok bele, csak meg akartam nyugtatni, hogy nem megvezetés lett ez is.

Igy már az se fog kiderülni, mi történik, ha két ugyanazon uuid-es partíció van a bootoló rendszeren.

Egyébként se jó, ha bárki az én favágó módszereimet követi, ha van hozzáértőbb hsz is a témában.

Mondjuk ha nem is törli, legalább új uuid-t generáljon neki a gparteddel.

Ez OK, de akkor viszont írd le a további szükséges lépéseket is.

[ Szerkesztve ]

Mire gondolsz? Hogy javítsa ki az fstba-ban?
Csak mert ha jól értettem az eredeti kérdést, akkor ő a partíciót egyik lemezről a másikra akarja költöztetni. Vagyis a forrás megszűnik, ergo az fsbat-hoz nem kell hozzányúlni.
De természetesen lehet hogy tévedek

Never let your sense of morals prevent you from doing what's right.

Köszi mindkettőtöknek. Gparteddel átmásoltam, az UUID-t is ezzel változtattam meg, Grubot is újraraktam, rendszer működik. De rohadt lassan áll fel, lassabban, mint a HDD-ről korábban. Bár a programok gyorsan indulnak. Kivéve a Firefox.

A /var-t át tudom úgy rakni a HDD-re, hogy az fstab-ba az

UUID=xxx /var ext4 noatime 0 2
(xx értelemszerűen a HDD ennek megfelelő partíciója)?

Amennyiben a /var könyvtár SSD-re kerül, érdemes lehet bizonyos alkönyvtárait a RAM-ba irányítani tmpfssel, ehhez adjuk az /etc/fstab fájlhoz az alábbi sorokat:

tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
tmpfs /var/spool tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0

Erre gondolt kollégánk az imént. Ne rakd HDD-re szerintem sem. Gondolom az SSD-s írásokat azért olvastad. Swap hol van?

a systemd-analyze blame parancs kimenete jó lenne a boot miatt. A blame nélküli is.

[ Szerkesztve ]

Köszi, ezt néztem.

Beírtam az fstabba azt a sort, aztán a reboot után low graphics reklamáció után újra és újra próbálta felcsatolni a /-ot, de nem tudta. Így ezt a sort töröltem az fstabból.

(#30561) ubyegon2
Jogos.

Swap az SSD-n.

[ Szerkesztve ]

systemd-analyze blame

discard legyen inkább vagy fstrim? Most az fstabba a discardot írtam. Vagy ez az egész az /etc/cron.weekly-ben gyárilag lévő fstrim szkript miatt felesleges?

A NetworkManager-wait-online-t kapásból kilőheted ha semmi nem indul boot-kor aminek kell az internet.

Vagy kell az apache-nak?

[ Szerkesztve ]

You may corrupt the souls of men, but I am steel. I am doom.

Nem kell, nincs apache (vagyis nyilván van, de valamelyik progi függősége, gondolom, ráér később).
Hogy lőhetem ki?

[ Szerkesztve ]

systemctl stop szerviznev -> (daemon, szerver) leállítása
systemctl disable szerviznev -> -||- letiltása (automatikus indítás kikapcsolása)

pl. ebben az esetben:
systemctl disable NetworkManager-wait-online

[ Szerkesztve ]

You may corrupt the souls of men, but I am steel. I am doom.

Ez felhasználás kérdése, ha sokat törölgetsz a meghajtóról (főleg kis fájlokat), akkor praktikusabb az fstrim, egy átlagos rendszer meghajtónál, amiről alig törölsz, mehet a discard.
Mint az már volt téma, bizonyos meghajtóknál a discard problémás (Samsung főleg), erre érdemes figyelni.

Köszi.
Megnéztem az apache-ot, már nem volt semminek a függősége, töröltem.

A NetworkManager-wait-online.service úgy nézem, a hálózathoz való automatikus csatlakozást csinálja. Ez azért nem baj, ha van.

(#30567) berus.berus
Köszi. Nekem éppen Samu 850 Evo lett.
Az „érdemes odafigyelni” mit takar? Hogy tudok rá odafigyelni? És főleg mire?

[ Szerkesztve ]

Úgy, hogy nem használod a discard opciót az fstabban!
A Samu eldöntötte helyetted, hogy fstrimmet akarsz használni...

OK, köszi.
Akkor az SSD-s logout-os bejegyzésednél a

UUID=12314263-4578-4990-95b7-50067d4a906d / ext4 discard,noatime,errors=remount-ro 0 1

nálam erre módosul?

UUID=12314263-4578-4990-95b7-50067d4a906d / ext4 noatime,errors=remount-ro 0 1

Szerk.:
vagy inkább

defaults,noatime,errors=remount-ro 0 1

legyen?

És akkor életbe lép az /etc/cron.weekly/fstrim lefutása?

[ Szerkesztve ]

Igen!

"A NetworkManager-wait-online.service úgy nézem, a hálózathoz való automatikus csatlakozást csinálja. Ez azért nem baj, ha van."

Nem, a networkmanager service azt megcsinálja. Ez azt csinálja, hogy addig nem engedi tovább a boot-ot amíg nem jött létre az internet kapcsolat mert vannak olyan service-ek amiknek kell.

You may corrupt the souls of men, but I am steel. I am doom.

A cron feladatoknak nincs köze az fstabhoz, lefutnak amikor kell...

OK.

(#30573) berus.berus
Jelen esetben azért van összefüggés, hiszen a cron fájl tartalma ez:

#!/bin/sh
# trim all mounted file systems which support it
/sbin/fstrim --all || true

Azaz alapértelmezetten hetente minden vonatkozó eszközön lefuttatja az fstrimet függetlenül attól, mi van írva az fstabba. Azaz alapból feleslegessé teszi az fstabba való beleírást. Vagy rosszul látom?

[ Szerkesztve ]

Jól látod, de a cronnak akkor sincs semmi köze az fstabhoz... Az fstrim nem vizsgálja, hogy milyen opciókkal van csatolva a fájlrendszer, a két dolognak csak a felhasználó szemszögéből van összefüggése.
A discard egy csatolási opció, az fstrim pedig egy parancs, ami ott is használható, ahol a discard nem értelmezett (NTFS-3g).

[ Szerkesztve ]

Normál esetben jól elvan egymás mellett az azonnali és az ütemezett TRIM. Nálad, ahogy berus.berus szaki mondta, az azonnalit(discard) nem célszerű használni, az ütemezett(fstrim) meg mindenképpen lefut hetente.

Fstabban elég a noatime, de a default is mehet, discard ne legyen.

a networkmanager-wait-online.service-t mindenképp lődd ki, nálam is időnként megjelent és nagyon idegesítő volt, amikor 3,5 percre volt állítva.

Nézd meg a függőségét, ha nem akarja a BoB által írt parancs kikapcsolni, mert a függőség nem engedi:

systemctl list-dependencies --reverse NetworkManager-wait-online

a satust ezzel a paranccsal tudod ellenőrizni:

systemctl status networkmanager-wait-online.service

ha ilyen a kimenet, akkor OK:

~ $ systemctl status networkmanager-wait-online.service
● networkmanager-wait-online.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)

Ha minden OK, akkor igen gyors lesz a boot-idő, valami ilyesmi:
Startup finished in 4.592s (kernel) + 1.744s (userspace) = 6.336s

Ha elég fizikai memóriád van, akár a FF cache-t is kiküldheted abba, gyorsabb lesz és nem használja az SSD-t sem.

ha Firefoxot használunk, viszont nincs kedvünk RAMDISK-kel bajlódni, irányíthatjuk a gyorsítótárat közvetlenül a memóriába is, méghozzá egyszerűen. Nyissuk meg megint a beállításokat tartalmazó lapot: írjuk be a böngésző címsorába az about:config parancsot.

Keressük ki a browser.cache.disk.enable kulcsot, majd értékét true-ról állítsuk át false-ra. Ezután keressük meg a browser.cache.memory.enable kulcsot, majd értékét állítsuk át false-ról, true-ra. Most már a memóriába kerül a Firefox gyorsítótár, de nem árt megszabni, hogy mekkora memória mennyiséget foglaljon le magának a webböngésző. Hozzunk létre egy új Integer (Egész) kulcsot (Jobb egérgomb -> Új menüpont), majd adjuk neki a browser.cache.memory.capacity nevet. A friss beállítás értékeként adjuk meg kilobájtban, hogy mennyi rendszermemóriával gazdálkodjon a memóriába száműzött gyorsítótár. Itt persze -1 is lehet az érték, ha a Firefox-ra szeretnénk bízni a beállítást. Utóbbi esetben a rendelkezésre álló rendszermemória mennyiségétől függően dinamikusan állítja be a webböngésző a memóriában helyet foglaló gyorsítótár méretét.

Az új beállítások a Firefox újraindítása után lépnek életbe.

[ Szerkesztve ]

+(#30576) ubyegon2
Köszi.
Menet közben találtam egy olyan megoldást, ahol nem kilövi ezt, hanem maszkolja.

Sajna, csak 4 GB a RAM, de a következő lépés ez lesz.

Jut eszembe, Apparmort még mindig csak én használok?

[ Szerkesztve ]

Én is kérdeznék

run-parts -v /etc/cron.weekly
parancsra ezt dobja:
run-parts: executing /etc/cron.weekly/fstrim
fstrim: /home: FITRIM ioctl failed: A művelet nem engedélyezett
fstrim: /mnt/vbox: FITRIM ioctl failed: A művelet nem engedélyezett
fstrim: /: FITRIM ioctl failed: A művelet nem engedélyezett

Ez most mit jelent?
Nem fut le a heti fstrim?

Never let your sense of morals prevent you from doing what's right.

Szerintem sudo-val próbáld a parancsot.

(#30577) tomtyi

A mask is jó, csak nem akartalak még jobban megkavarni, én is azzal próbálkoztam, mikor nem tudtam kilőni a services-t, de egyszerűbb volt aztán kivenni a függőség gazdáját, ami a glances.service ill. a glances volt.

[ Szerkesztve ]

Igen, jó volt a tippem elsőre! A sudo hiányzott.

Már nem emlékszem pontosan, miért vettem ki a SSD-s leírásból ennél a parancsnál a sudo-t, de anno külön kérés volt. Lehet, hogy vissza is írom most.

köztes megoldás:

[ Szerkesztve ]

>Szerintem sudo-val próbáld a parancsot.

Never let your sense of morals prevent you from doing what's right.

Üdv Urak,

Ha újabb kernelt szeretnék feltenni (frissíteni 4.8-ról 4.11-re) akkor csak az az opció van, hogy letöltöm mind a 3 és dpkg -i *.deb paranccsal feltelepítem, vagy van más egyszerűbb módja is?

linux-headers-4.11.0-041100_4.11.0-041100.201705041534_all.deb
linux-headers-4.11.0-041100-generic_4.11.0-041100.201705041534_amd64.deb
linux-image-4.11.0-041100-generic_4.11.0-041100.201705041534_amd64.deb

Üdv. !
Ha gyakrabban akarsz új kernelt telepíteni, (és a régiek közül eltávolítani)
akkor telepítsd az "Ukuu"-t (Ubuntu kernel update utility)

Sziasztok!

A MantisBT telepítéséről találtam ezt a leírást. Hátha hasznos lehet valakinek.

Mantis Bug Tracker Wikipédia

Boot grafikusan
Systemd-analyze

Lát valaki valamit?
A systemd-analyze kimenete ennyi:
Startup finished in 10.865s (kernel) + 3min 586ms (userspace) = 3min 11.451s
Utóbbi inkább 1:50 környéki.

Nincs valami kevésbé monumentális? Sima systemd-analyze blame vagy az volt már?

Ubuntu MATE 20.04, hobbi cayenne termesztő

Üdv,
AMD mostanában mennyire veszi komolyan a driver fejlesztés? Tudom hogy csak nyílt van.
Azt mennyire támogatja?
Év vége körül akarok összerakni egy gépet. AMD apu-val gondoltam. (új Ryzen alapon, addigra megjelenik, ha minden igaz)

A nyíltat nagyrészt már az AMD fejleszti, emellett a Valve is beszállt. Elég jó teljesítményt produkál mostanság. Kérdezd meg az év végén, de szerintem addigra ezen új cuccok támogatása is rendben lesz.

Ubuntu MATE 20.04, hobbi cayenne termesztő

Volt.

Userspace lassúságot ír. Ott hogy a fenébe lehetne kideríteni, mi a hiba?

A NetworkManager-est végül kiiktattad?

Ubuntu MATE 20.04, hobbi cayenne termesztő

Igen, maszkoltam.

Lehet hogy a jelenlegi Ubuntuban csak nylt van, de amúgy az AMD készít zártat is (ami a nyíltra épül rá).

You may corrupt the souls of men, but I am steel. I am doom.

Egy jó tanács mindenkinek: nem legyetek hülyék, mint én! A Gparted-es HDD>SSD partíciómásolás, UUID újítás után a swap partíció UUID-jét nem írtam át, ezért a boot során nem csatolta fel, emiatt volt dög lassú. Így azért már jóval gyorsabb.
Köszi mindenkinek a hülyeségem miatt elpazarolt idejét és őszített hajszálait.

Ugye most csak viccelsz!

A kép feletti mondatban pontosan leírtam, hogy erre figyelj oda! Emiatt nem volt tippem, hogyan lehet még mindig lassú, mert azt hittem ilyenkor végigmész minden leírt mondaton!

Az én jó tanácsom mindenkinek! Olvassátok figyelmesen a segítő hsz-eket!

Úh, bakker! Ez lehet, kimaradt, mert a hsz elején Syl-t írtad, én meg lehet, azt hittem, neki válaszoltál. No, sebaj. Lényeg, hogy megoldódott. Így viszont duplán köszi.

(#30598) BoB
9,5 éve kezdtem linuxozni, de az utóbbi években nagyon ellustultam, mert minden működik, ahogy kell, és bevallom őszintén, élvezem, hogy nem kell mókolni.