2022. november 28., hétfő

Gyorskeresés

Telepítsünk disztrót egy futó rendszerre kizárólag SSH alól!

Írta: | Kulcsszavak: rescue . OS . Fedora . Debian . takeover.sh . ssh . vnc . qemu . raid . sysadmin . linux

[ ÚJ BEJEGYZÉS ]

Esetemben adott volt egy bare metal dedikált szerver hosting, ami nagyon kedvező feltételek mellett megkeresett, hogy szívesen tehermentesítené a tárcámat egy közösségi projektem hostolása kapcsán. Ez a lehetőség kapóra jött, mivel pont kerestem egy barátibb konfigot CI szervernek. Igen ám, de ahogy minden túl kecsegtető ajánlat, ez is hordozott magában egy kis csavart. Az elmúlt évek során a Debian/Ubuntu szerverek iránti imádatom átvándorolt a Fedora Server felé, így egyértelmű volt, hogy a leendő szerveren is Fedora fog futni.

Ám a hosting oldalát jobban áttanulmányozva nincs sehol lehetőség egyedi lemezképről telepíteni a vasat, az elérhető operációs rendszereik közt pedig sajnos a Debiantól a CentOS-on át a Windows Server 2019-ig minden volt, csak Fedora nem. Ami persze érthető, a legtöbb szervert bérlő cég (sajnos) nem a friss csomagokkal rendelkező és alaposan felkonfigurált, SELinuxos Fedorát fogja választani, hanem az ősrégi csomagokkal megáldott Debiant... :W

Ilyenkor szoktam a B tervhez folyamodni, az összes hosting, amivel eddig dolgom volt biztosított egy rescue debian rendszert, ami RAM-ból fut. Ez azért jön kapóra, mert nem használja a diszkeket egyáltalán, amik így újraírhatóak teljesen, ha valamilyen úton-módon betölthető a Fedora telepítő. Ezt én a következő módon szoktam megtenni (példámban Fedora ISO-t bootolunk, de mással is működhet a dolog):

Letöltjük a kívánt lemezképet, mehet bárhova, ahol elfér:

wget https://download.fedoraproject.org/pub/fedora/linux/releases/32/Server/x86_64/iso/Fedora-Server-dvd-x86_64-32-1.6.iso -O lemezkep.iso

Aztán a trükk, hogy indítok egy qemu kvm virtualizált gépet, aminek felcsatolom mindkét SSD-m (ide fogjuk írni az operációs rendszert), a telepítő lemezképet, illetve megadok neki kellő mennyiségű RAM-ot és egy VNC elérést, amelyre később még szükség lesz:

apt update && apt install qemu-system-x86

qemu-system-x86_64 -net nic -net user -m 2048M -enable-kvm -cpu kvm64,+nx -smp 2 -device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 -k en-us -cdrom lemezkep.iso -drive file=/dev/sda,format=raw -drive file=/dev/sdb,format=raw -vnc 127.0.0.1:0 -boot d

A parancsot ízlés szerint lehet paraméterezni, nem Szentírás. Iránymutatás céljából van beszúrva. :)

Majd egy SSH port forwarddal a távoli SSH hoszton egyszerűen elérhető az 5900-as porton futó VNC session, amit egy tetszés szerint választott VNC klienssel bátran elérhetünk a localhost:5900 címen. Innentől pedig a telepítő bebootol, és elindul a normál telepítési folyamat. A korábban hozzáadott SSD-k kiválaszthatóak és egész nyugodtan felülírhatóak. A telepítési folyamat végeztével pedig bátran ki lehet lépni a telepítőből, be lehet zárni a VNC klienst és Ctrl+C-vel ki lehet lépni a qemu folyamatból is. Majd visszatérve a rescue Debian shellbe, egy reboot parancsot követően már az újonnan telepített OS-nak kell, hogy induljon.

Ez volt az elképzelés és tucatszor csináltam már ilyet. Sikerült is találni egy rescue Debiant a korábban említett hosting oldalán, de elakadtam. Ugyanis a qemu csak és kizárólag akkor működhet használható sebességgel, ha be van töltve a kernelbe a kvm modul. Viszont a host letiltotta a külső modulok támogatását, azaz esélytelennek tűnt a KVM boot. Ezek mellett nem is ramból futott, hanem egy read-only csatolás volt, 0 üres hellyel. A helyproblémát természetesen tucatnyi bindmounttal, vagy egy tmpfs-be tett írható chroottal ki lehetett volna küszöbölni, de mindezt minek, ha nem tudom a telepítőt elindítani.

Így a rescue mód lehetőségét kilőttem. Gondolkoztam sokat, hogy hogyan lehetne a helyzetemben megoldást találni. Adott 16 GB RAM, 2*480GB SSD RAID1-ben, amire telepíthetek Debiant, CentOS-t, Ubuntut. Az kizárt, hogy én bármit is netbootoljak, hiszen a host ad VNC elérést, de a bios-ra nincs rálátásom, PXE-t pedig csak úgy nem tudok bootolni. Bár privát hálózatot lehet létrehozni, a DNS szerver mindig a hostingé lesz, tehát a netboot ténylegesen esélytelen. Telepíthetnék mondjuk egy Ubuntut, SSH-n belépve letölthetném a Fedora lemezképet, szerezhetnék egy vmlinuz és initrd fájlt, majd egy extra grub configgal bootolhatnám a telepítőt, hiszen van VNC hozzáférésem és a grub bootot meg tudom már állítani. Az ISO pedig betölthető teljesen a RAM-ba, így az SSD-k felülírhatók. Ez a megoldás jónak is hangzott, viszont a VNC-n keresztüli telepítés nem volt éppen sikeres, mivel egér támogatás nincs és kényelmetlen lett volna a telepítés több perifériából fakadó egyéb hiba miatt.

Utólag eszembe jutott egy másik lehetséges út is, amit sajnos nem sikerült tesztelnem, de talán járható. Ebben az esetben kihasználnám, hogy RAID1-ben van 2 SSD-m a futó rendszer alatt. Debian fel a dedikált szerverre, majd apt install mdadm. Következhet egy rövid rátekintés a tömbökre a cat /proc/mdstat paranccsal, aztán lecsatolom az egyik szabadon választott array membert egy szimpla mdadm --fail /dev/sdxy paranccsal. A Debianom ettől még elvileg működőképes, tehát mehet neki a fentebb ecsetelt módon a qemu-s telepítés, annyi különbséggel, hogy itt csak 1 diszkkel, hiszen a Debiant még nem tudom felülírni. Viszont amiikor a telepítő lehetőséget ad rá, akkor a / partíciót RAID1-ként adom meg, egyelőre 1 db lemezzel. Majd a Debianba visszalépve a grub konfigot át tudom írni, hogy bootoljon a most készült Fedora-s partícióról, ahonnan boot után hozzá tudom adni a másik lemezt is az eddig egyszemélyes RAID1 "tömbömhöz".

De utólag okos az ember! Valószínűleg a legutóbbi megoldás sikerrel járhatott volna, csak nem jutott eszembe. :W Így maradt az eredeti elképzelés. Valahogy el kell érnem, hogy az OS a RAM-ban legyen, mindezt egy már SSD-ről bebootolt, futó rendszerből.

És akkor jöjjön a lényegi rész, a ténylegesen működő megoldás!

Egy rendszergazda barátom linkelte annak idején a takeover.sh nevű projektet, amely pontosan azt ígéri, amire nekem szükségem van. Egy bármilyen futó rendszert képes teljesen lecsatolni (természetesen a kernel megtartásával), majd egy RAM-ba töltött fájlrendszert indítani helyette. Ígéretes, de nem tűnt valami bőbeszédűnek a leírás és tele volt mindent saját felelősségre figyelmeztetéssel a Github oldal. :D Viszont ez a megoldás kivitelezhetőnek hangzott.

Tehát el is kezdtem a dedikált szerver telepítését. Kezdeti operációs rendszernek elvileg bármely telinit-et támogató linux disztribúció megtette volna, de az elsőként választott Ubuntum pont nem akart működni a telinit szkripttel (csak a 20.04 nem támogatja, a 18.04 még jó), így a végső választás a Debianra esett. Felment, a host megküldte az SSH belépési adatokat, sikerült is a belépés root SSH-n.

Tehát akkor szokásos friss Debian alatti package cache helyretevős parancsok:

apt update && apt upgrade -y

Majd el kell döntenünk, hogy tulajdonképpen mit szeretnénk a RAM-ba tölteni. Nekem a választásom a Debianra esett, ha már Debiant bootoltunk. Szerencsére van olyan lemezképe, amit kicsomagolva tudunk chrootként is használni. De első körben derítsük ki, hanyas Debian fut a vason, hanyasat érdemes letölteni:

root@localhost:~# cat /etc/os-release | grep VERSION
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster

10-es buster Debian. Akkor keressük ki a megfelelő standard iso-t innen, hiszen ez a legfrissebb a cikk írása pillanatában: [link]

Meg is van a direkt link:

https://cdimage.debian.org/mirror/cdimage/release/current-live/amd64/iso-hybrid/debian-live-10.4.0-amd64-standard.iso

Töltsük is le a szerverre, majd csatoljuk fel:

cd ~ && wget https://cdimage.debian.org/mirror/cdimage/release/current-live/amd64/iso-hybrid/debian-live-10.4.0-amd64-standard.iso -O lemezkep.iso && mount lemezkep.iso /mnt

Ezután célszerű körülnézni a csatolásban:

root@localhost:~# ls /mnt/
boot d-i dists EFI isolinux live pool
root@localhost:~# ls /mnt/live/
config-4.19.0-9-amd64 initrd.img-4.19.0-9-amd64 vmlinuz-4.19.0-9-amd64
filesystem.squashfs System.map-4.19.0-9-amd64
root@localhost:~# du -sh /mnt/live/filesystem.squashfs
611M /mnt/live/filesystem.squashfs

Meg is van, amit kerestünk, a filesystem.squashfs fogja tartalmazni a számunkra szükséges Debian fájlrendszert. Most hozzunk létre egy mappát, ahova ki szeretnénk csomagolni:

mkdir /takeover

Csatoljunk rá egy tmpfs-t, hiszen a továbbiakban RAM-ban szeretnénk a fájlrendszert tárolni. Majd ellenőrizzük a méretét. Én 8 GB-ot adok neki, hiszen a következőekben kicsomagolt Debian jócskán felemészt majd 2 GB-ot, és majd a végleges ~3 GB méretű Fedora lemezképet is tárolni kell valahol. Mivel RAM van bőven, a 8 GB elégnek hangzik.:

root@localhost:~# mount -t tmpfs tmpfs /takeover -o size=8G
root@localhost:~# df -h /takeover
Filesystem Size Used Avail Use% Mounted on
tmpfs 8.0G 0 8.0G 0% /takeover

Most tegyük fel a squashfs-tools csomagot:

apt install squashfs-tools

És bontsuk ki a Debian fájlrendszert a /takeover mappába:

root@localhost:~# cd /takeover && unsquashfs -d ./ -f /mnt/live/filesystem.squashfs
Parallel unsquashfs: Using 24 processors
73619 inodes (80450 blocks) to write

[===========================================================\] 80450/80450 100%

created 64457 files
created 7687 directories
created 8637 symlinks
created 8 devices
created 0 fifos
root@localhost:/takeover# ls
bin etc initrd.img.old lib64 mnt root srv usr vmlinuz.old
boot home lib libx32 opt run sys var
dev initrd.img lib32 media proc sbin tmp vmlinuz

Csatoljuk le a Debian lemezt a /mnt elérési útról:

umount /mnt

Eddig minden rendben ment. :C A szkript leírása ezen a ponton javaslatot tesz a /lib/modules teljes eltávolítására, hiszen erre nem lesz szükség és sok helyet foglal (ha idegen kernelre van a modul, azaz a magic number nem egyezik, akkor be se fog töltődni, nekünk pedig mindvégig a host által eredetileg adott Debian kernelünk van betöltve, tehát a RAM-os rendszer moduljaival nem tudunk mit kezdeni):

rm -rf /takeover/lib/modules/*

Egy pillanat erejéig lépjünk be a kicsomagolt fájlrendszerre, hogy megbizonyosodhassunk, a dolog tényleg működőképes:

root@localhost:/takeover# chroot /takeover
root@localhost:/# exit
exit
root@localhost:/takeover#

Remek, ez is megvan! Lépjünk vissza a chrootba (nem is kötelező az előző lépésben kilépni), tegyünk fel SSH-t, hogy később be tudjunk lépni az új rendszerre (a parancsok soronként, egyesével lettek kiadva):

chroot /takeover
dhclient
apt update
apt install openssh-server -y
mkdir /run/sshd
sed -i s"|#PermitRootLogin prohibit-password|PermitRootLogin yes|" /etc/ssh/sshd_config
exit

Ezzel fent lesz az SSH a RAM rendszeren is és remélhetőleg majd működni is fog. Most, ahogy a takeover.sh leírás javasolja, töltsünk le egy megfelelő busybox binárist, innen: [link]

wget https://www.busybox.net/downloads/binaries/1.26.2-defconfig-multiarch/busybox-x86_64 -O /takeover/busybox && chmod +x /takeover/busybox

A következő feladat a takeover.sh letöltése, amit a következő parancsok sorban kiadásával lehet megtenni:

cd /takeover
apt install git -y
git clone https://github.com/marcan/takeover.sh ./takeover
mv ./takeover/* ./
mv ./takeover/.* ./
rm ./takeover/ -rf

A következő lépésben eltérek a takeover által javasolt úttól, ugyanis a takeover működéséhez le kell fordítani a fakeinit.c fájlt, amihez ők a gcc chrooton belüli használatát javasolják, hogy biztosan kompatibilis legyen a lefordított bináris a kívánt RAM-ból futó rendszerrel. Mivel a gcc nincs telepítve Debianra alapból és csak értékes RAM-ot rabolnék el magamtól, illetve pontosan tudom, hogy Debian 10 x64-ről fordítok Debian 10 x64-re, ezért elméletben nem kell aggódnom, a host is megfelel.

Tehát adjuk ki ismét sorban:

cd /takeover
apt install gcc -y
gcc fakeinit.c -o fakeinit -static

Végezetül adjuk ki a következő parancsot, ami szerkeszti magát a takeover.sh-t. Sajnos Debian host alatt erre mindenképpen szükség van a sikeres tty átirányítás miatt:

sed -i 's|^./busybox mount -t devpts devpts dev/pts|./busybox mount --bind /dev/pts dev/pts|' /takeover/takeover.sh

És kész is vagyunk, indulhat a szkript futtatása:

root@localhost:/takeover# sh /takeover/takeover.sh
Please set a root password for sshd
New password:
Retype new password:
passwd: password updated successfully
Setting up target filesystem...
Mounting pseudo-filesystems...
Checking and switching TTY...
Type 'OK' to continue
> OK
Preparing init...
Starting secondary sshd
ssh-keygen: generating new host keys: DSA
You should SSH into the secondary sshd now.
Type OK to continue
>

Remélhetőleg eddig a pontig semmi nem szorul magyarázatra, de ahogy a szkript is írja, itt mindenképp célszerű csatlakozni az új SSH-ra. Az IP ugyanaz, viszont a másodlagos SSH a 80-as porton fog futni. A felhasználónév root, a jelszó pedig amit a szkript első promptjában megadtunk.

You should SSH into the secondary sshd now.
Type OK to continue
> OK
About to take over init. This script will now pause for a few seconds.
If the takeover was successful, you will see output from the new init.
You may then kill the remnants of this session and any remaining
processes from your new SSH session, and umount the old root filesystem.
Init takeover successful
Pivoting root...
Chrooting and running init...

root@localhost:/takeover#

Innentől kezdve a régi SSH-ra nincs is szükség. Remek. Sikerrel járt a folyamat! :C Zárjuk is be a régit.

root@localhost:~# ls /
LICENSE dev initrd.img libx32 proc sys vmlinuz
README.md etc initrd.img.old media root takeover.sh vmlinuz.old
bin fakeinit lib mnt run tmp
boot fakeinit.c lib32 old_root sbin usr
busybox home lib64 opt srv var
root@localhost:~# ls /old_root/
bin home lib64 opt sbin tmp vmlinuz.old
boot initrd.img lost+found proc srv usr
dev initrd.img.old media root sys var
etc lib mnt run takeover vmlinuz

Látható, hogy az új SSH rendszere a RAM-ból fut. Ha szükséges a későbbiekben debuggoláshoz stb és van elég szabad hely, akkor a /run/modules átmásolható a régi rendszerről, de ez a lépés teljesen opcionális:

cp -ar /old_root/run/modules /run

Nekem nem lesz szükségem a modulokra, hiszen a kvm már be van töltve, más modulra pedig nincs és nem is lesz vélhetően szükséges:

root@localhost:~# lsmod | grep kvm
kvm_intel 233472 0
kvm 749568 1 kvm_intel
irqbypass 16384 1 kvm

Rendben, most lőjük ki elsőként a megmaradt régi SSH szervert:

root@localhost:~# lsof -i | grep ssh
sshd 678 root 3u IPv4 19650 0t0 TCP *:ssh (LISTEN)
sshd 678 root 4u IPv6 19652 0t0 TCP *:ssh (LISTEN)

Nekem a 678-as porton fut, így azt fogom kilőni:

kill -9 678

Végezetül szaladjunk át az összes folyamaton, amit az lsof kilistáz és lőjük ki hasonlóan a régi SSH-hoz:

kill -9 `lsof -t +D /old_root`

A lényeg, hogy a végére ne maradjon futó folyamat, amely igénybe venné a diszket:

root@localhost:~# lsof /old_root
root@localhost:~#

Most elvileg semmilyen folyamat nem használja a diszket már, viszont maradt nekünk a RAID1 tömbünk, amit még szét kell szedni, illetve egy meglepetés LVM konfig is:

root@localhost:~# fdisk -l | grep sectors | grep Disk
Disk /dev/sda: 447.1 GiB, 480103981056 bytes, 937703088 sectors
Disk /dev/sdb: 447.1 GiB, 480103981056 bytes, 937703088 sectors
Disk /dev/md2: 28 GiB, 29996482560 bytes, 58586880 sectors
Disk /dev/md4: 409.9 GiB, 440102879232 bytes, 859575936 sectors
Disk /dev/mapper/vg00-usr: 10 GiB, 10737418240 bytes, 20971520 sectors
Disk /dev/mapper/vg00-var: 10 GiB, 10737418240 bytes, 20971520 sectors
Disk /dev/mapper/vg00-home: 10 GiB, 10737418240 bytes, 20971520 sectors

Ellenőrizzük, hogy van-e swap felcsatolva a rendszeren:

root@localhost:~# free -h
total used free shared buff/cache available
Mem: 15Gi 181Mi 12Gi 2.0Gi 2.9Gi 13Gi
Swap: 18Gi 0B 18Gi

Esetemben van, tehát csatoljuk le:

swapoff -a

Mindenekelőtt csatoljuk le a régi rootot:

umount -R /old_root

Ez a lépés valószínűleg el fog térni, host és Debian telepítő specifikus, az én hostom LVM-et is alkalmazott. Így ezt kell eltávolítani először, majd mehet a RAID szétszedés is:

apt install lvm2 -y
lvremove /dev/mapper/vg00-usr
lvremove /dev/mapper/vg00-var
lvremove /dev/mapper/vg00-home

Szedjük szét a RAID tömböt:

apt install mdadm -y
mdadm --stop --scan

Ellenőrizzük a sikerességét:

root@localhost:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>

Nincs itt semmi, így sikerrel jártunk! :) Kezdődhet a tényleges OS telepítés!

Töltsük le a telepítőt mondjuk a root home könyvtárába:

wget https://download.fedoraproject.org/pub/fedora/linux/releases/32/Server/x86_64/iso/Fedora-Server-dvd-x86_64-32-1.6.iso -O lemezkep.iso

Majd futtassuk le a cikk elején említett két parancsot, de előtte győződjünk meg arról, hogy nyitottunk egy SSH port forwardot az 5900-as portra:

apt update && apt install qemu-system-x86

qemu-system-x86_64 -net nic -net user -m 2048M -enable-kvm -cpu kvm64,+nx -smp 2 -device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 -k en-us -cdrom lemezkep.iso -drive file=/dev/sda,format=raw -drive file=/dev/sdb,format=raw -vnc 127.0.0.1:0 -boot d

Majd egy tetszés szerint választott VNC klienssel (én a VNC Viewer-t tudom ajánlani, vagy a Remmina-t) lépjünk be a localhost:5900 VNC szerverre, ahol már fogad is a telepítő. Esetemben valahogy így:

A telepítés innentől kizárólag rajtatok áll és semmiben nem különbözik egy hagyományos CD-s telepítéstől, kivéve hogy VNC-n keresztül zajlik. Ha kész, lépjünk ki a telepítőből, illetve a qemu folyamatból Ctrl+C-vel, majd indítsuk újra a masinát:

sync
reboot -f

És az új rendszer fog várhatóan elindulni. :)

Megjegyzés magamnak: Ha a Fedora telepítése a bootloader telepítésnél ismeretlen hibával elhasal, az valószínűleg azért van, mert mindkét lemezen szükség van a boot partíció meglétére.

És ennyi lenne. Kérdéseket, kommenteket, kioktatást szívesen fogadok hozzászólások formájában! :) Kellemes konfigolást kívánok!

Belevágni a projektbe kizárólag saját felelősségére érdemes és egy olyan rendszeren, ahol van fizikai hozzáférés/OS újratelepítési lehetőség biztosított, arra az esetre, ha valami balul sülne el!

Készült: 2020. 07. 15, Szerda

Hozzászólások

(#1) adika4444


adika4444
addikt

Hali!

Nagyon jó cikk!

Miért a Fedora? Miért jó, ha ennyire gyorsan pörög? Utánaolvastam kicsit, 13 hónapos támogatás, és 6 hónapos megjelenési ciklus.

A Debian-ban én pont azt szeretem, hogy stabil mint a beton, a buster-érában egyre több backport-olt szoftver érhető el, Docker-rel pedig bármiből tudom futtatni a legfrissebbet, vagy ha nem úgy akarom, akkor is le tudom fordítani konténerben, hogy ne szemeteljem szét a host gépet.

Az Ubuntu-t is pont emiatt kerülöm, mert tartok tőle, hogy a gyorsabb pörgés miatt nem várt anomáliák jelentkezhetnek.

üdv, adika4444

(#2) Mr Dini válasza adika4444 (#1) üzenetére


Mr Dini
addikt

Szia!

A cikk írásával nem volt célom disztró háborút kirobbantani, szerintem szubjektív kinek mire van szüksége.

Az én váltásomnak szerver oldalon több oka van:

1.) Szintén sok minden konténerben fut nálam is, de van, amit kénytelen vagyok a host OS-on is frissen tartani, pl. Python. Megelégeltem, hogy a Debian még a 3.5-nél járt, amikor már rég volt 3.7.9 is. Persze a saját fordítás/PPA működhet, de azzal is akadtak kényelmetlenségek, pl. ha egy függőség könyvtárat frissítettem, akkor le kellett vagy 8 csomagot újból fordítani. Még a repókban ezek automatizálva vannak. Ok, hogy Debianba is megy backport, de nem igazán kerülnek bele új funkciók, inkább security update-ek.
2.) A Fedora a RHEL "teszt buildje" mindig, ezáltal igen aktívan van fejlesztve és a közösség is nagyon aktív mögötte = van community support.
3.) Nagyon tetszik a Fedora féle yum csomagkezelő, soha nem akadt még be nekem, míg az apt esetében volt olyan, hogy olyan szinten kiakadt egy rossz csomag telepítése után, hogy le akarta töröltetni velem a teljes grafikai környezetet. :D
4.) Mindig friss kernel. Ez számomra "crucial". Docker helyett podman-t használok, ami teljes mértékben userspace, nem is feltétlenül szükséges root a futtatáshoz, így minden konténerem teljesen rootless módon fut a hoszton, ráadásul Docker API kompatibilis. Viszont a fájlrendszerekhez fuse csatolásokat használ, amiben nemrég pusholtak rengeteg optimalizációt, talán az 5.4-es kernel verziónál. Érezhető a különbség. :)
5.) Amikor felrakod az OS-t, az egy eleve élő tűzfal konfigurációval és SELinux-szal jön. Eleinte féltem az utóbbitól, de egész hozzászoktam mára. Számomra ez egy hatalmas plusz.

Azon kívül kb akkor váltottam, mikor a Fedora 29 volt porondon, most 32 csücsül az összes vasomon, minden beton stabilan működik, egyszer nem volt semmivel sem gondom. Cserébe friss is a rendszer.

Sose köss bele az antikvitásba!

(#3) hcl


hcl
félisten
LOGOUT blog

Ez is ügyes volt :)
Én egy dd-s imaget toltam volna fel egy előre telepített rendszerről... Bár annak is lehet 5000 buktatója.

Illetve, Fedor telepítő is bootolható hálóról (vagy a szerver nem?), az is érdekes lett volna, hogy a rescue Debian loaderével behúzni a hálós Fedora települőt :D

Veszek _hibás_ LCD monitort,fényképezőgépet, objektívet, routert ---- Mutogatni való hater díszpinty

(#4) Mr Dini válasza hcl (#3) üzenetére


Mr Dini
addikt

A dd nem rossz ötlet, csak akkor kellett volna repartitioning gondolom. Így meg a grafikus telepítővel egyenesen úgy került fel minden, ahogy lennie kell :).

Netbootot viszont így elsőre nem értem. Azt hogy oldottad volna meg? Hoszting oldalon annyi van, hogy van egy chechbox, hogy "restart in rescue shell", ami valami flaget állít, hogy az ő PXE szerverükről induljon a vas, ne a diszkekről. Mivel ahhoz a PXE szerverhez nincs hozzáférésem, nincs ötletem mire gondolsz.

Sose köss bele az antikvitásba!

(#5) hcl válasza Mr Dini (#4) üzenetére


hcl
félisten
LOGOUT blog

Ha a GRUB-ot látod a rescue-ben, akkor talán valahogyan be lehet hackelni, hogy bebootolja a hálós telepítőt, hasonlóan az ittenihez.
Bár sosenem néztem utána, de hátha.

Veszek _hibás_ LCD monitort,fényképezőgépet, objektívet, routert ---- Mutogatni való hater díszpinty

(#6) Mr Dini válasza hcl (#5) üzenetére


Mr Dini
addikt

Oh, ez hasonló ahhoz az elképzeléshez, amit a cikkben is említettem. Csak én az initrd-t és vmlinuz-t az SSD-re rakom, amikor még megy az eredetileg telepített Debian/Ubuntu, aztán reboot, grub intercept és betöltöm ezeket a fájlokat a RAM-ba. Még net se kell hozzá. A gond ezzel az, hogy a hoszting által adott VNC elérés nem igazi VNC, hanem egy webes valami és nincs egér támogatás, illetve csak betűket és számokat lehet beírni. Most belegondolva bootolhattam volna egy Debian rendszert NFS csatolásról is viszont, amibe rakhattam volna egy előre megírt szkriptet és telepíthettem volna úgy. De ahhoz custom debian kernelt kellett volna forgatnom, ami tud netbootot.

[ Szerkesztve ]

Sose köss bele az antikvitásba!

(#7) hcl válasza Mr Dini (#6) üzenetére


hcl
félisten
LOGOUT blog

Mondjuk amiket én "Centos"'-t bootoltattam hálóról, azt iPXE-vel csináltam, de mintha be lehetne húzni GRUB-ból iPXE-t is, és ha be lehet, akkor onnan már sétagalopp.

Veszek _hibás_ LCD monitort,fényképezőgépet, objektívet, routert ---- Mutogatni való hater díszpinty

(#8) adika4444 válasza Mr Dini (#2) üzenetére


adika4444
addikt

Köszi a részletes választ!:)

üdv, adika4444

További hozzászólások megtekintése...
Copyright © 2000-2022 PROHARDVER Informatikai Kft.