UHU Linux UBK1 (RIA)

 ( peritus | 2016. október 31., hétfő - 19:30 )

Sziasztok!

Elkészült, ill. reményeink szerint használható állapotba került :) az
UHU Linux UBK1 (RIA) kiadása.
Az iso-k letölthetők innen:

http://download.ubk.hu/iso/UBK1/

A kiadás a hivatalos UHU Linux-ra épül de attól teljesen független,
az eredeti UHU Linux csomagtárolókból semmit nem használ.
Észrevételeket ide lehet címezni:

http://ubk.hu/forum/

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

up

Kicsit többet megtudhatunk róla?

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

Hányan fejlesztitek?
Mik a főbb rendszerkomponensek és programok verziószámai?
Melyik debian verzióval vagy származékkal várható a legjobb kompatibilitás? (Ugye csomagformátum ugyanaz, de gondolom a csomagok nem az ubuntu vagy debian tárolóiból vannak újraforgatva.) A csomagok elnevezései, függőségei valamilyen másik rendszerrel összegyezthetőek?

Én kipróbáltam:
virtualbox alatt nekem kernel panic-ot dob boot során.
(Uncompression error)

Ugyanez az imidzs (cinnamon) usb-re kiírva simán bebootol.
Kicsit játszogattam vele, nem találtam benne semmi különöset: Minden működik, témák gyáriak, pár extra program előre telepítve.

Én örülök hogy van pár lelkes csomagoló akik foglalkoznak a rendszerrel. És nagyon szivesen használnám is, már csak meg kellene győzni :)

szerk.: 64 bites verzió nincs?

Most még csak hárman csináltuk, de reméljük, hogy szaporodunk és a régi uhu külsős csomagolókból még fognak csatlakozni.
Teljesen független az uhulinux tárolóitól, le van szakadva róla.
Teljesen önálló, de UHU alapokon nyugszik. Csomagformátuma szintén deb, mivel a dpkg -t használja, csomagjai ubk.uhu kiterjesztésűek. Függőségi szinten egyáltalán nem kompatibilisek a debian származékok egyikével sem, mivel nem debian származék, tehát azokra nem telepíthetők, és a RIA rendszerre a régi uhu csomagok sem telepíthetők.
Extrákat nem építettünk bele, minden csomagja forrásokból lett teljesen újraépítve az uhubuild rendszerrel.

A dektop környezetei, mint mate, cinnamon, lxqt, plasma, lxde, xfce4 naprakészek, kivéve a gnome -t, mely 3.20 -as.
Kernel 4.4.28 32 bites és 64 bites. A csomagok 32 bitesek.
Minimális RAM igény 1 Gigabájt, de 2 az ajánlatos.

korrekt, köszi!

Szia!

Ezen a címen az összes csomag verziószámát megnézheted ami érdekel:

http://download.ubk.hu/pkg/UBK1/main/

Van ott néhány ezer csomag. :)

A Gnome verzió 1Gb RAM-mal kernel pánikot produkál Virtualbox-ban.
(További teszt később.)
--
♙♘♗♖♕♔

Nem csoda a pánik, hisz a gnome azért terjedelmes, könnyen lehet, hogy az 1 Giga memória kevés neki, főleg vboxban.
Írd ki pendrájvra az isót és bootolj arról!

azért arra, hogy a gnomenak kevés a memóriából hogy lesz kernel pánik (ami ráadásul nem is csoda) kíváncsi volnék :)

Próbáld ki.

ne haragudj, de próbálja ki a nehézség :)

"azért arra, hogy a gnomenak kevés a memóriából hogy lesz kernel pánik (ami ráadásul nem is csoda) kíváncsi volnék :)"
Így.
--
♙♘♗♖♕♔

hát, ez elég ... érdekes.

Bocs, de ezt a választ nehezen tudom értelmezni. Én kipróbáltam ezt az oprendszert, de nem Gnome-mal, mivel a 3-ast nem szeretem, túl sokat változott a 2-eshez képest, szerintem nem jó irányban. A MATE nekem jobban fekszik (mivel az a Gnome 2 egyik forkja), ezért én azt a változatot választottam, amiben MATE az asztali környezet. 1GB-tal simán ment. Ezután fokozatos közelítéssel (felezgetésekkel) arra jutottam, hogy megy ez 753MB RAM-mal is. Kisebb memóriaméret esetén gondolkodik egy kicsit a rendszer annál a résznél, még az elején, amikor kiírja, hogy "Loading initial ramdisk...", és újraindul a virtuális gép, de kernel panic nem volt egyszer sem, még 512MB RAM esetén sem.
Már más is kérdezte, de válasz még nem jött rá, ezért én is megkérdezem: az "1 Giga memória kevés neki, főleg vboxban" mit akar jelenteni? Főleg a "főleg vboxban" :)

Ha jól emlékszem az újabb UHU-k tulajdonképpen Live verziók, amelyek ramdiszken tanyáznak. Ezért aztán ha a virtualbox-nak kevés memóriát ad az ember, akkor a kicsomagolás a ramdiszkre nem fog sikerülni. Az eredmény pedig ez.
--
♙♘♗♖♕♔

Nálam MATE esetén ilyen nem látszott, pedig próbáltam előcsalni a képernyőre az újraindulás okát, de nem sikerült. Úgy sem találtam semmilyen használható információt, hogy egy sikertelen bootolás után egy Live CD-vel bootoltam, majd felcsatoltam az UHU két fájlrendszerét (van egy 1GB körüli a bootnak, meg egy másik a fájlrendszer többi részének). A syslogban csak a sikeres bootolások látszanak, sikertelen bootolás esetén el sem jutott odáig a rendszer, hogy írni tudjon a syslogba.

Csak most vettem észre, hogy a linket rosszul másoltam be.
Szóval ezt produkálta: http://i.imgur.com/8h0bF5Hl.png
--
♙♘♗♖♕♔

Nem csoda a pánik, hisz a gnome azért terjedelmes, könnyen lehet, hogy az 1 Giga memória kevés neki, főleg vboxban.
Írd ki pendrájvra az isót és bootolj arról!

"főleg vboxban"

talán a virtualboxban lévő 1GB memória nem is 1GB memória?

kár, hogy a gnome2 környezet ebben sincs már benne, számomra eddig ez volt a leghasználhatóbb asztalkörnyezet :( pl. gnome3-ban a nautilus már arra sem képes, hogy "új üres fájl létrehozása"... meg már az sem működik, hogy fájl megnyitása egyéb paranccsal.

Ha a gnome nem is lenne "naprakész", lehetne egy gnome2 is beleépítve, szerintem többet tudott, mint az összes mai "naprakész" asztali környezet együttvéve.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

+1 A Gnome2-t szerettem legjobban én is. Minden működött, minden a helyén volt. Aztán rájöttek, hogy újra kell írni. De már olyan régen volt, hogy alig emlékszem.

Cinnamon van helyette, meg mate.
Ki tehet róla, hogy a gnome2 karbantartása, naprakész tartása abbamaradt?
Talán a gnome fejlesztők a leginkább. Az ő fejüket kell megmosni, szidni.

A mate gnome2 fork, nem jó megoldás azt használni?

De igen. A letölthető ISO alapból Mate-t telepít.
A többi ablakkezelő a szerverről telepíthető.

Akkor viszont fura, hogy fentebb pont a gnome2-t hiányolják. Azt még el tudom képzelni, hogy a mate rossz irányba ment vele.

Ezt én sem igazán értem, de nem is kell nekem mindent érteni... :)
Egyébként a Mate-val nincs semmi baj (még) szerintem.

Nekem a MATE ment VirtualBox alatt, bootolt rendesen, telepíteni is sikerült.
Megfigyelések (kb. 10-15 perc használat után):
- VirtualBox-ban futtatva az alapfelbontás nagyon kicsi: 640x480
- Érdekesen viselkedett ennél a kicsi felbontásnál a kijelző: időnként néhány terület lefedésre került, ami egérmozgatásra felfedhető volt (ez a hiba pl. akkor fordult elő, amikor belenéztem a logokba less-szel, és "közlekedtem" balra-jobbra a sorokban)
- Nincs aptitude (a csomagtárolóban sincs) - én szeretem, valamiért ezt szoktam meg az apt-get és egyebek helyett
- Alaphelyzetben nem támogatott a VirtualBox, a Guest Additions telepítéséhez szükség volt előzetesen a kernelforrások "beszerzésére"
- A felhasználó csak a users csoport tagja (nincs a sudoers fájlban sem) - ez sem gond, csak a legnépszerűbb disztribúciókban nem így van
- A Synaptic-ból hiányzik a gyorskereső funkció (az apt-xapian-index meg nincs a csomagtárolóban)
- Nincs minden magyarítva (Apply, Close stb.) - ez nem katasztrófa, csak megfigyelés :-)

Hát nem is arra készült, hogy virtualboxban használják.

Magyarítva meg az is van, ami más disztrókban nincs. (Az lxqt magyarításai az lxqt github forrásába példul az én PR-jeim nyomán kerültek bele, azóta az ubuntuban is magyarabb már az lxqt.) A magyarítások a forrásokból származnak kevés zömében, nincsen minden upstream forrásban a nyelvi fájlok frissítve a fejlesztők által, ez pedig elsősorban az ő dolguk és nem a csomagolóké, főleg nem patch -ek alkalmazásával.
Régi hagyomány az UHU vonalnak, hogy nem szaporítjuk csoportok számát, csak akkor létesítünk új csoportot, ha nagyon muszály és elkerülhetetlen. Ettől függetlenül, ha valaki akarja, nyugodtan hozzáadhatja magát a media, vagy audio csoporthoz.
http://ubk.hu/users-groups.html
De minek, ha users csoporttagként is nézhet filmeket a médialejátszókkal?

Nem hülyeség pedig a virtualizáció :)

A magyarításra tett megjegyzésemet először nem is akartam leírni, de meggondoltam magam, mert az ismerőseim között is vannak többen, akik sírva fakadnak, ha valami nem magyarul van, nekik nem lehet akármit feltennem a gépükre Linux alá, csak azt, ami teljesen magyarul "beszél" (60 fölött már nem akarnak nyelvet tanulni).

Azt nem tudom, hogy muszáj lenne-e több csoportnak lennie, csak furcsa volt ez a megoldás, mert más disztribúcióknál nem ezt tapasztaltam. Talán így egy kicsit nehezebb a rendszergazda dolga, ha korlátozni szeretné egyes userek jogait.

Nekem nem sikerül a Guest Additions telepítése, pedig a kernel-headers csomag telepítve van :(
http://i.imgur.com/y7YfLDfl.png
http://i.imgur.com/KS6aD4Ql.png
--
♙♘♗♖♕♔

A kernel-dev kell még hozzá.

Ne haragudj, nem bírtam ki: biztos, hogy olyasvalaki kellene "magyarítson", aki leírja azt, hogy "muszály"?!
------------------------
{0} ok boto
boto ?

miabalyodvele ??? :):):)
a "muß sein" magyarosodot tellyesen .... //az ly az, ami igazán magyar// ... :):):)
a "j"-t csak az idegen eredetű "dzsé" //ez a betű nem is létezik// helyett használnám ...
lásd: ninja, finja, lánja, hanjár, no + a joe //nem is kell átirni dzsóra//... :):):)
de viccen kívül, őszintén örülnék, ha 1 frissen összerakott, BÁRMELY disztribben, csak 1 ly-j elírás lenne a lenne a legnagyobb offogás tárgya ...
:):):)
_____________________
www.pingvinpasztor.hu

"Hát nem is arra készült, hogy virtualboxban használják."

Pedig sokan abban próbálják ki, és ha ott "elvérzik", akkor a legtöbb embernél már nem biztos, hogy kap egy újabb esélyt. Sajnos VirtualBox-ban 640x480-nál nem enged nagyobb felbontást beállítani, így meg gyakorlatilag használhatatlan. Nekem például most nincs se szabad partícióm, se üres DVD-m, se pendrájvom, hogy arról próbálhassam ki.
--
♙♘♗♖♕♔

Egy 8 Gigás célpendrájv elegendő lenne.
Hidd el nekem, megéri! Nekem már sokkal jobbnak tűnik, mint a z UHU-3.
Lehet, hogy sikerülne visszacsábítania téged.

Utánajártam, az újabb isók virtualboxban nekem sem hajlandók kicsomagolni a ramdiszket, bepánikolnak. A régebbi, nem kidobolt és már nem létező, ellenben régebbi kernellel készültekkel semmi ilyen gond nem volt virtualboxban.

Ellenben valamennyi mostani isó kiírva pendrájvra fizikai gépen 1,5 Giga Rammal szépen bebootol nekem és elindulnak a live rendszerek.
Úgy néz ki tehát, a virtualboxban keresendő a hiba, vagy annak beállításában, vagy magában a virtualbox kódjában, mely ugye Oracle gyártmány. Esetlek a kernelt kellne a virtualbox igényeihez passzítani.

Régebben már volt egy ilyen eset: https://patchwork.kernel.org/patch/4396841/
Ez persze nem virtualboxos eset volt, amire a linkelt patch született.

Ellenőrzésképpen csináltam 1,7 Gigabájtos lxde minimális isót, az is elvérzik virtuálboxban, ellenben egy 2 gigás penrájvra írtan arról szépen elindul a minimális lxde rendszer.

Az lxde isó virtuálboxos üzenete a következő:

/initrd.image: incomplete write (12288 != 217492161)
wistron_btns: System unknow
RAMDISK: EOF while reading compressed data
Kernel panic - not sycings: VFS: Unable to mount fs or unknow-block(0,0)
Kernel Offset: disabled
Rebooting in 30 seconds.._

Összegezve egyelőre úgy néz ki, hogy a RIA isók virtualboxos pánikjával én egyelőre nem tudok mit kezdeni a 2 Giga összmemóriával rendelkező gépemen.
Ellenben fizikai gépeken szépen működnek.

Nem ez a probléma, mivel 2GB ramot adva a virtualboxnak már megy. A baj (legalábbis nálam) ez.
--
♙♘♗♖♕♔

Kernel modulhoz a kernel-dev is kellene netán?
Janusz követte el valaha, mikor sírtam, hogy nem tudok nvidia modult csinálni a kernel-headers csomagjával.
Azóta van külön kernel-dev csomag az UHU-ban.
Esetleg lehetne egy ilyen Guest-addons csomag is készen a virtualbox számára.
Gondolom nem jelente problémát számodra egy ilyen legyártása, ha lenne valamilyen UHU telepítményed.

Bingó! Csak a kernel-headers csomagra emlékeztem, a kernel-dev felrakása már nem jutott eszembe.
--
♙♘♗♖♕♔

synaptic: az apt-xapian-index python cuccokat használ, a python cuccok függőségeit pedig néha elég horror rendesen felderíteni, úgyhogy részemről python cucc csak akkor, ha muszáj. Emiatt még nem néztem meg - no meg eddig ilyen konkrét igény sem volt rá.
aptitude: az UHU 3-hoz megcsináltam a 0.6.11-et (az aptik függősége), de a gtest/gmock függősége miatt feladtam a későbbi verziók elkészítését. Olyan helyen keresi ezeket, hogy a hajam égnek áll tőle :)
synaptic magyarítás: köszi az észrevételt, én is tapasztaltam már. Most ránéztem a dologra: néhány fordítás fuzzy állapotú a hu.po-ban, többek közt az Apply és a Cancel is. Nem naprakész a fordítás, patch kell hozzá.

- rezso -

1 óránnyi gyorsteszt után:

- tényleg nagyon sok a csomag, és frissek is. Én majdnem mindent megtaláltam amit használni szoktam, pár egzotikum nem lett meg.
amit kiemelnék hogy igen nagy hiány van emulátorokból (nes, snes, sega, stb)
- a synaptic elég fapad: az ubuntu által foltozott verzió sokkal többet tud, érdemes lenne szvsz azt használni.
- a szerver párszor pár percre lehallt, reméljük a túl nagy érdeklődés következtében :)
- valamiért nem látom a samba-s megosztásokat, pedig elvileg minden telepítve van hozzá alapból (próbáltam nemo-val és dolphinnal is)
- az sddm rossz dpi beállításokkal indul, nálam minden óriási (24", 1080p)

Ezeket leszámítva le a kalappal, gyakorlatilag teljesen szép, friss, gyors, működőképes minden. Remélem lesznek még akik segítenek, és nem fogy el a lendület. A tesztelést folytatom, tetszik a dolog :)

Emulátorokból viszont olyan is van, ami másutt nincs. Például ep128emu, plus4emu.
A synaptic az debian upstream forrású, de lehet, hogy ránézünk gyermekének, az ubuntunak foltozott verziójára.

Akkos is a gyorskereső funkcióra gondolhatott talán, amit írtam korábban, amihez pedig kellene az apt-xapian-index.

amit én hiányolok, az leginkább a részletes csomaginformáció - akkor, amikor rákattintok legyen létható az alsó ablakban. (Tulajdonképpen a tulajdonságok ablak tartalma kerül oda)
Meg persze a gyorskereső is nagyon hasznos.

„a synaptic elég fapad: az ubuntu által foltozott verzió sokkal többet tud, érdemes lenne szvsz azt használni”

Ez létezik release formában náluk, vagy patch készlet csak?

- rezso -

a samba-s megosztásokra a gyógyír:
smb.conf-ban csak az eth* és ath*-al kezdődő hálókártyákat figyeli. Értelemszerűen ki kell egészíteni a hálókártyád nevével, és utána már megy.

Pentium M processzoros gépre - amiben nincs PAE támogatás - fel lehet tenni?
Van egy Thinkpad gép az asztal alatt, de csak XP megy rajta.

Nem, már az UHU-3 is PAE igényű volt.
Öreg gépre régi Linux való, vagy Puppy-Linux. Esetleg gentoo, mert abban előírhatod a PAE mellőzését a telepítésénél, csak nehéz régi gépen a gépre fordítást kivárni, nekem egy régi IBM thinkpadra, 256 Mb RAM-mal 5 napig tartott a telepítése, mire eljutott az icewm -ig.

nálam pentium m-es gépen nagyon szépen muzsikál a legújabb debian is.

http://hup.hu/node/143458 - Emitt leírtam egy éve a tapasztalataimat, azóta is napi! használatban van, és teszi a dolgát. Igaz a gazdája türelmes, és nem nyit meg 10 lapot egyszerre :)

Hmm. Egy Thinkpad T42-re próbáltam feltenni Ubuntut, Mintet, UHU-t is, de a PAE hiányán nem tudtam túllépni. Amit fórumok javasoltak, hogy PAE nélküli kiadásokat frissítgessek apránként, mert úgy már fog bootolni a rendszer.
Szóval azt mondod, hogy a Jessie megy pae támogatás nélkül Pentium M-en?

igen, egész biztos. Ha jól rémlik amikor bootolod a telepítőt meg kell adni a forcepae paramétert, aztán már nem kell mókolni semmit. Nálam liquorix kernellel megy, de megy az alap is. Nézz utána, mert az emlékeim már 1 évesek, azóta csak használjuk a gépet :)
(Amúgy a kezdetekben volt rajta egy rövid ideig arch linux is)

Azt olvastam a Birodalomban, hogy a Pentium M tudja a PAE utasításkészletet, csak szemérmesen titkolja.
Ezért ha a forcepae paraméterrel ráveszed a kernelt, hogy PAE-zzon csak bátran, akkor mehet a móka.

A többi disztrónál se tart sokáig egy kipróbálás...

Nekem is beugrott, hogy van aki a forcepae opcióval használja.

A forcepae opciót így már megtaláltam több videóban is, kifogom próbálni.
Ez alapján a RIA is menni fog akkor!?

Elvileg igen.
Utánanéztem, az sse2 utasításokat is értelmezi ez a processzor, tehát a qt5 alapú cuccok is menni fognak, azaz az sddm beléptető, sőt akár a plasma is döcöghet.

És tényleg!

The Banias family processors internally support PAE but do not show the PAE support flag in their CPUID information; this causes some operating systems (primarily Linux distributions) to refuse to boot on such processors since PAE support is required in their kernels.

én egy antix-ot használok pentium m-es laptoppal (512Mb) az is (valamelyik verziója) jessie alapú.

Tehát akkor PAE nélkül pont nem megy, hanem éppen azt kellett kierőszakolnod, hogy függetlenül attól, mit "gondol" az oprendszer az aktuális CPU képességeiről, mindenképpen kísérelje meg használni a PAE-t.

Igen. Nem emlékeztem a részletekre, csak azt tudtam hogy Pentium M-mel működik.

Van már egy ideje tiszta 64 bites is. Teljesen tisztán 64 bites, nem kevert, mert nincs 32 bites glibc benne, tehát ELF32 életképtelen benne.

http://download.ubk.hu/iso/UBK1/

A csomagok:
http://download.ubk.hu/pkg/UBK1/main64/

Hamarosan lesz ubk2 is, most alakítjuk, teszteljük, nyúzzuk.
http://download.ubk.hu/pkg/UBK2/
Iso még nincs nyilvános. Nekem van, mert generáltattam magamnak. Jól működő telepítményem is van 64 bites, btrfs fájlrendszeren.
A cinnamont, mate-t, lxqt -t nyúzom, tesztelem.

A fórum megszünt, levelezőlista van. http://lists.ubk.hu/

++
up
köszönjük!
:):):)
_____________________
www.pingvinpasztor.hu

+1

Lesz minimal install vagy net install változat?

A calamares van hálózati installálásra, tetszőlegesen összerakható csomagválasztékkal az egyetlen mate isón
Nem lesz minimal 300 Mb-os CD, mert a mai világban a legkisebb pendrájv is 4 Gb-os.
Akinek nem tetszik a mate telepítése hálózat nélkül, az feltelepíthet vele bármi mást magának. Például az icewm, vagy a plasma, vagy enlightenment.
Esetleg fvwm, vagy dwm...

Még valami: ha valaki egy telepített rendszer csomagjait akarja frissíteni,
akkor legelőször az apt-ot kell letölteni és dpkg-val telepíteni/frissíteni.
Ez azért van mert minket is "utolért" a tároló gpg-vel történő hitelesítése.
A tároló címei:
http://download.ubk.hu/pkg/UBK2/main/i386/
http://download.ubk.hu/pkg/UBK2/main/amd64/
ftp://download.ubk.hu/pkg/UBK2/main/i386/
ftp://download.ubk.hu/pkg/UBK2/main/amd64/

Üdv!

Szerettem volna kipróbálni UHU-t letöltöttem UHU-Linux-UBK1-MATE-20171217-amd64.iso , a letöltés jó
#md5sum UHU-Linux-UBK1-MATE-20171217-amd64.iso
3baa386242e7ea2cd8128489692ad58d UHU-Linux-UBK1-MATE-20171217-amd64.iso
Lenovo G50 laptop ssd winyó
92 % -nál megfagy többször elindítottam a telepítőt , mindig 92 %-ig jut .

Szia!

Valami hardware összeférhetetlenségre gyanakszom ugyanis mindkét
(32 ill 64 bites) iso-val csináltam próbatelepítést, igaz asztali
gépen.
Más disztribúció települt arra a laptopra? Sajnos nem mindegyik
barátja a linuxnak. :(

Csak linux van a gépemen , windows nekem kínai , na nem mintha a linux-hoz annyira értenék :))
Sz.g vásárlásakor elsődleges szempont , hogy a linux kedvelje .
Mostani forma . ssd merevlemez 500 GB
Leap 42.3 az alap , de mivel 14 éve használom a suse-t jött az ötlet ideje más verziókat is megnézek.
sda1 20 GB Slackvare
sda2 20 GB Kubuntu
sda3 20 GB Debian
sda4 logikai
sda5 250 GB Leap suse
sda6 5 GB swap
sda7 4 GB swap
sda8 20 GB Linux Mint
sda9 20 GB Mageia 6
sda10 20 GB Kde Neon
sda11 20 GB Arch
sda12 20 GB lett volna az UHU
A komplett suse-ról van 2 db. külső winyón biztonsági mentésem az összes dokumentumaimmal számláimmal amit bármikor vissza másolhatok , nyugodtan kísérletezhetek , ha esetleg tudsz valami megoldást hogyan tudnám megnézni mi a hiba ?

Ennyi linux egy gépre telepítve... használod is mindegyiket?

Csak most próbaképp , így némileg összetudom hasonlítani melyik indul gyorsabban , melyik másolható boot-olható egyszerűbben , a méret , mennyire magyar , mennyire találok segítséget ha gondom van , stb...
Vannak különbségek , apróságok , és majd meglátom váltok vagy sem , nem nagy dolog mert csak 3 gépről van szó .

Egyébként magyar emberként magyar terméket használok mindenben , ahol csak lehet , az UHU-t néztem ár az elején csak akkor nem találtam rá erre az új verzióra .

Szerencsésebb lett volna ezeket a tesztrendszereket virtuális gépen futtatnod. Rengeteg oprendszert néztem meg VirtualBox alatt, soha nem volt probléma, hogy nem fizikai gépen futnak. Némelyik "egzotikus" OS esetén volt csak macerás a VirtualBox Guest Additions telepítése, de ez is inkább hasznot hozott, mert ebből is lehetett tanulni.

Lehet nyugisabb a virtuális gép , régebben vmware-t használtam én is , de így legalább rendes vason vannak , különösebb gond nem lehet , mint mondtam vannak komplett másolataim , ha valami balul sül el kb. 30 perc alatt visszamásolom az egészet :)) Az ssd-n pedig pár másodperc egy újraindítás .

Gondolom, kedvenc csevegőpartnered Zuzu Petals... :-) Egy vm-et snapshot-ból szerinted mennyi visszarakni...? normális rendszert 30 perc alatt nullából fel lehet telepíteni, nemhogy visszaállítani...

és még én hittem azt hogy a tesztgépemen a 3 oprendszer 10 partíción az elvetemült állatság...
amúgy minek tartasz két swapot?


"all submitted complaints will be forwarded to /dev/null for further investigation"

"92 % -nál megfagy többször elindítottam a telepítőt , mindig 92 %-ig jut "

Én lennék a telepítők orvosa jobb híján, több kérdésem is van, hogy ezt a hibát ki lehessen javatítani.
Ez az infó, amit írtál édeskevés.

Mi ez a 92%?
Milyen telepítőt használtál?
Milyen fájlrendszerre akartál telepíteni?
Milyen partíciókiosztással?

Homályosítások következnek...

Két telepítő van az isón, az uhu-installer és a calamares.

Az uhu-installer.

Az uhu-installer egy perl nyelven írt telepítő a ma már ősi glade2 felülettel, ezt a perl csodát eredetileg az UHU-Linux KFT alkotói alkották, akkor még nem létezett 64 bites rendszer. Sok téren módosítani kényszerültem, noha a perl ismeretek terén ugyancsak tapasztalatlan valék. Szégyenszemre nem volt nálam jobb arra kapható, hogy megpróbálja helyrerántani. Ennek 2 telepítési módja van, az easy és a haladó. Az easy módban a teljes céllemezt használja, önállóan partícionálja új gpt partíciótáblával ext4 -es fájlrendszerekkel. Haladó módban lehetőség van saját partíciókra és más fájlrendszekre telepítésre, ekkor a partíciók létrehozására a gpartedet indítja, amivel a felhasználó megcsinálja a neki tetszőket. Easy módban nincs felhasználónév választás, a felhasználó UHU lesz, Normál módban meg a begépelt név.
Ezután átmásolódik a live rendszer a célra és létrehozza a betöltőt a kiválasztott helyre.
Ez 32 bites módban tök hibátlanul dolgozik már, az újabb fájlrendszerekkel akadthat gondja mint pl. a btrfs, habár én magam is végeztem már eredményes próbatelepítést btrfs-re, a perl csoda megfelelő módosítása után.
A telepítési folyamatot egy kék csík jelzi, ennek helyrepofozása 64 bitnél nem nagyon sikerült, valamennyire azért mutat valamit, ami csak a felhasználó nyugtatására elég, a valósághoz csak némi köze van.

A calamares.

Ez egy a fejlesztők áltat folyamatosan mind a napig karbantartott rendszertelepítő.QT5 alapú C és python nyelven íródott.
https://github.com/calamares/calamares

Ezt gyógyítottam be UBK alá.

Tetszőleges partícionálású tetszőleges fájlrendszerekre tud telepíteni, partícionálásra a KDE cuccait használja (kparted, satöbbi).
Ez a telepítő most két módot ismer, a netinstall és live módot.

Live mód.

Jellegzetessége, hogy a telepítéssel az isó által szolgáltatott live rendszert másolja át a célhelyre, tehát a telepítmény a live rendszerrel azonos lesz, nem kell internet kapcsolat a telepítéshez. A telepítés viszonlag gyors, kábé 15-30 perc.

Netinstall mód.

Útálja, ha csatolva van a célpartíció, egy umount -a nem árt előtte. Ezt live módban jól csinálja, illetve, ha a cél még nincs partícionálva, vagy megváltoztatjuk menet közben.
Internet kapcsolat szükséges hozzá, a telepítményre kerülő csomagválasztékot a felhasználó szabhatja meg, minden ami a telepítményre kerül, a központi ubk ftp tárolóból lesz letöltve és a telepítményre installálva. Első körben a nem választható, de mindenképp szükséges csomagokat telepítí fel a célhelyre, hogy át lehessen chrootolni és az oda feltelepedetett cuccok segítségével folytatódhatjék most már a felhasználó által kiválasztott csomagojk telepítése. folytatódjon a telepítés. A live módhoz képest jóval hoszabb ideig tart, úgy kábé 30-60 perc a csomagválaszék függvényében akár tőbb is lehet.

Mindkét módban a folyanat előrehaladását itt is kék csík jelzi, de szerintem ez sem tökéletes még, van, hogy vánszorog, van, hogy gyorsan rohan.
Net módban direkte hagytam egy xterm terminált amiben fit a calamares, azért, hogy figyelemmel lehessen kísérni chroot építés és egyéb előrehaladási üzeneteket.

Megjegyzem, hogy legalább 30 sikeres telepítést csináltam mind 32 bites, mind 64 bites ubk1 isókkal. A cél általában mdsos partíciótáblán létrehozott ext4, swap btrfs fájlrendszer volt, különféle kiosztásban. 16 Gigás pendrájvra is csináltam 64 bites céltelepítményt easy móddban (gpt) az uhu-installerrel, meg az IDE vinyóra cinnamon, gnome, lxqt, plasma telepítményeket netinstallal. (Előtte meg egy rakás vacakot is, melyek tanulságai alapján a telepítők hibáit lassan kijavítottam.)

Szóval jó lenne, ha egy kissé többet tunánk arról, hogy min is hasalhattál el?

Jellegzetessége, hogy a telepítéssel az isó által szolgáltatott live rendszert másolja át a célhelyre, tehát a telepítmény a live rendszerrel azonos lesz, nem kell internet kapcsolat a telepítéshez. A telepítés viszonylag gyors, kábé 15-30 perc.

Nemár... emlékeim szerint dvd-ről max 5 perc volt az install hdd-re, netről pedig kb 2 perc. Mindez 5+ éve. Mitől lett ez 15-30 perc? :)

Az uhu-installer gyorsabb, mint a calamares, gyors gépen nyilván gyorsabb mindegyik, mint amit írtam.

Ezek az időértékek nálam pendrájvra írt isóról usb-átalakítón lógó 10 Gigás IDE vinyóra történt próbatelepítések értékei.
Az egész gép kuka márkás.
A gép alaplapja mintegy 10 éves, 1,8 Ghz-es Intel procija van, 2 Giga DDR2 RAM-os, az usb rajta 2.0 -ás. Az alaplap IDE vezérlője be tojt, azért dobták a kukába, a bratyóm szedte onnan ki. Sata vezérlője jó, sata vinyókkal használom, 2 van rajta, uhu-2.2, uhu-3 ubk, uhu-ubk1, meg egy tök felesleges win7 a bratyóm kedvéért. Az uhu ubk1-en készült az ubk 64 bit számmottevő csomagkészlete.
Rádugtam egy ssd -t az egyik sata madzagra, azon van egy ubk1 32 és egy ubk1 64 bit. Az ssd ubk1 32 biten forgatom most a leendő ubk2 64 bites csomagjait, ezzel már jóval gyorsabb, mint a sata vinyókon.
Az uhu-installerrel nálam kábé 10 perc egy UHU-3, vagy ubk1 telepítés ideje. Ha sata vinyóra telepítek, akkor sem lényegesen gyorsabb. Viszont 8 Gigás célpendrájvra egy 4 gigás pendrájvról egy telepítés minimum 15 perc.

Van egy medion laptottyom is, szintén kuka márka, arra egy ubk1 32 bit van telepítve egy 100 Gigás vinyóra a win7 mellé, az egész telepítés nem tartott 10 percig.

"Nemár... emlékeim szerint dvd-ről max 5 perc volt az install hdd-re, netről pedig kb 2 perc. Mindez 5+ éve. Mitől lett ez 15-30 perc? :)"

Ezt esetleg a calamres fejlesztők tudnák megmagyarázni. Ez python csoda, python értelmezéssel és nem perl alkotás, amire emlékszel.

Ez a /dev/loop1 eszközt másolja a célhelyre.
https://github.com/uhulinux/ub-ubk1/blob/master/calamares/patches/unpackfs.conf.patch

Akkor még nem létezett calamares, netinstall telepítési mód meg soha nem volt lehetséges az uhu installerrel.

Kár, hogy az uhu-installert én nem tudom úgy alakítani, hogy a megváltozott körülményehez tökéletesen használható legyen. Ezért én kárhoztatható is lehetnék. Nem vagyok programozó, perl-hez nem értek, csak autodidakta módon javítgattam rajta. Jóval jobb is lehetne, ha lenne olyan hozzáértő, aki ezt megtenné.

Vállalkozó kedvűek!

Valaha glade2 -vel készült, ami már rég idejétmúlt, glade felület használatára kellene átalakítani, alkalmassá tenni a 64 bites telepítésnél a folyamatjelző sáv helyes működésére, a btrfs rendszerre történő telepítésnél a fstab helyes előállítására, választható csomagkészlettel történő netinstall lehetőséggel.

Véletlenül rájöttem , mi volt a gond a telepítéskor.
A partíciókat suse alatt készítettem el előre, mivel suse-én alap a btrfs, mindegyikre btrfs került, holott hagyhattam volna üresen is. Azt láttam, hogy az UHU (is) ext4 fájlrendszert akar, jóvá is hagytam a formázást , de valami gond itt adódik . Ugyanis ha suse-val letsztítom a területet , akkor gond nélkül hoz létre új partíciót ext4 swap és települ.

Vivát!

Megjegyzem, hogy ez tiszta 64 bites rendszer, nincs benne 32 bites elf futtathatóságot biztosító glibc32.

Bármely desktopot felrakhatod a synapticcal az illető metacsomagjával, ha nem tetszik az alap mate.

Említettem volt, hogy a btrfs csak pár éves, a perl -es uhu-installer meg ugyancsak jó pár éves, akkor alkották, mikor a btrfs még nem létezett.
Ha már úgyis próbálkozol és nem sajnálod a telepítményt (van pár más is neked, köztük a tamakocsként frissítendő Arch is), a calamares -el is csinálhatnál próbát, az nekem btrfs -re is szuper telepítményt produkált.
Mondjuk a röptömörítést a fstabban nem engedélyezi ő sem, magam sem tudom, hogy miért, de ez legyen a calamares fejlesztők gondja.

Egy kérdésem még maradt, mivel KDE kedvelő vagyok, megnéztem rajta van a csomaglistán i386 -os csomagokban, nem okoz gondot 64 bites rendszeren ?

A synaptic alapból ai i386 -osakat is felsorolja tök feleslegesen, ez múló jelenség.
Idővel az alap isónál is már csak az amd64 tárolót fogja majd látni.

Szedd ki a synaptic tárolóiból az i386 -as tároló előtt a pipát, csak az amd64 maradjon.
ftp://ftp.ubk.hu/pkg/ubk1/main/amd64/

Ezután frissítés, majd a kde telepítése mehet már. A kde meta csak az alap plasma, kell még hozzá a kde-apps is, és hogy teljesen legyen a kde-apps-pim is mehet, mely a plasma levelező, meg személyes adazkazaeleő alkalmazásokat tartalmazza.
Még wailand -al is megy, noha például a synaptic ott nem működik, ez a synaptic upstream karbantartóinak a sara.

Elnézést , csak most vetem észre a fentebb írt , válaszodat .

Tudni kell abszolút laikus vagyok.
Szóval mindkét telepítővel próbálkoztam, a 92%-t clamares írta ki , az uhu-telepítő már az elején megakadt .
Pontosabbat nem tudok , mert amikor megakad akkor már nem tudok belépni terminála sem, minden megáll .
Az biztos , hogy lehet reprodukálni a hibát , mert többször is nekifutottam , és mindig oda jutott.
Azóta kiderült Fedora szintén nem megy föl suse által készített formázott partícióra , Fedora átformázni sem hajlandó , nem is lehet tovább lépni.

Live módot használtam , USB kulcsról telepítettem .
Lehet ez valami csak nálam jelentkező egyedi dolog , hiszen nem szoktak egy sereg oprendszert fölrakni egyetlen gépre .

"Tudni kell abszolút laikus vagyok.
Szóval mindkét telepítővel próbálkoztam, a 92%-t clamares írta ki , az uhu-telepítő már az elején megakadt .
Pontosabbat nem tudok , mert amikor megakad akkor már nem tudok belépni terminála sem, minden megáll .
Az biztos , hogy lehet reprodukálni a hibát , mert többször is nekifutottam , és mindig oda jutott.
Azóta kiderült Fedora szintén nem megy föl suse által készített formázott partícióra , Fedora átformázni sem hajlandó , nem is lehet tovább lépni. "

Nem lehetsz annyira kezdő, ha Arch-linux is telepítve neked, laikusnak én is laikus, azaz nem hivatalos vagyok.

Ezzel a kellemetlen teljes lefagyással én is találkoztam már, mit mondjak... Nagy élmény! Persze ez nekem az új xorg-servernél volt, mert bevezették újabban az xf86-input-libinput csodát, amit nem vertek nagydobra és csak néztem, hogy ott pompázik a grafikus beléptető és teljes a fagyás. Jó nyomozás volt.

Mindenesetre amikor nekem a calamares formázta btrfs-re a partíciót, akkor sose volt gond vele.
A kék folyamatjelző meg a calamares fejlesztők által abszolúte fejlesztés alatt van még, csak a felhasználó megnyugtatására van, támpontot nem ad.
Érdekes lehet amit a Suse csinál, hogy még a hírneves és tengernyi fejlesztóvel, karbantartóval rendelkező Fedora is orrabukik benne?

A KDE gond nélkül fölment .
Jó választás volt , azon fölül hogy ahhoz vagyok szokva, semmi gond vele a proci 2-4%-on nyugalomban. A mate viszont (most már KDE után tudom ) akad , fagyogat, van hogy csak a terminál marad.

Ezeket találtam .

syslog
Jan 4 07:00:46 scs-pc mate-session[3381]: WARNING: Failed to acquire org.gnome.SessionManager
Jan 4 07:00:53 scs-pc mate-session[3381]: Gtk-CRITICAL: gtk_main_quit: assertion 'main_loops != NULL' failed

Xorg.0.log
1.153] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 11.154] (--) PCI:*(0:0:2:0) 8086:0f31:17aa:3905 rev 14, Mem @ 0x90000000/4194304, 0x80000000/268435456, I/O @ 0x00003050/8
[ 11.155] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
[ 11.155] (II) LoadModule: "glx"
[ 11.156] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so

Laikus , nos csak annyit tudok a linux-ról amennyi a használat során rám ragadt , pár parancs , nagyjából tudom mi hol van , ennyi.

Már csak egy kedvelt programom hiányzik . Konqueror .

Az alábbi csomagoknak teljesítetlen függőségei vannak:
konqueror : Függ ettől: tidy (>= 20051026) de csak 5.4.0-1.1 telepíthető
E: A problémák nem javíthatók, sérült csomagokat fogott vissza.

Konqueror megoldva, hogy jól-e az kérdés?
Először letöltöttem egy .tgz-s verziót , nem jött be mert újabb qt-t keres.
konqueror: /usr/lib/qt5/lib/libQt5Core.so.5: version `Qt_5.10' not found (required by /usr/lib/libKF5Konq.so.6)

Jött az ötlet letöltöttem http://download.ubk.hu/pkg/ubk1/main/amd64/ -ról konqueror-t kicsomagoltam és kézzel helyre raktam, látszólag jó, hibaüzenet nincs, minden működik. Lehet egy szép napon összeomlik tőle a rendszer ? :)

Az a baj, hogy az így keletkezett állapot követhetetlen és karbantarthatatlan. Nem elég valamit működő állapotra hozni, ennek az eredménynek reprodukálhatónak is kell lennie! Ha nincs csomagkezelőd, nagyjából mindegy, ha viszont van, garantáltan ellene dolgozol, és abból csak baj lehet.
------------------------
{0} ok boto
boto ?

Mivel ez UHU csomag nem tudom hogyan lehetne föl telepíteni a függéségi probléma miatt , ami egybébként nem lehet valós mert a buildinfo-ban

tidy 20051026-2.2
tidy-dev 20051026-2.2

szerepel , ilyen régi verzió csak nem kellhet ?
A lényeg, hogy elvileg működhet rendesen így kézzel szétszórva?
Frissítéskor pedig oda kell figyelnem és előre eltávolítani a régi fájlokat akkor kézzel?

Az rpm -U --nodeps --force kapcsolók használhatók, apt-get -nél nem találtam ilyet, csak vak vagyok vagy nincs ?

Frissíts rá a tárolóra, már jó lesz.
Valamiért kimaradt egy adag a legutóbbi kde frissítésnél 64 biten, ezért lett rossz a függőség.

- rezso -

Kösz, azért a biztonság kedvéért letörölgettem a régi fájlokat kézzel, és most jó az új :)

"Kösz, azért a biztonság kedvéért letörölgettem a régi fájlokat kézzel, és most jó az új :)"

Azért a barkács módszer(fájlok ide-oda másolgatása, törölgetése) nem igazán jó, habár lehet, hogy eredményes módszer. Ez amolyan windózos berögződés.

Az uhu és a RIA az apt -ot és a dpkg -t használja. Elsősorban az apt -ot, vagy annak grafikus felületét, a synaptic -ot kell használni. Nagyon értelmesen van megírva, az apt a leírása szerint "a szupertehén hatalmával rendelkezik".
Ha letöltesz egy csomagot, azt a dpkg -val illik feltelepíteni, nem pedig annak tartalmát kicsomagolni a gyökér fájlrendszerre.
Így kell (su - jogokkal) csinálni helyesen: dpkg -i útvonalasletöltöttcsomagod
Ha valami nem tetszik neki, majd visszaszól.
Rengeteg kapcsolója van, például a --force-all a legveszélyesebb, ekkor felerőszakolja a csomagot akkor is, ha az nem fog működni és a rendszert is hazavágja.

Ha valamilyen csomaggal baj van, netán nem települ, akkor értesítést küldesz a levelezőlisára (olyanunk is van) és igen rövid időn belül megoldjuk a gondod. Minél többen használják a rendszert, annál inkább jobb is lesz, több rejtett hiba bukkanhat elő, mert mindenre nem terjedhet ki a csomagolók, javítók, tesztelők figyelme.

A mostani gondot Rezső már meg is oldotta.
Én például konquerort soha nem használtam, a plasma -t is csak kíváncsiságból telepítettem fel, nem kedvelem, én jobbára mate alatt dolgozom, meg a cinnamont tesztelgetem, mert az én gyógyítottam be a rendszerünkbe.
Ellenben a krusader -t használom mate alatt is.

Egy biztos windows-os berögződésem nincs, nekem kínai, egyáltalán nem ismerem, aki anno megmutatta a sz.gépet linux-t használt, rpm alapút.

Ok renben értem, hogy nem jó módszer a barkács, és tényleg nagyon gyorsan meglett a javítás. Egyébként még nem használom élesben UHU-t , de igyekszem minél jobban megismerni, azért is kísérletezek vele, olvasok amit találok, kérdezek, de mindig van egy másolatom az eredeti rendszerről, amit percek alatt visszamásolhatok, ha nagyon elszúrok valamit, és megyek megkeresem a levelezőlistát.

A következő problémám, a helyesírás-ellenőrző mindent hibásnak lát, mi lehet a gond?

Milyen nyelv van a nyelvi ellenőrzéshez beállítva...?

Magyar, ha a KDE és a böngésző a kérdés. Az office-ban működik.
A böngészőben nem jó Firefox-ban és Konqueror-ban sem .

Most tényleg jó. Nem tudom lehet, a véletlen műve, de gyorsabb is lett.