remélem tudtok segíteni.....csináltam egy LIVE creator segítségével egy USB-re egy Fedora-17-x86_64-Live-Desktop.iso-ból egy indítható valamit, ami nem indul, hanem ezt irja ki bootolás után: dracut warning: unable to process initqueue
dracut warning: /dev/disk/by-uuid/40B5-B740 does not exist
dracut warning: dev/mapper/live-rw does not exist
droping to debug shell
dracut:/#_(...és itt villog a kurzor)
ez egy w7 alatt szerettem volna elinditani...szóval az USB-n rajta a fedora, boot az USB-ről...és ez az eredmény...egyelőre....tudtok ebben segíteni?
Az a sanda gyanúm, hogy a libXi vagy libX11 környékén lesz valami disznóság, vagy a numlockx-ben alkalmazott megoldás helyett valami mást kell csinálni.
Lefordult, csomagot csinált az rpmbuild, feltelepült, működik.
A probléma egyébként az volt, hogy a spec file-ban volt hivatkozás macro-ra, aminek nem is tudom, hol kellett volna definiálódni. Az a kisebbik baj, hogy én nem tudtam, a nagyobb az, hogy az rpmbuild sem. Így aztán szépen leállt a feltételes fordítási, telepítési opcióknál.
Megoldásként azt ötlöttem ki, hogy a feltételes opciók közül választok egy nekem tetszőt, s így elmulasztom a feltételeket. Konstans döntésekhez nem kell if. Így is lett, de éppen rosszat választottam. Nevezetesen a custom függvényekben nem voltam megengedő, így a libek közül letörölte a spec file script-je a már lefordított library-t, ettől függetlenül persze a calc bináris még hivatkozott rá, meg persze az rpm csomagban, mint szükséges lib, ez szerepelt.
A megoldás az lett, hogy a feltételes fordítási, telepítési opciók közül azt választottam, amelyik megengedi ezen custom library létezését.
Nem értek az X-hez - sem -, ugyanakkor van egy nyúlfarknyi program, a numlockx, amiben az a nagyon jó, hogy shell script-ből lehet a Num Lock státuszt változtatni. Fedora 14 igen friss X-et használ:
xorg-x11-server 1.9.0-15.fc14
Na most a fenti program a Num Lock státusz változtatására képes, ugyanakkor a LED státuszt nem változtatja meg. Ezt is magamnak kellett csomaggá tennem, mert amit a fedorások fordítottak, az olyan szinten nem működik, hogy egyiket sem képes módosítani, tehát lényegében semmit sem csinál.
Valóban ennyire bonyolult ezt megoldani, az X API-ja nem biztosít erre lehetőséget, vagy vajon mi lehet a probléma lényege? Mert így a partvonalról azért ez nem tűnik egy Holdra szállás szintű feladatnak.
De, a sajátja. Most nem néztem meg az általad írtat, mert már letöröltem, amit fordított. Abból a patch-ből puskázok, amit a fedorások a korábbi verziójú calc-hoz csináltak. Valami ilyesmi lesz a lényeg:
Nekem ez az ALOW_CUSTOM üres, így gondolom, az lesz a megfejtés, hogy az LDFLAGS ne tartalmazza a ${LIBCUSTCALC_STATIC} változót. Gondolom, ez nem csak a statikus libekre van meg a patch-ben, szóval nem biztos, hogy ez a releváns rész, de érzem, hogy valami ilyesmit kell keresnem. Bogarászom tovább, bár most elmegyek itthonról, majd holnap folytatom.
A calc.spec file-ba beletettem, hogy írjon logot. Innen ki is derült, hogy a Makefile.ship-et is használja. Kikommenteltem a platformhoz tartozó LD_SHARE értékadásokat - BSD, Windows nem érdekeltek -, aztán lefordult. Csomag is készült, már nem panaszkodik. Telepíteni még nem lehet:
error: Failed dependencies: libcustcalc.so.2.12.4.3()(64bit) is needed by calc-2.12.4.3-1.1.x86_64
Még rá kell jönnöm, miért vélelmezi, hogy kell neki a libcustcalc.so.2.12.4.3, amikor nyilván nem. Workaround lehetne az rpm parancs --force opciója, de ennél azért szebben kellene ezt. Mindegy, keresem tovább, bár nem biztos, hogy ma van erre időm...
Most menjünk vissza ahhoz a lépéshez, amikor ugye a fordítás során készítettünk egy logfájlt (make all 2>&1 | tee log.make.all), hogy abban megnézzük, hogy minő parancs állította elő a calc nevő programot... (szerintem egy libtool lesz a tettes)
Ami a régi, még Fedora 12-höz a disztribútor által szállított calc:
readelf -d /usr/bin/calc | grep RPATH
Az eredmény üres, tehát nincs benne RPATH. Gondolom, ez lenne a helyes, mert van egy default elérés, azt nem kell duplikálni. Azt is sejtem, hogy azért biztonsági rés, ha meg van adva egyéb alkönyvtár, mert akkor Rossz Ember csinálhat gonosz *.so-t, amelyet a bináris elkezd majd futtatni.
Széjjel vet az ideg. Az egyik kedvencemből, a calc nevű programból szeretnék Fedora 14-hez rpm csomagot csinálni. Már annyi módosítást tettem, hogy lefordul, tehát keletkezett egy patch-em. A gondom az alábbi üzenettel van:
******************************************************************************* * * WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild' * to fail. To ignore these errors, you can set the '$QA_RPATHS' * environment variable which is a bitmask allowing the values * below. The current value of QA_RPATHS is 0x0000. * * 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor * issue but are introducing redundant searchpaths without * providing a benefit. They can also cause errors in multilib * environments. * 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute * nor relative filenames and can therefore be a SECURITY risk * 0x0004 ... insecure RPATHs; these are relative RPATHs which are a * SECURITY risk * 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other * RPATHs; this is just a minor issue but usually unwanted * 0x0010 ... the RPATH is empty; there is no reason for such RPATHs * and they cause unneeded work while loading libraries * 0x0020 ... an RPATH references '..' of an absolute path; this will break * the functionality when the path before '..' is a symlink * * * Examples: * - to ignore standard and empty RPATHs, execute 'rpmbuild' like * $ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild my-package.src.rpm * - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like * $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths * ******************************************************************************* ERROR 0002: file '/usr/bin/calc' contains an invalid rpath '/home/locsemege/rpmbuild/BUILD/calc-2.12.4.3' in [/home/locsemege/rpmbuild/BUILD/calc-2.12.4.3:/lib:/usr/lib:/usr/lib64:/usr/local/lib] ERROR 0001: file '/usr/bin/calc' contains a standard rpath '/lib' in [/home/locsemege/rpmbuild/BUILD/calc-2.12.4.3:/lib:/usr/lib:/usr/lib64:/usr/local/lib] ERROR 0001: file '/usr/bin/calc' contains a standard rpath '/usr/lib' in [/home/locsemege/rpmbuild/BUILD/calc-2.12.4.3:/lib:/usr/lib:/usr/lib64:/usr/local/lib] ERROR 0001: file '/usr/bin/calc' contains a standard rpath '/usr/lib64' in [/home/locsemege/rpmbuild/BUILD/calc-2.12.4.3:/lib:/usr/lib:/usr/lib64:/usr/local/lib] ERROR 0002: file '/usr/bin/calc' contains an invalid rpath '/usr/local/lib' in [/home/locsemege/rpmbuild/BUILD/calc-2.12.4.3:/lib:/usr/lib:/usr/lib64:/usr/local/lib] error: Bad exit status from /var/tmp/rpm-tmp.j9u77B (%install)
RPM build errors: Bad exit status from /var/tmp/rpm-tmp.j9u77B (%install)
A problémát érteni vélem. Olyan helyen is keresné a bináris a shared object-et, ahol az biztosan nincs. Jelenleg a /usr/local/lib ilyen. Ezt az RPATH mondja meg.
A kérdésem: hogyan lehet a Makefile-ban elmondani neki, hogy mi legyen ez a bizonyos RPATH? A Makefile-ban nem találtam erre utalást, valahonnan mégis tudja. Gondolom, van valami system default.
Nem a probléma megkerülése érdekel, miszerint kikapcsolom az rpmbuild-ben az ellenőrzést. Azt szeretném, hogy ne keressen ott *.so-t, ahol biztosan nincs.
Nem kérdez, de utólag még feltehetsz valami kisebb erőforrásigényű desktop környezetet. Én gyors gépen is Xfce-t használok, szerintem nagyon kézreáll. Nagyon kényelmesen és gyorsan testreszabható. Nyilván nem azzal az idétlen megjelenéssel kell használni, amikor alul középen van egy rövid tálca, mert az valóban szörnyű.
Ilyesmit nem kérdez a debian install, azt telepít, amit jónak érez... egyébként is, a géppel semmi baj, egyszerűen idegesítenek ezek a 'felhasználóbarát' szolgáltatások, windows-ban is ezeket kapcsolom ki először...
