Bdisk что это

BDISK.EXE — Как исправить ошибки [РЕШЕНО]

Основные причины ошибок исполняемого файла EXE связаны с отсутствием или повреждением файла BDISK.EXE или, в некоторых случаях, заражением вредоносным ПО. Как правило, эти ошибки наблюдаются во время запуска Kings Quest : The Princess Bride. Большую часть проблем, связанных с данными файлами, можно решить посредством скачивания и установки последней версии файла EXE. Кроме того, регулярная очистка и оптимизация реестра Windows предотвратит создание неправильных ссылок на пути к файлам EXE, поэтому мы настоятельно рекомендуем регулярно выполнять сканирование реестра.

Windows Executable File форматы, классифицируемые в качестве Исполнимые файлы, чаще всего имеют расширение EXE. Ниже представлен список самых последних версий файлов практически для всех версий Windows (а также для некоторых %%os%%), которые вы также можете скачать. В настоящее время в нашем каталоге для загрузки могут отсутствовать некоторые файлы (такие как BDISK.EXE), но их можно запросить, нажав на кнопку Request (Запрос) ниже. Если вы не нашли необходимую вам версию файла в нашей базе, представленной ниже, мы рекомендуем обратиться непосредственно к Sierra Inc..

Поместите новый файл BDISK.EXE на место предыдущего (перезаписав предыдущий). Проблема больше не должна возникать, однако, чтобы убедиться в этом окончательно, следует выполнить проверку. Затем вы можете повторно открыть Kings Quest : The Princess Bride, чтобы проверить выводится ли сообщение об ошибке.

BDISK.EXE Описание файла
Формат файла:	EXE
Тип приложения:	N/A
Program:	Kings Quest : The Princess Bride
Вер:	1.0.0.0
Программист:	Sierra Inc.

Имя файла:	BDISK.EXE 8D32EB1C281DB7349C6519B4D9D19D9DC5AF4BDE
MD5:	B9BDFC3B2327497296C5023149BEF019
CRC32:

bdisk.exe : что это? и как его убрать (Решено)

Tip: В вашей системе запущено много процессов, которые потребляют ресурсы процессора и памяти. Некоторые из этих процессов, кажется, являются вредоносными файлами, атакующими ваш компьютер.
Чтобы исправить критические ошибки bdisk.exe,скачайте программу Asmwsoft PC Optimizer и установите ее на своем компьютере

Очистите мусорные файлы, чтобы исправить bdisk.exe , которое перестало работать из-за ошибки.

Запустите приложение Asmwsoft Pc Optimizer.
Потом из главного окна выберите пункт «Clean Junk Files».
Когда появится новое окно, нажмите на кнопку «start» и дождитесь окончания поиска.
потом нажмите на кнопку «Select All».
нажмите на кнопку «start cleaning».

Очистите реестр, чтобы исправить bdisk.exe , которое перестало работать из-за ошибки

Запустите приложение Asmwsoft Pc Optimizer.
Потом из главного окна выберите пункт «Fix Registry problems».
Нажмите на кнопку «select all» для проверки всех разделов реестра на наличие ошибок.
4. Нажмите на кнопку «Start» и подождите несколько минут в зависимости от размера файла реестра.
После завершения поиска нажмите на кнопку «select all».
Нажмите на кнопку «Fix selected».
P.S. Вам может потребоваться повторно выполнить эти шаги.

Как удалить заблокированный файл

В главном окне Asmwsoft Pc Optimizer выберите инструмент «Force deleter»
Потом в «force deleter» нажмите «Выбрать файл», перейдите к файлу bdisk.exe и потом нажмите на «открыть».
Теперь нажмите на кнопку «unlock and delete», и когда появится подтверждающее сообщение, нажмите «да». Вот и все.

Настройка Windows для исправления критических ошибок bdisk.exe :

Настройка Windows для исправления критических ошибок bdisk.exe

Нажмите правой кнопкой мыши на «Мой компьютер» на рабочем столе и выберите пункт «Свойства».
В меню слева выберите » Advanced system settings».
В разделе «Быстродействие» нажмите на кнопку «Параметры».
Нажмите на вкладку «data Execution prevention».
Выберите опцию » Turn on DEP for all programs and services . » .
Нажмите на кнопку «add» и выберите файл bdisk.exe , а затем нажмите на кнопку «open».
Нажмите на кнопку «ok» и перезагрузите свой компьютер.

Как другие пользователи поступают с этим файлом?

Всего голосов ( 202 ), 133 говорят, что не будут удалять, а 69 говорят, что удалят его с компьютера.

bdisk.exe Пользовательская оценка:

Переход на си

Всем доброго времени суток! Пишу подобие ОС =) перешел в Protect Mode, до этого писал на ассемблере, сейчас хочу перейти на Си. Кто подскажет как осуществить?
Какой — нибудь Hello World на си и как его скомпилировать\слинковать в бинарный файл? Какой компилятор юзать? Си знаю плохо, вот хочу подучить =)

2 ответа

30 декабря 2012 года
474 / / 15.02.2007

Несколько кусков из моего «подобия ОС»:

Переход в защищенный режим:

movw $ 0x1000 , % ax
movw % ax , % ds

movb % dl , bdisk

movb $ 0 , % ah
movb $ 2 , % al
int $ 0x10

movb $ 1 , % ah
movb $ 0x20 , % ch
int $ 0x10

movw $ 0x5000 , % ax
movw % ax , % ss
movw $ 0 , % sp

cli
call rmodeInitGDT
call rmodeInitIDT
call rmodeInitMainTSS

movl % cr0 , % eax
orw $ 1 , % ax
movl % eax , % cr0
jmp $ ( 8 * 16 ) , $ 0x0 // Сразу включается многозадачность — это переключение на описываемый ниже mainTSS

. globl bdisk
bdisk : . byte 0

rmodeInitMainTSS :
movw $ 0x6000 , % ax
movw % ax , % es
movb $ 0 , % al
movw $ 0xffff , % cx
call rmodeMemfill
movw $main , % es : 0x420 /* EIP main */ // Обрати внимание на эту строку . Здесь main — указатель на сишную функцию , на которую осуществляется переход . Подставляется при линковке .
movw $ 0 , % es : 0x422 /* EIP main */
movw $ 0xfff , % es : 0x438 /* ESP main */
movw $ 0 , % es : 0x43a /* ESP main */
movw $ 8 , % es : 0x44c /* CS main */
movw $ 24 , % es : 0x450 /* SS main */
movw $ 16 , % es : 0x454 /* DS main */
movb $ 4 , % es : 0x4a1
movw $ 0x270 , % bx
movw $mainNameSize , % cx
movw $mainName , % ax
call rmodeMemcopy
ret

mainName : . string «main»
mainNameSize = .- mainName
. globl rmodeMemfill
rmodeMemfill :
/* al — value
es : bx — dest
cx — size */
loopBfill :
movb % al , % es : ( % bx )
inc % bx
loop loopBfill
ret

. globl rmodeMemcopy
rmodeMemcopy :
/* ds : ax — src
es : bx — dest
cx — size */
loopBcopy :
movb ( % eax ) , % dh
movb % dh , % es : ( % bx )
inc % ax
inc % bx
loop loopBcopy
ret

В сишном коде должна быть объявлена функция «long main()», указатель на которую использован в rmodeInitMainTSS. В принципе она может называться и по другому.

gcc -c -ffreestanding -mtune=i386 -m32 startup.s gdt.s idt.s main.c asmFunctions.s
ld -mi386linux —oformat binary -melf_i386 -o kernel -T LDkernelScript

BDisk User and Developer Manual

See CREDITS in the project source for a list of thanks.

Preface

About the Author

I am a GNU/Linux Systems/Network Administrator/Engineer- I wear a lot of hats. I have a lot of side projects to keep me busy when I’m not working at $ , mostly to assist in other side projects and become more efficient and proficient at those tasks. “Shaving the yak,” [1] indeed.

A lot of research went into how low-level boot operations take place when writing BDisk, both in BIOS and UEFI [2] (and corresponding concepts such as Secureboot, etc.) which is no easy task to understand and very commonly misunderstood. (For instance, a common misconception is that UEFI necessarily implies Secureboot. This is quite far from the truth and UEFI by itself is quite a useful replacement for BIOS). I invite you to do research into the specifications yourself; it’s rather fascinating.

What is BDisk?

BDisk refers to both a live distribution I use in my own uses (for rescue situations, recovery, etc.) but foremost and most importantly, it also refers to the tool I use for building that distribution. In other words, it’s both a complete GNU/Linux distribution you can run entirely from USB/CD/DVD/etc. (without needing to install it to your hard drive)… and also the name of a tool to create a custom GNU/Linux install. The latter is what this project and documentation refer to when the word “BDisk” is used.

This documentation was started when I rewrote BDisk in Python 3.x; versions 0.x-2.x of BDisk were written in Bash, and horribly inelegant and rigid. [3] One of my main goals was to make BDisk as easy to use as possible. This is surprisingly hard to do- it’s quite challenging to try to approach software you’ve written with the mindset of someone other than you.

It’s my hope that by releasing this utility (and documenting it), you can use it and save some time for yourself as well (and hopefully get the chance to learn a bit more in the process!).

It of course is not the only live media creator out there, but most others only focus on remastering an existing ISO, or creating an installer ISO — not creating a custom live-centric environment.

Copyright/Licensing

The BDisk code is GPLv3-licensed. This means that you can use it for business reasons, personal reasons, modify it, etc. Please be sure to familiarize yourself with the full set of terms. You can find the full license in docs/LICENSE .

This document, and all other associated author-generated documentation, are released under the Creative Commons CC-BY-SA 4.0 copyright. It’s essentially the GPL for non-software, so similar terms apply.

User Manual

What good is software if nobody uses it?

BDisk was ultimately designed to make your life easier. «Why would I possibly need yet another LiveCD/LiveUSB?» Well, that’s sort of the point- by customizing a live distribution of GNU/Linux to your particular needs/desires/whimsy, you can do away with the multiple other images you keep around. It’s designed to let you create a fully customized distribution.

Using BDisk, you can:

Install GNU/Linux (Arch, CentOS, Debian, Gentoo, Ubuntu…). BDisk may be Arch-based, but many if not most other distros offer ways to install from any GNU/Linux live distribution.
Perform disk maintenance (mdadm, fdisk / gdisk, gparted, storcli, etc.). Need to replace that disk in your RAID and you don’t have hotswap? Not a problem!
Rescue, recover, wipe (scalpel, nwipe, foremost, etc.). Chances are this is why you booted a live distro in the first place, yes?
Boot over the Internet (or LAN). Burning a new image to CD/DVD/USB is a pain. BDisk has built-in support for iPXE (and traditional PXE setups). Update the filesystem image once, deploy it everywhere.
And much, much more.

Seriously.

This manual will give you the information you need to build your very own live GNU/Linux distribution.

1. Getting Started

1.1. Downloading

If it isn’t in your distro’s repositories (It is in Arch’s AUR! Both tagged release and git master.), you can still easily get rolling. Simply visit the project’s source code web interface and download a tarball under the Download column:

If you know the tag of the commit you want, you can use curl:

curl -sL -o bdisk.tar.xz https://git.square-r00t.net/BDisk/snapshot/BDisk-3.00-BETA.tar.xz

wget -O bdisk.tar.xz https://git.square-r00t.net/BDisk/snapshot/BDisk-3.00-BETA.tar.xz

Alternatively, you can use git. Git most definitely should be in your distro’s repositories.

You can clone via https:

git clone https://git.square-r00t.net/BDisk

or native git protocol:

git clone git://git.square-r00t.net/bdisk.git BDisk

The git protocol is much faster, but at a cost of lessened security.

1.2. Prerequisites

This is a list of software you’ll need available to build with BDisk.

1.2.1. Necessary

These are needed for using BDisk.

Python (>=3.5)
dosfstools
libisoburn
squashfs-tools (>=4.2)

These are required Python modules:

1.2.2. Optional

While not strictly necessary, these will greatly enhance your BDisk usage. I’ve included some reasons why you might want to install them.

Needed for building iPXE.

Needed for building iPXE.

For autodetection of version, automatically making commits for your project, checking out source code, etc.

For automatically signing releases, verifying downloaded files from the Internet as part of the build process, etc. It’s okay if you don’t have a key set up!

For syncing built ISOs to a fileserver, syncing to a remote iPXE server, syncing to a traditional PXE/TFTP server, etc.

2. Important Concepts

If this is your first foray into building live distros, there are some terms and concepts we need to understand first. This will simplify the process later on.

2.1. Terms

An operating system, or OS, is what your programs (email client, web browser, etc.) run on.

There are two basic types of booting systems that communicate between the hardware (the physical computer itself and its components) and the operating system: BIOS (Basic Input/Output System) which has been around for quite some time and the newer UEFI (Unified Extensible Firmware Interface). Don’t worry, you don’t need to memorize what they’re acronyms for and there won’t be an exam — just remember that BIOS is an older technology and UEFI is the newer one (and that they operate differently).

GNU/Linux, sometimes just referred to as Linux (And there is a difference between the terminologies, but it’s nuanced. You are welcome to read up on it though!), is an example of an operating system. Other examples include Windows, macOS (previously OS X), iOS, Android, and a whole slew of others. There are many types of GNU/Linux offerings, called distributions, flavors, or distros.

A live distro, live CD, live DVD, live USB, and the like are a way of booting an operating system without installing it on the hard drive- this means the computer doesn’t even need a hard drive installed, or it doesn’t matter if the installed operating system is broken. Typically they are Linux-based, but there are several Windows-based live releases out there (usually they’re focused on rescuing broken Windows systems, so they’re not very flexible).

Hybrid ISOs are ISO files that can be burned to optical media (CDs, DVDs, etc.) and also be dd‘d directly to a USB thumbdrive (for computers that support booting from USB). That means one file, multiple media types.

Architectures are different hardware platforms. This mostly refers to the CPU. Common implementations are 64-bit (also known as x86_64 or AMD64 for ones that support running both 64-bit and 32-bit software, or IA64 or Itanium for processors that only support 64-bit) and 32-bit (or i686 and the older i386 and i486 implementations). Most consumer PCs on the market today are x86_64.

Chroots, chrooting, and the like are variants on the word chroot. A chroot is a way of running a GNU/Linux install «inside» another GNU/Linux distro. It’s sort of like a virtual machine, or VM, except that it’s a lot more lightweight and it doesn’t do any actual virtualization- and uses the host’s kernel, memory mapping, etc. It’s very useful for development of operating systems.

PXE, or Pre-boot eXecution Environment, is a way of booting operating systems over a local network.

iPXE is a project that builds a very small Linux kernel, UNDI (traditional PXE) images, and the like that allow you to essentially use PXE over the Internet. It’s very flexible and customizable, and supports a custom scripting engine and such.

2.2. Why live media is necessary/Why you might want BDisk

«But Brent,» I hear you ask in a voice which most likely is nothing close to what you actually sound like and entirely in my head, «Why would I need a live CD/USB/etc.? And why BDisk?»

Elementary, my dear imaginary reader! I touch on some reasons why one might want live media in the beginning of the User Manual, but here’s why you might want BDisk specifically as opposed to another live distro (or live distro creator).

Fully customizable
Works with a multitude of GNU/Linux distros — both for the host build system and as the guest. (Still under development!)
It performs optimizations and compression to help you get the smallest ISO possible.
In addition to building hybrid ISOs, it supports building iPXE hybrid ISOs (meaning you only need a very small file; the rest of the operating system boots over the Internet).
It supports both BIOS and UEFI systems- both the full image and the iPXE images.
It supports multiple architectures (x86_64, i686, possibly IA64 — untested) on the same ISO.
It supports automatically syncing to a web mirror, PXE boot server, etc. via rsync upon successful build.
It supports SecureBoot (untested!).
It is 100% compatible with both the Arch installation guide and the Gentoo installation guide.
It allows for non-interactive/automated building (i.e. nightly images).
It supports arbitrary file inclusion in a defined path on the ISO itself, not via some arbitrary directory as a separate partition on the media.
It can automatically build an accompanying «mini» ISO using iPXE — which is also a hybrid, UEFI-supported ISO.
Automatic versioning based on git tags (optional).

2.3. Who might want to use BDisk?

System builders/hardware testers
System Administrators/Engineers/Architects
Information Security professionals
Computer repair shops
Technology Consultants
Hobbyists
Home GNU/Linux users
Technology enthusiasts

3. Project Structure

The following is a tree of files and directories in a BDisk root directory. Note that yours may not look quite like this, as BDisk supports some directory relocation to aid in packaging for distros. These will be examined in-depth in the coming sections.

 ├── bdisk │ ├── bchroot.py │ ├── bdisk.py │ ├── bGPG.py │ ├── bSSL.py │ ├── bsync.py │ ├── build.py │ ├── host.py │ ├── ipxe.py │ └── prep.py ├── docs │ ├── COPYING │ ├── LICENSE -> COPYING │ ├── manual │ │ └── (. ) │ ├── README ├── examples │ └── HTTP │ └── (. ) ├── extra │ ├── bdisk.png │ ├── bin │ │ └── (. ) │ ├── dist.build.ini │ ├── external │ │ └── (. ) │ ├── mirrorlist │ ├── pre-build.d │ │ ├── (. ) │ │ ├── i686 │ │ │ └── (. ) │ │ └── x86_64 │ │ └── (. ) │ └── templates │ ├── BIOS │ │ ├── isolinux.cfg.arch.j2 │ │ └── isolinux.cfg.multi.j2 │ ├── EFI │ │ ├── base.conf.j2 │ │ ├── loader.conf.j2 │ │ ├── ram.conf.j2 │ │ ├── uefi1.conf.j2 │ │ └── uefi2.conf.j2 │ ├── GPG.j2 │ ├── iPXE │ │ ├── BIOS │ │ │ └── isolinux.cfg.j2 │ │ ├── EFI │ │ │ ├── base.conf.j2 │ │ │ └── loader.conf.j2 │ │ ├── EMBED.j2 │ │ ├── patches │ │ │ ├── 01.git-version.patch.j2 │ │ │ └── 02.banner.patch.j2 │ │ └── ssl │ │ └── openssl.cnf │ ├── overlay │ │ ├── (. ) │ │ ├── i686 │ │ ├── x86_64 │ ├── pre-build.d │ │ ├── (. ) │ │ ├── i686 │ │ ├── x86_64 │ ├── VARS.txt.j2 │ └── VERSION_INFO.txt.j2 └── overlay ├── (. ) ├── i686 └── x86_64

3.1. bdisk/

This directory contains the «heart» of BDisk. It essentially is a Python module package. It contains several python «subpackages» split into different files that provide different functions for BDisk. Chances are you won’t ever need to touch anything in here.

[code_bchroot_py_code]
[code_bdisk_py_code]
[code_bgpg_py_code]
[code_bssl_py_code]
[code_bsync_py_code]
[code_build_py_code]
[code_host_py_code]
[code_ipxe_py_code]
[code_prep_py_code]

3.2. docs/

This directory contains various documentation and other helpful text.

3.2.1. COPYING

This contains BDisk’s license, the GPLv3.

3.2.2. LICENSE

This is simply a link to COPYING .

3.2.3. manual/

This directory contains the documentation source you’re reading right now! It’s written in asciidoc (well, to be more precise it’s written in/has some asciidoctor-isms). I’d recommend reading the rendered version, as the source (while perfectly human-readable) is written in a very modular fashion so it may be inconvenient to read each source file and following include directives.

3.2.4. README

This is a placeholder for common convention; it simply tells you to read the manual (and where to find it/build it).

3.3. examples/

This directory contains example filesystem layouts for e.g. your webserver (for iPXE), or your PXE server via TFTP.

3.4. extra/

This directory contains multiple «support files» for BDisk building.

3.4.1. bdisk.png

This file is used for bootloader graphics. If you change the name of the project, this can be named something different — see the section on uxname.

3.4.2. bin/

This directory contains sample code or extra tools that don’t have anything to do with BDisk normal operation but are useful in building a BDisk distribution.

3.4.3. dist.build.ini

This is the «source-provided»/upstream example build.ini . It will be sourced for any missing configuration options or the like.

3.4.4. external/

This directory contains external source code for use with extra features in BDisk that would otherwise be inconvenient to fetch and build dynamically.

3.4.5. pkg.build.ini

This is the recommended default build.ini file for packagers of distro repositories to use when packaging BDisk for inclusion in a package manager.

3.4.6. pre-build.d/

This file contains a «core» overlay. Generally these files shouldn’t be modified unless you know what you’re doing, but there are some interesting things you can do in here. Generally speaking, though, you’ll want to place your modifications in the overlay/ directory.

For files that should be included in both chroots, simply recreate the path with the desired file. For instance, if you want a file /etc/foo/bar.conf to exist in both i686 and x86_64 versions, it would exist as the path pre-build.d/etc/foo/bar.conf .

It follows the following structure:

i686/

This contains modifications that should be applied to the i686 version only. If you wanted a file to exist only in the i686 version at /etc/a/b.conf , it would be placed in pre-build.d/i686/etc/a/b.conf .

x86_64/

This contains modifications that should be applied to the x86_64 version only. If you wanted a file to exist only in the x86_64 version at /etc/z/y.conf , it would be placed in pre-build.d/x86_64/etc/z/y.conf .

3.4.7. templates/

This directory contains dynamic templates used for dynamic configuration building and other such things. They are written in Jinja2. If you haven’t used Jinja2 before, the templating documentation will prove to be very useful.

This allows you to customize low-level behaviour of BDisk without modifying the source.

BIOS/

The isolinux.cfg.arch.j2 template controls boot options for the single-arch versions of BDisk. In other words if you only build an i686 or only an x86_64 version, this is the template that would be used for BIOS boot mode.

The isolinux.cfg.multi.j2 is used for multi-arch. It manages booting for both i686 and x86_64 versions.

These files will let you change the behaviour of booting in BIOS systems. The menu colour, the menu entries, the menu default, etc.

EFI/

The files in here are systemd-boot configurations. The distributed defaults are:

base.conf.j2 , which controls the «main»/default entry.

loader.conf.j2 , the meta configuration file which tells the loader which entry to load by default and which entries to include.

ram.conf.j2 which allows BDisk to run entirely from RAM.

uefi1.conf.j2 which provides a UEFI shell (for older UEFI systems).

uefi2.conf.j2 which provides a UEFI shell (for newer UEFI systems).

GPG.j2

This file contains default parameters for the GPG key generation, if we need to automatically generate a key.

iPXE/

This directory holds templates for iPXE/mini builds.

The BIOS/ directory is similar to BIOS/ mentioned above, but it only needs one configuration file and is a much more minimal design (since its entire purpose is to chainload to the iPXE loader).

The EFI/ directory is similar to EFI/ above also, but needs fewer configuration files (its only purpose is to bootstrap iPXE).

EMBED.j2 is the iPXE embedded script (more info). This is what chainloads the remote resources (kernel, intird, squashed filesystem images, and so forth).

The patches/ directory largely control branding of the mini ISO. They are in unified diff (or «patch») format.

overlay/

This directory contains templated overlays. These are intended to be templated by the user. See the overlay section for more information on how to use this. Remember to suffix your template files with the .j2 extension.

pre-build.d/

This directory contains templated overlays. These are intended to not be managed by the user, as they handle configuration necessary for building an ISO. See the pre-build.d section for more information on this.

VERSION_INFO.txt.j2

This template specifies a VERSION_INFO.txt file placed in various locations throughout the builds to help identify which version, build, etc. the ISO is.

3.5. overlay/

This directory follows similar rules to the pre-build.d/ directory, except it is applied after the chroots are prepared (as it is designed to be user-centric rather than core functionality). We’ll go more into this later in-depth, as this is where most of your customizations will be done.

It follows the following structure:

3.5.1. i686/

This contains modifications that should be applied to the i686 version only. If you wanted a file to exist only in the i686 version at /etc/a/b.conf , it would be placed in overlay/i686/etc/a/b.conf .

3.5.2. x86_64/

This contains modifications that should be applied to the x86_64 version only. If you wanted a file to exist only in the x86_64 version at /etc/z/y.conf , it would be placed in overlay/x86_64/etc/z/y.conf .

4. The build.ini File

This file is where you can specify some of the very basics of BDisk building. It allows you to specify/define certain variables and settings used by the build process. It uses ConfigParser for the parsing engine, and you can do some more advanced things with it than I demonstrate in the default.

It’s single-level, but divided into «sections». This is unfortunately a limitation of ConfigParser, but it should be easy enough to follow.

Blank lines are ignored, as well as any lines beginning with # and ; . There are some restrictions and recommendations for some values, so be sure to note them when they occur. Variables referencing other values in the build.ini are allowed in the format of $ if it’s in the same section; otherwise, $ can be used.

If you want to use your own build.ini file (and you should!), the following paths are searched in order. The first one found will be used.

/etc/bdisk/build.ini
/usr/share/bdisk/build.ini
/usr/share/bdisk/extra/build.ini
/usr/share/docs/bdisk/build.ini
/usr/local/etc/bdisk/build.ini
/usr/local/share/docs/bdisk/build.ini
/opt/dev/bdisk/build.ini
/opt/dev/bdisk/extra/build.ini
/opt/dev/bdisk/extra/dist.build.ini
/../build.ini

We’ll go into more detail for each section below.

4.1. Example

[bdisk] name = BDISK uxname = bdisk pname = BDisk ver = dev = A Developer email = dev@domain.tld desc = A rescue/restore live environment. uri = https://domain.tld root_password = user = yes [user] username = $ name = Default user groups = $,admin password = $$6$$t92Uvm1ETLocDb1D$$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/ [source_x86_64] mirror = mirror.us.leaseweb.net mirrorproto = https mirrorpath = /archlinux/iso/latest/ mirrorfile = .sig mirrorchksum = $sha1sums.txt chksumtype = sha1 mirrorgpgsig = gpgkey = 7F2D434B9741E8AC gpgkeyserver = [source_i686] mirror = mirror.us.leaseweb.net mirrorproto = https mirrorpath = /archlinux/iso/latest/ mirrorfile = mirrorchksum = $sha1sums.txt chksumtype = sha1 mirrorgpgsig = gpgkey = gpgkeyserver = [build] dlpath = /var/tmp/$ chrootdir = /var/tmp/chroots basedir = /opt/dev/bdisk isodir = $/iso srcdir = $/src prepdir = $/temp archboot = $/$ mountpt = /mnt/$ multiarch = x86_64 sign = yes ipxe = no i_am_a_racecar = no [gpg] mygpgkey = mygpghome = [sync] http = no tftp = no git = no rsync = no [http] path = $/http user = http group = http [tftp] path = $/tftpboot user = root group = root [ipxe] iso = no uri = https://domain.tld ssldir = $/ssl ssl_ca = $/ca.crt ssl_cakey = $/ca.key ssl_crt = $/main.crt ssl_key = $/main.key [rsync] host = user = path = iso = no

4.2. [bdisk]

This section controls some basic branding and information having to do with the end product.

4.2.1. name

This value is a «basic» name of your project. It’s not really shown anywhere end-user visible, but we need a consistent name that follows some highly constrained rules:

Alphanumeric only
8 characters total (or less)
No whitespace
ASCII only
Will be converted to uppercase if it isn’t already

4.2.2. uxname

This value is used for filenames and the like. I highly recommend it be the same as name (in lowercase) but it doesn’t need to be. It also has some rules:

Alphanumeric only
No whitespace
ASCII only
Will be converted to lowercase if it isn’t already

4.2.3. pname

This string is used for «pretty-printing» of the project name; it should be a more human-readable string.

Can contain whitespace
Can be mixed-case, uppercase, or lowercase
ASCII only

4.2.4. ver

The version string. If this isn’t specified, we’ll try to guess based on the current git commit and tags in build:basedir . If build:basedir is not a git repository (i.e. you installed BDisk from a package manager), you MUST specify a version number.

No whitespace

4.2.5. dev

The name of the developer or publisher of the ISO, be it an individual or organization. For example, if you are using BDisk to build an install CD for your distro, this would be the name of your distro. The same rules as pname apply.

Can contain whitespace
Can be mixed-case, uppercase, or lowercase
ASCII only

4.2.6. email

An email address to use for git syncing messages, and/or GPG key generation.

4.2.7. desc

What this distribution/project is used for.

Can contain whitespace
Can be mixed-case, uppercase, or lowercase
ASCII only

4.2.8. uri

What is this project’s URI (website, etc.)? Alternatively, your personal site, your company’s site, etc.

Should be a valid URI understood by curl

4.2.9. root_password

The escaped, salted, hashed string to use for the root user.

Please see the section on passwords for information on this value. In the example above, the string 6t92Uvm1ETLocDb1D$$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/ is created from the password test . I cannot stress this enough, do not use a plaintext password here nor just use a regular /etc/shadow file/ crypt(3) hash here. Read the section. I promise it’s short.

4.2.10. user

Default: no

This setting specifies if we should create a regular (non-root) user in the live environment. See the section [user] for more options.