Van egy OpenBSD 7.1 amd64 telepítésem. Jó ötletnek tűnt egy mindent egybe "/" partíció létrehozása, így most van:
- sd3a: 200GB "/"
- sd3b: 24GB "swap"
Jön is boot során a hibaüzenet:
open(hd3a:/etc/boot.conf): Unknown error: code 20
Szerencsére default beállításokkal továbbmegy, viszont így a boot beállításaimnak lőttek. Megtaláltam a hibát, az OpenBSD boot során a root partíció első 1024 cylinderét tudja olvasni, amin én a 200 GB root partíciómmal szépen túllőttem. Szerencsére határon belől van még a kernel, így azt be tudja tölteni, de olvastam olyat is, akinek már az is kívül esett (vagy csak egy része) és ott vége is a boot folyamatnak. Feltételezem, a szerencsén múlik hogy még bootolni tudok, idővel (kernelfrissítés, sysupgrade) kívül esik majd a kernel is és akkor vége.
Újratelepítésen és megfelelő partícionáláson kívül, hogyan tudnám ezt javítani?
Olvasgatva az OpenBSD boot folyamata így néz ki:
- Master Boot Record (MBR) and GUID Partition Table (GPT). The fdisk(8) man page contains the details.
- Partition Boot Record (PBR). The first 512 bytes of the boot disk's OpenBSD partition contain the first stage boot loader biosboot(8). It is installed by the installboot(8) utility.
- Second stage boot loader
/boot
. The PBR loads the boot(8) program which has the task of locating and loading the kernel.
Using drive 0, partition 3. <- MBR
Loading...... <- PBR
probing: pc0 com0 com1 mem[638K 1918M a20=on] <- /boot
disk: hd0+ hd1+
>> OpenBSD/amd64 BOOT 3.33
boot>
booting hd0a:/bsd 4464500+838332 [58+204240+181750]=0x56cfd0
entry point at 0x100120
[ using 386464 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993 <- Kernel
The Regents of the University of California. All rights reserved.
Tehát nálam a /boot-nál van a hiba. Lehetne-e megjavítani úgy a dolgot, hogy létrehozok egy partíciót, ami belefér az 1024 cylinderbe, arra pakolom a /boot fájlt, a /etc/boot.conf-ot, meg a /bsd kernelt. A biosboot-ot az installboot-tal lehet újra telepíteni, aminek meg lehet adni, hogy hol van a root, ahol a boot-ot keresse:
-r root Specify the mount point of the root filesystem to operate on, defaulting to /.
Szóval, valami ilyesmire gondolok, hogy létrehozok egy megfelelő partíciót, ami tartalmazza:
/boot (bootloader)
/bsd (kernel)
/etc/boot.conf (bootloader configja)
majd ezt csatolom a /boot könyvtárba.
Akkor elméletben így nézne ki a boot folyamat:
- MBR megtalálja a sda3 partíciót, ahol belöki a módosított PBR-t
- A PBR a /boot/boot útvonalon indítja a Second stage boot loadert
- A Second stage boot loader tudja olvasni a /boot/etc/boot.conf-ot remélhetőleg... és indítja a kernelt: /boot/bsd
Kérdések azon kívül, hogy ez működhet-e egyáltalán:
- a boot megtalálja-e a /boot/etc/boot.conf-ot? gyanítom igen, mert ő még nem mount-ol, az ő partícióját hiszi root-nak
- van-e abból probléma, hogy a /boot/bsd alól indul a kernel, nem a /bsd alól? Megtalálja pl az /etc/fstab-ot, /sbin-t stb?
- Egyáltalán hogyan tartható ez karban? gondolok itt arra, hogy ha lesz egy sysupgrade, az felülírja-e a biosboot-ot pl? vagy első boot-kor még a régi kernel indulna a /boot/bsd vonalon, újraindítás előtt azt is frissíteni kellene...
Gyanítom, hogy nem működne ez, de hátha van valakinek valami véleménye, javaslata.
- 527 megtekintés
Hozzászólások
Azt hiszem már az elmélet is bukik itt:
A PBR a /boot/boot útvonalon indítja a Second stage boot loadert
mivel akkor még nincs mount, így azon az útvonalon semmit nem fog találni...
- A hozzászóláshoz be kell jelentkezni
Én már oldottam meg túl kicsi /boot partíció problémát live CD + gparted segítségével, de akkor eleve külön volt a /boot. Nekem gyanús az újratelepítés, esetleg a /home-t meg tudod menteni.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Jah, itt meg az a baj, hogy túl nagy, de partíciót csak növelni lehet OpenBSD alól, gparted meg nem ismeri az ffs fájlrendszert :P
Még disk klónozás, majd megfelelő partíciókra vissza másoláson gondolkozok... Persze az újratelepítéssel és újraconfigolással már végeztem volna :D
- A hozzászóláshoz be kell jelentkezni
Jó alkalom tesztelni a backup / restore megoldásodat, helyreállításkor szükséges módosításokkal kiegészítve.
--
Légy derűs, tégy mindent örömmel!
- A hozzászóláshoz be kell jelentkezni
Miért nem tud ez a program LBA-t? Az kb. harminc éves technológia.
Van például egy ilyen: https://github.com/openbsd/src/blob/master/sys/arch/amd64/stand/biosboo…
- A hozzászóláshoz be kell jelentkezni
Erre az LBA-ra nem tudok mit mondani, default telepítést használtam. A biosboot az a default "first stage boot loader" ami indítja a /boot "Second stage boot loader"-t, ami indítja a kernelt. A nyitóban a manualból beillesztettem a default boot folyamatot. A legkecsegtetőbb szerintem most az efiboot, ami a hagyományos:
MBR -> PBR-biosboot -> /boot -> /bsd (kernel)
helyett (ha jól értem):
efiboot -> /bsd (kernel)
- A hozzászóláshoz be kell jelentkezni
Igazából két kódrészletet idéztél be, az első csak egy sor, a másodikban viszont nincs benne a hibaüzenet. (Vagy nem látom.)
- A hozzászóláshoz be kell jelentkezni
Az egy sor az amit kaptam hibaüzenetet, a második csak egy példa, ahol bemutatják, hogy boot folyamat során melyik sor kitől jön. Hülyén írtam, bocs.
A hibaüzenetet én ezután kapom:
>> OpenBSD/amd64 BOOT 3.33
Fotóról gépeltem be amúgy, mert ott még nincs log sem.
- A hozzászóláshoz be kell jelentkezni
Az legalább meglett, hogy van egy lib/libsa/strerror.c, amiben az ismert errno-értékeket szöveggé fordítja, de speciel a 20 nem megy neki. Itt kellene nézelődni: sys/lib/libsa/saerrno.h
(ELAST=95)
#define EADAPT (ELAST+1) /* bad adaptor */
#define ECTLR (ELAST+2) /* bad controller */
#define EUNIT (ELAST+3) /* bad drive */
#define EPART (ELAST+4) /* bad partition */
#define ERDLAB (ELAST+5) /* can't read disk label */
#define EOFFSET (ELAST+6) /* relative seek not supported */
#define EBSE (ELAST+7) /* bad sector error */
#define EECC (ELAST+8) /* uncorrectable ecc error */
#define EHER (ELAST+9) /* hard error */
#define ESALAST (ELAST+9)
- A hozzászóláshoz be kell jelentkezni
Megint bocs, futtatom veled a felesleges köröket azt hiszem:
Unknown error: code 20 -ra ezt találtam.
- A hozzászóláshoz be kell jelentkezni
Az legalább meglett, hogy van egy lib/libsa/strerror.c, amiben az ismert errno-értékeket szöveggé fordítja, de speciel a 20 nem megy neki. Itt kellene nézelődni:
Itt: sys/sys/errno.h
...
#define ENODEV 19 /* Operation not supported by device */
#define ENOTDIR 20 /* Not a directory */
#define EISDIR 21 /* Is a directory */
...
#define ELAST 95 /* Must be equal largest errno */
Továbbá itt: sys/lib/libsa/saerrno.h
(ELAST=95)
#define EADAPT (ELAST+1) /* bad adaptor */
#define ECTLR (ELAST+2) /* bad controller */
#define EUNIT (ELAST+3) /* bad drive */
#define EPART (ELAST+4) /* bad partition */
#define ERDLAB (ELAST+5) /* can't read disk label */
#define EOFFSET (ELAST+6) /* relative seek not supported */
#define EBSE (ELAST+7) /* bad sector error */
#define EECC (ELAST+8) /* uncorrectable ecc error */
#define EHER (ELAST+9) /* hard error */
#define ESALAST (ELAST+9)
Na szóval ez a lib/libsa/strerror.c:strerror
ez csak egy részhalmazát tartalmazza a hibakódoknak, mivel ez nem a libc publikus függvénye, csak egy afféle adhoc belső strerror.
Lenne itt egy gyanúsított: sys/stand/boot/cmd.c:
97 int
98 read_conf(void)
99 {
113 if ((fd = open(qualify(cmd.conf), O_RDONLY)) < 0) {
114 if (errno != ENOENT && errno != ENXIO) {
115 printf("open(%s): %s\n", cmd.path, strerror(errno));
116 return 0;
117 }
118 return -1;
119 }
A qualify
írja a cmd.path
-ba a cmd.bootdev
:cmd.conf
értékét.
43 struct cmd_state {
44 char bootdev[BOOTDEVLEN]; /* device */
45 char image[MAXPATHLEN - 16]; /* image */
46 int boothowto; /* howto */
47 char *conf; /* /etc/boot.conf normally */
48 void *addr; /* load here */
49 int timeout;
50
51 char path[MAXPATHLEN]; /* buffer for pathname compose */
52 const struct cmd_table *cmd;
53 int argc;
54 char *argv[8];<>/* XXX i hope this is enough */
55 };
- A hozzászóláshoz be kell jelentkezni
Valami azt súgja, hogy a sys/lib/libsa/open.c
az illetékes, elannyira, hogy file-system kezelési képesség is van benne (vö: grub), azzal találja meg a kérdéses fájlt. Tehát a fs-handler mondja valamiért, hogy ENOTDIR.
Kiegészítő ovasmány: https://undeadly.org/cgi?action=article;sid=20200326083657
- A hozzászóláshoz be kell jelentkezni
FFS2 érdekes (fel is rakom a listámra), de itt pont nem beszél arról, hogy mekkora partícióról tud vele bootolni. Gyanítom, hogy ugyanúgy 1024 cylinder méretűről. Amíg a másodlagos bootloader a /boot, addig szerintem ugyanaz a limit, függetlenül, hogy milyen fájlrendszerről megy. az xxboot meg az elsődleges loader, a biosboot helyett van (FIXME), ugyanúgy a /boot-ot indítja másodlagos loader-nek.
- A hozzászóláshoz be kell jelentkezni
Ez lenne az: https://github.com/openbsd/src/blob/master/sys/lib/libsa/open.c
Benne:
109 /* pass file name to the different filesystem open routines */
110 for (i = 0; i < nfsys; i++) {
111 /* convert mode (0,1,2) to FREAD, FWRITE. */
112 error = (file_system[i].open)(file, f);
113 if (error == 0) {
114 f->f_ops = &file_system[i];
115 return (fd);
116 }
117 if (error == ENOENT || error == ENOTDIR)
118 break;
119 }
És van egy ilyen: https://github.com/openbsd/src/blob/master/sys/arch/amd64/stand/efiboot… ebben van a struct fs_ops file_system
66 struct fs_ops file_system[] = {
67 { tftp_open, tftp_close, tftp_read, tftp_write, tftp_seek,
68 tftp_stat, tftp_readdir },
69 { ufs_open, ufs_close, ufs_read, ufs_write, ufs_seek,
70 ufs_stat, ufs_readdir, ufs_fchmod },
71 { ufs2_open, ufs2_close, ufs2_read, ufs2_write, ufs2_seek,
72 ufs2_stat, ufs2_readdir, ufs2_fchmod },
73 { cd9660_open, cd9660_close, cd9660_read, cd9660_write, cd9660_seek,
74 cd9660_stat, cd9660_readdir },
75 #ifdef notdef
76 { fat_open, fat_close, fat_read, fat_write, fat_seek,
77 fat_stat, fat_readdir },
78 { nfs_open, nfs_close, nfs_read, nfs_write, nfs_seek,
79 nfs_stat, nfs_readdir },
80 #endif
81 };
82 int nfsys = nitems(file_system);
83
84 struct devsw devsw[] = {
85 { "TFTP", tftpstrategy, tftpopen, tftpclose, tftpioctl },
86 { "EFI", efistrategy, efiopen, eficlose, efiioctl },
87 };
88 int ndevs = nitems(devsw);
Ezt úgy vélem érteni, hogy szépen sorban próbálja a fájlrendszerek open-rutinjait, amíg nem sikerül valamelyik. De ha ENOENT(2) vagy ENOTDIR(20) jön vissza, akkor feladja.
- A hozzászóláshoz be kell jelentkezni
Fizikai gép? Virtuális gép? Miért építesz BIOS-ra 2022-ben, miért nem UEFI bootolsz?
- A hozzászóláshoz be kell jelentkezni
Nekem is BIOS módban indul a gépem. Miért baj ez 2022-ben? Mi az előnye egy UEFI-nek egy 5 évente telepített rendszer esetén? Tényleg érdekel, mert már elgondolkodtam, hogy a következő telepítésem UEFI-s lesz, csak még az előnyök nem jöttek eddig szembe.
Persze azon kívül, hogy modernebb és ez (lesz) a jövő.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
A gépben - ha akarod, ha nem - UEFI van, csak van a tetején egy kompatibilitási réteg (CSM), amivel emulálja a BIOS-t.
Miért baj ez 2022-ben? Mi az előnye egy UEFI-nek egy 5 évente telepített rendszer esetén?
Én a kérdésedet megfordítanám: miért akarnál egy korszerű hardveren, korszerű szoftverrel, natív megoldás helyett egy olyan kompatibilitási réteget használni, ami a ~40 évvel ezelőtti műszaki színvonalat prezentálja?
Persze azon kívül, hogy modernebb és ez (lesz) a jövő.
Gyakorlatilag 10 éve minden gép UEFI-vel van ellátva. Én nem jövőidőben beszélnék róla.
- A hozzászóláshoz be kell jelentkezni
Fizikai gép, nem szándékos választás volt, hanem default-an azt kaptam. Nem igazán érdekelt, mert ilyen jelenségre nem számítottam :P Viszont ha nem is default, de lehet UEFI boot-ot választani, megpróbálom.
- A hozzászóláshoz be kell jelentkezni
Az OpenBSD default particionálását én is utálom. Szét van szabdalva 100 felé, minden apróságnak külön szelet, de ez a BSD-knél divat, még a régi időkből átvéve. Így én kb. 30 gigát adok rootnak, a többit csak a /home-nak, swap nálam nincs. Boottal még nem volt gondom, mert általában olyan lemezre telepítem, amin nincs más. UEFI-vel simán bootolt eddig, Legacy CSM MBR boottal még nem próbáltam. Bevallom, hogy a bootlási mechanizmusát még nem ismerem olyan jól, mint a Linuxnak.
Most jelenleg nincs fent, mert kidöglött alóla a régi SSD, de azt nem tudja valaki, hogy bootkor hogy lehet az OpenBSD-n automatizálni, hogy a kezdeti bootloader ne kérje honnan bootoljon? Mert ha entert nyomok, akkor megismeri, hogy hd0, vagy ilyesmiről bootol, de fárasztó entert nyomkodni. Talán valami x másodperc múlva magától is eltűnik, de zavaró.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Remove the 5 second pause at boot-time
permanently, causing boot to load the
kernel immediately without prompting:
# echo "boot" > /etc/boot.conf
- A hozzászóláshoz be kell jelentkezni
Kösz az infót, legközelebb, ha felteszem, ezt mindenképp beállítom. Sajnos én bootidő-mániás vagyok, és a bootolási sebessége amúgy sem villám az OBSD-nek, így extra zavaró volt. Persze kicsit gyorsítottam rajta, kernel újralinkelésének kikapcsolása, Hyper-Threading/SMP bekapcsolása, stb., ez kicsit segít. A másik, amit nagyon ajánlok minden új OBSD usernek, főleg, ha laptopon használják, hogy apmd engedélyezésével (rc-ben) és paraméterezésével az energiatakarékossági szintet mindenképp állítsák be, egyébként túl forrón járatja a rendszer a procit. Van még egy csomó ilyen ajánlott beállítás.
Persze, a hivatalos OBSD FAQ is sok mindenről ír, de az elég elméleti, és nem megy rá a gyakorlati vonatkozásokra. Ráadásul elég sok beállítás túl konzervatív per default (memóriakezelés, konzolbeállítások, stb.) a frissen telepített rendszeren, így részletes beállítással jókora teljesítménytöbblet nyerhető. A másik még, amire figyelni kell, hogy a xenodm az X11-hez nem megkerülhető. Elsőre rondának tűnt, így kihagytam, és startx-et használtam helyette (Linuxon is azt használom, shell rc-ből automatizálva), de úgy meg a hardveres videógyorsítás nem fog menni (DRI, tearfree, stb. beállítások X-en), állítólag valami jogosultsági hiba, setuid vagy mi miatt. Csak xenodm-mel megy, de hála az égnek, van a xenodm-nek konfigja, amivel testre lehet szabni a kinézetet, úgy azért sokkal normálisabb lesz a megjelenése, csak out of the box néz ki ilyen fosul szegényke. De ez a rendszer egészére elmondható, hogy default néhol túlzottan fapados, de mind állítható, csak rá kell szánni az időt.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni