-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
_Dumber_
őstag
válasz
_Dumber_ #32715 üzenetére
Válaszolva a saját kérdésemre:
2 napos szívás és internet feltúrása után egy kernel visszaűállítás segített a dolgon.
Rossz kernel: Arch: 5-15-81-1 LTS
Ami még biztos, hogy jó: 5-10-90-1 LTS (lehet hogy az 5-15 eleje is megfelelő, de nem próbáltam).
Valamint az aktuális Nem LTS 6-os is működik. -
-
fatpingvin
addikt
-
_Dumber_
őstag
válasz
_Dumber_ #31226 üzenetére
Ha valakit érdekel akkor a problémát azonosítottam. Megoldásra vár.
(Kikerülni már ki tudom.) -
-
_Dumber_
őstag
válasz
_Dumber_ #31054 üzenetére
Lentebb látható előzmény után, teszteltem pár dolgot. Volt:
AP mozgatás/csere hálózaton belül (2 AP van telepítve) - hiba továbbra is jelentkezett
Más hálózatra csatlakozás. - Nem volt hiba
Beállítások csesztetése - hiba megmaradtEgy dolog maradt még, amire MasterMark kolléga hívta fel a figyelmemet, mégpedig a ARCH-on beül a kapcsolati beállítás törése.
Kitöröltem a csatlakozás beállításokat (KDE), majd újra létrehoztam (networkmanager). Azóta minden rendben ment egészen a mai napig. 1 óra után (cc 6-7x hálózatvesztés), kitöröltem ismét a beállítást. Azóta megint jó,
Mi a **kömtől száll el a beállítás és mi lehet a ludas egy egyszerű config fileban?
Van ötlete valakinek?
-
Vladi
nagyúr
válasz
_Dumber_ #31051 üzenetére
Frissítésnél azt nézd, hogy hálózati program, vagy driver frissült -e kb akkor amióta hiba van.
Alap pszichológia, évtizede alkalmazom fórumon. Ha fingomnincs a megoldásról akkor is visszakérdezek, ezzel más szempontú problémamegközelítésre késztetem a kérdezőt. Anno smart qestion néven futott a hőskorban.
-
válasz
_Dumber_ #30588 üzenetére
Dos/freedosnál sem hiszem hogy bármi extra működne rajta
Ezt csak arra írta, hogy kötelező lenne oprendszerrel eladni.....szóval semmi nem ösztökélné a gyártót, hogy egy Linuxot szabjon/rakjon rá, ha FreeDos is elegendő. De azt simán el tudom képzelni, hogy a tapipad numerikus része tényleg nem működik Linuxon vagy csak az átkapcsolással vannak gondok, fene tudja. A Vivobook 14-nél amúgy tán csak a metálszürke van szerelve ezzel az okos tapipaddal.
-
válasz
_Dumber_ #30580 üzenetére
Mivel kötelező oprendszerrel eladni a gépeket, ezért ez a spórolós megoldás.
Ez nem így van, kb a gépek 15%-a Dos*, FreeDos vagy OS nincs paraméterrel megy ki a nagykerekből. Innentől kezdve, ha mégis raknak rá mást és az nem működik, tapipad hibával menne vissza az összes gép a 14 napos elállás miatt és pár hét múlva a kiskerek egyszerűen nem rendelnének több ilyen gépet a nagykerektől, az meg a gyártótól. Persze aztán lehet, hogy úgy van, ahogy írod, a gyártók meg nem olvassák az Archwiki-t.
Ja ésa 15"-os gépeken Asusnál is van normál numerikus bill.
-
válasz
_Dumber_ #30578 üzenetére
Ne szivasd magad nem üzleti géppel, ha linuxot akarsz. Elitbook, thinkpad, latitude akár használtan. Esetleg ezek gagyibb verziói újonnan (E-s thinkpad, probook stb.), de azokkal azért lehetnek érdekes dolgok. A csúcskategória tuti megy Linuxal és abból is jobb 1-2 generációval ezelőtti.
Ugyan ez igaz a desktopokra is, csakis brand gépet érdemes.
-
-
Domonkos
addikt
-
_Dumber_
őstag
válasz
_Dumber_ #26646 üzenetére
MÉg egy két teszt:
A smartd futott, de leállítottam, -> eredmény ugyanaz..
inotifywatch kimenet:
inotify /dev/sda
-bash: inotify: command not found
root@nuc:~# inotifywatch /dev/sda
Establishing watches...
Finished establishing watches, now collecting statistics.
total access close_nowrite open filename
684 128 278 278 /dev/sda -
_Dumber_
őstag
válasz
_Dumber_ #26551 üzenetére
Probléma megoldva:
Archwiki:
force the use of a certain VCL UI interface, use one of the SAL_USE_VCLPLUGIN=gen, SAL_USE_VCLPLUGIN=kde4, SAL_USE_VCLPLUGIN=gtk or SAL_USE_VCLPLUGIN=gtk3 environment variables. These variables can be uncommented in /etc/profile.d/libreoffice-fresh.sh or /etc/profile.d/libreoffice-still.sh.
Nálam a GTK3-as beállítás vált be.
-
Frawly
veterán
válasz
_Dumber_ #26551 üzenetére
Nálam Arch Openbox alatt jó volt az 5.x-es és most jó a 6.0-ás LibreOffice is, mindig is fresh-t használtam. Sose volt vele semmilyen gond, bugmentesen működik. KDE alatt mondanám, hogy próbából a kompozitort állítsd le, de ha Openbox alatt is csinálja, akkor ott lehet más gond lesz.
-
Frawly
veterán
válasz
_Dumber_ #25615 üzenetére
/etc/systemd/logind.conf-ban [Login] részlegében szétnéztél az Arch Wikinek megfelelően?
-
_Dumber_
őstag
válasz
_Dumber_ #25615 üzenetére
Annyi változott, hogy teszteltem egy kicsit.
Ha az energiakezelés ki van kapcsolva:
vagy bekapcsolom, de a beállítás így néz ki (természetesen hálózatról üzemelek):
Akkor nem történik semmi, azaz a képernyő mindig bekapcsolva marad.
Ha az energiabeállítások ilyenek:
(azaz 5 percnél több van beállítva), akkor
5 perc után lehalványodik, majd cc 3-4 perc után elsötétül a képernyőHa viszont 5 percnél kevesebbre állítom, akkor a beállított idő múlva halványodik el, majd rá 2-3 percre elsötétül (holott én ezt nem kértem).
Lassan kihullik a hajam. Van ötlet, hogy mit nézzek meg?
-
spammer
veterán
válasz
_Dumber_ #24883 üzenetére
De ha dd-vel akarod, akkor ezt olvasd át: Disk cloning
-
-
válasz
_Dumber_ #23793 üzenetére
Alapból ott van elszúrva az egész, hogy a class neve és a fájl neve egyezni illik.
Egyébként beírtam ugyanezt a kódot, és compile után ment is. De!
[build_settings]
# %f will be replaced by the complete filename
# %e will be replaced by the filename without extension
# (use only one of it at one time)
compiler=javac "%f"
run_cmd=java "%e"
Itt is látható, hogy amíg te alul a java class nevével operálsz, addig ő a fájlnévvel. -
bambano
titán
válasz
_Dumber_ #23305 üzenetére
abszolút teljesen téves megközelítés.
először is az utolsó, ami eszembe jutna, hogy felrakok egy bármit a linuxomra, amitől nem lehet bármikor rebootolni. emiatt majd amikor fontos dolog miatt le kell állítani, akkor se fog sikerülni.másodszor neked az a problémád, hogy a windowsod nem értesül arról, hogy le kellene állnia, tehát ezt a problémát kell megoldani, nem pedig kotorászni a rendszerben és hasonlók.
a probléma helyes azonosítása után már nem is olyan nagy truváj beírni a guglinak, hogy remote shutting down windows és akkor ilyen remek oldalak kerülnek elő, amiben olyan fejezetcím van, hogy remote shut down windows from linux.
tehát a helyes eljárás az, hogyha le akarod állítani a gépet, akkor álljon le szabályosan a windows is.
-
ToMmY_hun
senior tag
válasz
_Dumber_ #23303 üzenetére
Kicsit utánajártam és a VMPlayer hivatalosan nem támogat ilyen funckiót. Az oka az, hogy ez felhasználói interakciókra épít, tehát elvárja hogy kézzel állítsd le mielőtt a host-ot kilövöd alóla. A szerver verzió támogatja a host-guest együttes shutdown mechanizmust.
A megoldás emiatt nem triviális. Gyanítom, hogy a fenti okból kifolyólag a szoftver készítője szándékosan nem hagyott kiskaput ennek kijátszására, szóval csak nagyon csúnya módszerekkel lehetne ezt megoldani.
Az egyik opció, hogy készítesz egy scriptet, ami shutdown esetén fut le és várakozik addig, amíg nem állítottad le kézzel a VMPlayer-t. Aztán például írhatnál egy kapcsolat orientált protokollra alapuló szerver-kliens programot, ahol a szerver a guest OS-en fut és figyelni a klienstől (host) érkező adatokat. A host-on lévő programot a shutdown scriptet editálva az első helyre rakod, ezzel elérve hogy a shutdown szekvencia kezdetén kérje a guest leállítását. Ennek elindítását a guest egy nyugtával jelezné és mondjuk a kapcsolat megszakadásából nagy valószínűséggel arra lehetne következtetni, hogy a guest leállt. Hangsúlyozom, hogy ez iszonyat csúnya és rendkívül rizikós megoldás. Semmi sem garantálja, hogy a guest valóban leállt, előfordulhat olyan eset, hogy egy mentés megfogja a leállítást, ugyanakkor az általad írt shutdown szerver már rég leállt és nincs információd a guest valódi állapotáról. Egy fokkal jobb lenne, ha közvetlenül a VMPlayer-rel tudnál kommunikálni, de gyanítom hogy erre nem adnak lehetőséget, mert akkor nem lenne értelme ezt a feature-t a szerverben kiemelni.Mi lenne, ha alapból a szerver verziót használnád?
-
spammer
veterán
válasz
_Dumber_ #23303 üzenetére
Biztosan sokféle módszerrel megoldható, de használhatsz shutdownra egy ilyen pofonegyszerű scriptet:
#!/bin/bash
check=$(pgrep vmware)
if [[ ! -z $check ]]; then
echo "vmware fut"
else
echo "vmware NEM fut"
fipgrep-nél cseréld ki a megfelelő névre, ha nem vmware néven fut (htop vagy top kiírja, mi az).
echo csak kiírja, hogy fut vagy nem, a helyére írhatsz shutdown-t vagy bármi mást, ez csak egy tesztelős példa. -
-
Vladi
nagyúr
válasz
_Dumber_ #23000 üzenetére
Lecsatolni miért kell?
A könyvtárat elég egyszer létrehozni, majd a kellő jogosultságokat beállítani. Az a rész elhagyható.
Az fstabba beírod, bár ha sima mounttal csatolsz akkor már ott van noauto opcióval. tegyél bele még egy user opciót, akkor a felhasználó is beránthatja. link, itt segítség.
utána az umount is megy elvileg.Ennyi. De nem lehetne ezt egy szinkronizáló démonnal csinálni? Biztos van ilyen progi.
-
CPT.Pirk
Jómunkásember
válasz
_Dumber_ #23000 üzenetére
A root crontabjába tenném bele a kellő dolgokat, aztán ott egy rsync elintézhetné a szinkronizálást. Így nem kell még mount jog se a usernek, minden lefut a háttérben a tudta nélkül.
szerk: jah izé, hogy a usernek kellene indítania. Akkor sztornó. Fix időnként, és / vagy pl. kijelentkezéskor, gép indításkor, stb. az nem jó?
-
bambano
titán
válasz
_Dumber_ #22704 üzenetére
például úgy, hogy kidobod a shorewallt.
"Mondjuk nekem az is furcsa, hogy a kábelmodememmel kapcsolt eth0 ledjei folyton forgalmat jeleznek.": ebben mi a furcsa? egy broadcast tartományban vagy egy csomó előfizetővel. arp meg hasonló broadcast forgalom villogtatja a ledet. -
Osiris
őstag
válasz
_Dumber_ #22498 üzenetére
Az ok az lehet, hogy hiányzik egy masquarade a shorewall konfigból (be kéne állítani, hogy a rajta áthaladó, a belső háló felé irányított csomagokra saját magát állítsa be forrás címként).
Most ez történik mikor a belső hálóból a kamerát akarod elérni:
-a kliens a kérést a saját ip címéről (mint forrás címről elküldi) a külső ip címre (amit a domain visszaad) mint cél címre.
-a kérést a routered továbbítja a kamerához, de a forrás ip-t nem változtatja meg (nem maszkolja) a saját ip címére.
-a kamera a beérkezett kérésre a választ a kérés forrás ip címére küldi (vagyis közvetlenül a kliensnek) és a válasz forrás ip címe a kamera ip címe lesz.
-a kliens a választ a külső ip címről várja (amit ő a kérés céljának megjelölt), így a kamerától kapott választ eldobja.A megoldás az lenne, hogy a router a kérést a saját nevében (saját ip címét forrásként beállítva) küldené tovább a belső hálóra a címzettnek, így a válasz is rajta keresztül menne vissza és a kliens így fel tudná dolgozni.
Ezt a módszert "hairpin nat"-nak is nevezik erre keress rá.
-
_Dumber_
őstag
válasz
_Dumber_ #22250 üzenetére
A routing tábla (route kimenete) így néz ki.. akár rákapcsolom, akár nem a AP-t:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 87.242.xxx.xx 0.0.0.0 UG 0 0 0 eth0.1
87.242.xx.xx * 255.255.254.0 U 0 0 0 eth0.1
192.168.2.0 * 255.255.255.0 U 0 0 0 br0az rt_tables file tartama pedig ez:
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep -
_Dumber_
őstag
válasz
_Dumber_ #21269 üzenetére
Nem teljesen nyert. Az volt a célom, hogy elsődlegesen a chromium, de lehetőleg mindegyik a RAM-ba cach-eljen.
Helyzet a következő: A .cach látszólag a ramfs-ben van, meg a /tmp is.
Ennek ellenére a következő jelenség tapasztalható:
A chromium indítás után, mikors a képernyőn a legtöbbet látogatott oldalak miniatürjei vannak, egyáltalán nem dolgozik a vinyó, valamint ezen írás megírásakor, pont ugyanúgy mintha el sem lenne indítva
Ezen forumoldal nézegetésekor, és néha (cc5mp), egy rövidet mozog.
A www.index.hu-n 2mp-nként egy kicsit mozdul.
A www.portfolio.hu-n 1-2 mp-ként sokat mozdul.Nyilván függ, hogy milyen minőségben, vagy milyen tartalommal vannak az oldalak megírva, de nekem az lett volna a célom, hogy ne a vinyó dolgozzon, hanem a Ram.
Van még valami oka hogy onnan olvas/ír valamit?
-
CPT.Pirk
Jómunkásember
válasz
_Dumber_ #21264 üzenetére
VMWare + ramdisk az maximum 1.9GB. Teljes kihasználtságnál 2.1GB marad minden másra, egy erősebb disztró se nagyon fogyaszt 500MB-nál több ramot, szóval van ott bőven. A ramdisk meg nem állandó lefoglalás, ténylegesen csak annyit foglal el, amennyi benne van, ezt a df -h paranccsal tudod nézni.
-
CPT.Pirk
Jómunkásember
válasz
_Dumber_ #21259 üzenetére
Az utolsóra válaszolva: nekem erre azt mondták korábban, hogy olyankor a vinyón folytatja, ha a ramdisk betelne. Azt egyébként nem tartom valószínűnek, ha időnként újraindítod a gépet mert annyit nem cachelnek a böngészők. 20 perc böngészés után belerakott nálam 8KB-t a Firefox.
-
N0zer0
senior tag
válasz
_Dumber_ #20762 üzenetére
Igen, 32-es végleges FF-szal megy, 34-es alfával csak fekete kép van. Chrome bétában jó. A HTML5 viszont FF alfában és Chrome bétában is kikapcsolja a képernyőt. Frissítettem kézzel Flasht, ez sem lehet baja. Ezek szerint a videokártya drivere is jó, mert akkor FF32-ben és Chrome-ban nem menne. Akkor ez a FF alfa bugja lesz.
-
N0zer0
senior tag
válasz
_Dumber_ #20710 üzenetére
A gyakorlatban nincs hátránya. Ahogy kék luficet írja, a konténerfájl elméletileg töredezhet létrehozáskor, de gyakorlatilag nem nagyon szokott. Másrészt elvileg a rendszernek dupla munka, mert a swap fájlban lévő adatokat íráskor ext4-re is le kell képeznie, de ez is észrevehetetlen plusz terhelés. A gyakorlatban a két megoldás sebességügyileg 0,000001%-ban különbözik. A swap konténerfájl sokkal rugalmasabb, én is azt fogok használni Arch alatt, sokkal kényelmesebben lehet növelni és csökkenteni, mint egy partíciót vagy egy LVM logikai kötetet.
A swap konténerfájlban épp úgy swap fájlrendszer van, mint egy swap partíción. Épp úgy kell a konténerfájlt is felcsatolni, mint egy partíciót (mount, /etc/fstab, satöbbi), olyan, mintha egy swap partícióról készült képfájl lenne. Épp úgy, ahogy egy bootolható linuxos iso-ban sem ext4 van, hanem épp olyan iso-fájlrendszer, mint egy telepítő CD/DVD-n. Persze ezt most nem neked írom, hanem csak úgy, ismeretterjesztő jelleggel, mert sokan nincsenek tisztában ezzel a dolgokkal, főleg windowsos felhasználók.
Sőt, ilyen a WUBI-val telepített Windows melletti Linux. Az NTFS fájlrendszeren tárol fájl, amiben rendes linuxos fájlrendszer van. Igaz ez kicsit jobban lassít, nem a dupla munka miatt, hanem a linuxos NTFS driver egy kicsit munkásabban kezeli az NTFS-ses lemezműveleteket, de szerintem egy mai gépnél nem vészes, mintha titkosítva lenne a cucc, nem lassít sokat. Én kezdők esetén a WUBI-s megoldást preferálnám, úgy nem barmolják szét a partíciókat, könnyebben eltávolítható a cucc, csak a WUBI-s módszer inkább nem szokott menni, mint igen.
-
_Dumber_
őstag
válasz
_Dumber_ #20459 üzenetére
Hazaértem.
Az arch (sda5)-re feltelepítettem az os-prober csomagot. Ezek után gond nélkül berakta a grub menübe az sda7 és az sda9 partíciót is.Továbbiakban:
Beboot sda7 (manjaro)-ra,
pacman -Rs grub - letakarítva
Kézzel töröltem a /etc/grub.d és a /boot/grub könyvtárat.
Grub újratelepítése.Update grub futtatása - minden rendben bootol a gép...
Most már csak azt mondja meg valaki, hogy manjaro alatt (Arch alatt nincs ilyen problémám), az update-rub futása közben a No volume groups found sorok után miért vár 5-10 percet a gép
Igy kb 10-15 percembe telik mire lefut az update-grub
[root@Gabor-Acer boot]# update-grub
Generating grub configuration file ...
Found background: /usr/share/grub/background.png
Found linux image: /boot/vmlinuz-310-x86_64
Found initrd image: /boot/initramfs-310-x86_64.img
Found initrd fallback image: /boot/initramfs-310-x86_64-fallback.img
Found linux image: /boot/vmlinuz-310-x86_64
Found initrd image: /boot/initramfs-310-x86_64.img
Found initrd fallback image: /boot/initramfs-310-x86_64-fallback.img
/dev/cdrom: open failed: Nem található adathordozó
No volume groups found
Found Arch on /dev/sda5
Found Arch Linux (rolling) on /dev/sda9
Found memtest86+ image: /boot/memtest86+/memtest.bin
No volume groups found
Found Arch on /dev/sda5
Found Arch Linux (rolling) on /dev/sda9
Found memtest86+ image: /boot/memtest86+/memtest.bin
doneMár azon gondolkodom, hogy a syslinux nem lenne e jobb és egyszerűbb....
-
_Dumber_
őstag
válasz
_Dumber_ #20458 üzenetére
Szerk lejárt:
Annyit találtam, hogy lehet nincs fent az os-prober az 5-ön. (ez egy aránylag friss arch). Ugyanakkor a 7-en azt nem értem, hogy ott meg a sajátját nem ismeri fel, és a külsősök közül is csak az egyiket.
5-arch
7-manjaro
9-archÖsszekutyulódhatott valami egy update-grub-bal, hogy 7-töl felfelé nem lát semmit a grub egyik rendszerről sem?
-
Phvhun
őstag
válasz
_Dumber_ #20230 üzenetére
Azért nem volt jó mert azt a grafikus felületen kell telepíteni, és ott jeleníti meg a kódokat távoli eléréshez, de ugye ssh-n keresztül nem lehet grafikus módozni..
Már tárgytalan az egész, túl kicsi a vps csomagom hogy értelmesen tudjak kezdeni bármit is grafikus felülettel, szoval hagyom a témát.
-
hódmaci
senior tag
válasz
_Dumber_ #20224 üzenetére
Miért van az ha feltelepítek egy linuxot akkor utána legyen mondjuk egy újraindítás és kész minden?
Megy a net,ha elindítom a böngészőt nem kér marhaságokat ha meg akarsz nézni egy filmet nem kell telepíteni semmi külön programot.
Ehelyett a win??????????
Föltelepíted az a rohadék még internetközelben sem volt de már az első újraindítás után konfigurál meg az apja f@sza tudja miket csinál órákig persze de kine kapcsold mert felrobban,és még ráadásul ha meg akarok nézni valami kisfilmet a neten még telepítsek meg állítgassakHuh elnézést a dühkitörésért.
-
-
BoB
veterán
válasz
_Dumber_ #20197 üzenetére
Nem tudom hogy jól értem-e de nekem az jött le hogy a GRUB helyreállítási kísérlet után inkább újratelepítette az Ubuntu-t. Ha így volt azért nem lett jó mert egyéni partícionálást választott ahol meg kellett volna jelölni az EFI partíciót amit nem tett meg.
Szóval sztem neki egyszerűbb ha - megint
- újratelepíti mert nagyon kevés idő, és a egyéni cuccnál megjelöli. És ennyi.
Egéybként beszélj nyugodtan
-
hódmaci
senior tag
válasz
_Dumber_ #20190 üzenetére
Nincs rajta semmi ertekes torolheto minden.
Kozben vegigzongoraztam megint
ubuntu@ubuntu:~$ sudo parted -l
Model: ATA HGST HTS725032A7 (scsi)
Disk /dev/sda: 320GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 106MB 105MB fat32 EFI system partition boot
2 106MB 240MB 134MB Microsoft reserved partition msftres
3 240MB 158GB 157GB ntfs Basic data partition msftdata
4 158GB 162GB 4096MB linux-swap(v1)
5 162GB 320GB 158GB ext4
Warning: /dev/sdb contains GPT signatures, indicating that it has a GPT table.
However, it does not have a valid fake msdos partition table, as it should.
Perhaps it was corrupted -- possibly by a program that doesn't understand GPT
partition tables. Or perhaps you deleted the GPT table, and are now using an
msdos partition table. Is this a GPT partition table?
Yes/No? no
ubuntu@ubuntu:~$ sudo mount /dev/sda5 /mnt
ubuntu@ubuntu:~$ sudo su
root@ubuntu:/home/ubuntu# mount --bind /dev /mnt/dev
root@ubuntu:/home/ubuntu# mount --bind /proc /mnt/proc
root@ubuntu:/home/ubuntu# chroot /mnt
root@ubuntu:/# grub-install /dev/sda
Installing for i386-pc platform.
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
root@ubuntu:/# exit
exit
root@ubuntu:/home/ubuntu# umount /mnt/proc
root@ubuntu:/home/ubuntu# umount /mnt/dev
root@ubuntu:/home/ubuntu# umount /mnt
root@ubuntu:/home/ubuntu#
root@ubuntu:/home/ubuntu#
root@ubuntu:/home/ubuntu# sudo update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of `/cow'.
root@ubuntu:/home/ubuntu#
Új hozzászólás Aktív témák
- Okosóra és okoskiegészítő topik
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Formula-1
- Honor 400 - és mégis mozog a kép
- A fociról könnyedén, egy baráti társaságban
- Gurulunk, WAZE?!
- Nagyrobogósok baráti topikja
- Mozgásban a METAL GEAR SOLID Δ: SNAKE EATER
- ASZTALI GÉP / ALKATRÉSZ beárazás
- AMD Navi Radeon™ RX 9xxx sorozat
- További aktív témák...
- Assassin's Creed Shadows Collector's Edition PC
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Xiaomi Redmi Note 11 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! Fujitsu LifeBook U727 - i3-7GEN I 16GB I 256SSD I 12,5" FHD I Cam I W11 I Garancia!
- ÚJ- Lenovo ThinkVision T24i-10 - 24" monitor - Számla, garancia
- BESZÁMÍTÁS! Asus B760M i7 12700KF 32GB DDR4 512GB SSD RX 6800 16GB Rampage SHIVA FSP 700W
- LG 55G4 - 55" OLED evo - 4K 144Hz & 0.1ms - MLA Plus - 3000 Nits - NVIDIA G-Sync - FreeSync Premium
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest