тръгна гадината , грешката е предизвикана от разминаване между .buildstamp-те в initrd и netstg2.img

Изглежда ще е бъг във верися на anaconda която е билдната в дистрибуцията на ESX

https://bugzilla.redhat.com/show_bug.cgi?id=243528

ако знаех какво точно правя за да не стане щеше до сега съм си ясяснил цялата картинка

както писах по-нагоре, целият път на конфигуриране e изтестван с RHEL и кs install-a минава успешно. Проблема е че при ESX има неква болка с stage файловете, макар че ги открива , не зная на какво се дължи

мъката е с classic ESX, не с embedded ESXi 

Здравейте,

мъча се да организирам някакво решение за деплой на множество автоматични инсталации на VMware ESX server чрез PXE. Конфигурацията(DHCP+TFTP) e сетната коректно, изпробвана е чрез kickstart scripted install на  RHЕL5 през NFS/HTTP/FTP. За целта на source install server-a е mount-то ISO с инсталацията към NFS share /HTTP/FTP. Трика обаче не се случва с ESX ,който за основа ползва RHEL3 и anaconda като инсталатор с няколко допълнителни екстри. След успешен boot през PXE зарежда ks-a(HTTP install) но при стъпка source install връща "Unable to retrive Vmware/base/netstg2.img  The installation tree in that directory does not seem to match your boot media", изглежда анакондата не успява да си открие stage img-те. При ръчно задаване на source install през инсталатора грешката е същата. Ресурса е достъпен през HTTP и stage файловете са точно там където е описано и са достъпни.Аналогична е случката и през FTP/NFS.


Anaconda log during install:

......
transfering http://10.23.68.93/ESX35/VMware/base/updates.img to a fd
transfering http://10.23.68.93/ESX35/VMware/disk1/base/updates.img to a fd
transfering http://10.23.68.93/ESX35/VMware/base/product.img to a fd
transfering http://10.23.68.93/ESX35/VMware/disk1/base/product.img to a fd
transfering http://10.23.68.93/ESX35/VMware/base/netstg2.img to a fd
transfering http://10.23.68.93/ESX35/VMware/disk1/base/netstg2.img to a fd
copied 12382208 bytes to /tmp/ramfs/netstg2.img (complete)
mntloop loop0 on /mnt/runtime as /tmp/ramfs/netstg2.img fd is 28

httpd access.log:

10.23.85.203 - - [05/Mar/2009:09:25:10 -0500] "GET /ESX35/VMware/base/product.img HTTP/1.0" 404 303 "-" "-"
10.23.85.203 - - [05/Mar/2009:09:25:10 -0500] "GET /ESX35/disc1/VMware/base/product.img HTTP/1.0" 404 309 "-" "-"
10.23.85.203 - - [05/Mar/2009:09:25:10 -0500] "GET /ESX35/VMware/base/netstg2.img HTTP/1.0" 200 12382208 "-" "-"

httpd error.log:

[Thu Mar 05 09:24:48 2009] [error] [client 10.23.85.203] File does not exist: /var/www/html/ESX35/VMware/base/product.img
[Thu Mar 05 09:24:48 2009] [error] [client 10.23.85.203] File does not exist: /var/www/html/ESX35/disc1
[Thu Mar 05 09:25:10 2009] [error] [client 10.23.85.203] File does not exist: /var/www/html/ESX35/VMware/base/updates.img
[Thu Mar 05 09:25:10 2009] [error] [client 10.23.85.203] File does not exist: /var/www/html/ESX35/disc1
[Thu Mar 05 09:25:10 2009] [error] [client 10.23.85.203] File does not exist: /var/www/html/ESX35/VMware/base/product.img
[Thu Mar 05 09:25:10 2009] [error] [client 10.23.85.203] File does not exist: /var/www/html/ESX35/disc1

мдааа бройм го за user error , при сетване на RAID1 member partitions от fd към ext3 след reboot :

EXT3-fs: unable to read superblock
mount : error mounting /dev/root on /sysroot as ext3: Invalid argument
......


kernel panic

tldp :

Autodetection allows the RAID devices to be automatically recognized by the kernel at boot-time, right after the ordinary partition detection is done.

This requires several things:

   1. You need autodetection support in the kernel. Check this
   2. You must have created the RAID devices using persistent-superblock
   3. The partition-types of the devices used in the RAID must be set to 0xFD (use fdisk and set the type to "fd")

айде със здраве

такам, според  tldp за да може кернела по време на boot да разпознае автоматично всички устройства които са сетнати в md (RAID) device трябва partition-ите да са от  тип fd (raid autodetect).

понеже винаги ме чопли да "човъркам" , смених partition-те от fd на еxt3 на на два участника в RAID(1) и проблем нямаше след boot. До колкото разбирам леяра на който работи md driver-a се абстрахира от типа партишъни на участниците, т.е възможно е да комбинираш партишъни от различни файлови системи в един райд. И тук изниква въпроса каква ще е разликата ако изградиш райд от няколко партишъни с вече изградена файлова система и такъв при който изграждаш файлова система върху md device.

напълно фунционален си е

Здравейте,

разяснете каква точно е идеята при създаване на софтуерен раид партишъните участници да бъдат с индентификатор fd, малкото информация която открих е че при боот процеса за успешен аутодетек на раид девайсите партишъните трябва да са сетнати точно така. Пробвах да променя от fd на ext3 /boot partition и системата нямаше проблем да зареди.

инфото от tux е че ще бъдат вероятно ноеври по време на Openfest. Нов Български провеждали изпити но не е проверено още

направих си труда да разгледам сайта на lpi-bg, за 2008-ма няма инфо, също чакам отговор от LPI, но уви за сега няма такъв. Сайта на Webtech също не работи.

здравейте,

имате ли информация кога, къде, как ще се провеждат LPI и SAIR сертификационни изпити през 2008

здравейте,

имате ли информация кога, къде, как ще се провеждат LPI и SAIR сертификационни изпити през 2008

printf "\x2E" | dd bs=1 seek=112 of=/dev/port
printf "\xFF" | dd bs=1 seek=113 of=/dev/port

можело през /dev/port

оказа се че tool-те за linux от AMI са платени , писах им