Chryseus.co.uk

  • Understanding the Linux Boot System

    Date Posted:

    Background

    If you’ve ever tried to install Linux from scratch or with a distribution such as Arch or Gentoo you would have found the partitioning and boot loader setup to be a rather confusing mess of different standards, compatibility problems and issues, particularly with dual booting, even when using an installer there is still a chance things will not work as intended, additional features such as encryption, secure boot, fast boot and RAID further complicate matters, in this article I will attempt to simplify things somewhat, however I still recommend referring to the Arch and Gentoo wikis for the finer details.

    BIOS and UEFI

    The Basic I/O System (BIOS) is a memory chip on the motherboard that contains the code used to perform initialisation of hardware, provide basic software services and configuration used during the boot process, a lot of this was standardised way back in the 80’s so as you might expect the BIOS is now being phased out in favour of the Unified Extensible Firmware Interface (UEFI), this is a much more modern replacement that was introduced in 2006, as of today all consumer level computers support UEFI.

    UEFI shares a lot of similarity with the BIOS and includes backwards compatibility, it provides a number of new features such as enhanced user configuration, support for modern technologies such as secure boot and the UEFI boot process, any preinstalled system since Windows 8 uses it by default, UEFI comes in 32 bit (known as IA32) and 64 bit variants, the former is somewhat rare so if you have a relatively modern computer it’s almost certainly 64 bit UEFI.

    Partition Table

    The partition table is a data structure that tells software how the drive has been partitioned, the original partition table is called the Master Boot Record (MBR) since it contains the master boot loader along with the partition table, this can register a maximum of four primary partitions which can contain their own boot loader, one of these can be replaced with an extended partition which may contain any number of logical partitions, the first 512 byte sector1 of a drive contains the boot loader (446 bytes) along with the partition table (64 bytes) plus a 2 byte signature, due to the very small size it’s typical for the boot loader to read a partition and execute a larger boot loader, a process known as chain loading.

    Due to the significant limitations with the MBR partition table a new one was introduced around the time of UEFI called GUID Partition Table (GPT), this allows for much larger disks (> 2 TB) as well as up to 128 partitions, it also includes redundancy and error checking with a copy of the GPT being placed at the end of the drive. For backwards compatibility and to avoid damage from software that is not GPT aware a MBR2 is placed in the first sector of the drive.

    Boot Process

    For a BIOS system after completing the Power On Self Test (POST) which checks and initialises the hardware, it looks for a disk with a valid MBR, this is then executed, BIOS is capable of booting both MBR and GPT.

    BIOS Boot Process

    UEFI provides support for the legacy BIOS boot process using the Compatibility Support Module (CSM) which can be disabled if so desired, UEFI is almost always used with GPT, after the POST stage UEFI looks in its own Non-Volatile Random Access Memory (NVRAM) which contains the boot entries that tell it where to find boot loaders along with other EFI variables and applications.

    Unlike BIOS it can read some partitions directly, boot loaders and other UEFI applications are stored in the EFI System Partition (ESP) which is normally a FAT32 partition of at least 100 MiB, only one of these is allowed per drive, boot loaders are stored as normal files, for example the Windows boot loader is /EFI/Microsoft/Boot/bootmgfw.efi, for removable drives that don’t have an entry in the NVRAM the boot loader is stored at /EFI/Boot/bootx64.efi (bootia32.efi for 32 bit).

    UEFI Boot Process3

    Once the boot loader is executed things proceed mostly the same as with BIOS.

    This gives us four possible combinations:

    1. BIOS / MBR
    2. BIOS / GPT
    3. UEFI / MBR
    4. UEFI / GPT

    Option 2 is not recommend if you’re trying to dual boot since Windows never uses this setup, option 3 is not recommended even though it may technically work.

    BIOS/MBR Setup

    This is an example of a simple BIOS / MBR setup with a single root partition:

    Mount PointPartition TypeRecommended Size
    [SWAP]SWAP4 GiB minimum
    /Linux FilesystemRest of drive

    Installing GRUB for example is done with:

    grub-install --target=i386-pc /dev/sdX
grub-mkconfig -o /boot/grub/grub.cfg

    Where /dev/sdX is the root partition, or /boot partition if a separate one is used.

    BIOS/GPT Setup

    The only real difference here is that GRUB requires a little room at the start of the drive to store part of the boot loader, which would normally be stored in the gap between the MBR and the first partition, since the GPT partition table is bigger we need a dedicated partition for this.

    Mount PointPartition TypeRecommended Size
    BIOS Boot Partition1 MiB
    [SWAP]SWAP4 GiB minimum
    /Linux FilesystemRest of drive

    Installation otherwise remains the same as BIOS/MBR, note that the BIOS boot partition must not be formatted as anything.

    UEFI/GPT Setup

    Mount PointPartition TypeRecommended Size
    /boot or /efiEFI System Partition1 GiB
    [SWAP]SWAP4 GiB minimum
    /Linux FilesystemRest of drive

    The ESP should be formatted as FAT32, where you mount it has a significant impact, mounting it to /boot makes maintenance and updates easier however there is a potential risk that other operating systems may screw with the ESP in a way that breaks your system, mounting it to /efi eliminates this risk and allows for a smaller partition since it only needs to store the boot loader, personally I recommend the former option for the sake of simplicity, besides GRUB you should have efibootmgr and os-prober installed.

    Installation of GRUB is done with:

    grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg

    Replace esp with either /boot or /efi, use i386-efi if you have 32 bit UEFI.

    Alternatively rEFInd may be a better choice of boot loader than GRUB particularly if you want more advanced features, other options include EFISTUB and systemd-stub.

    Note: It may be advisable to install as a removable disk, this provides protection should the EFI variables in NVRAM become damaged or you have to move the drive to another computer and want it to remain bootable, this can be done by adding the removable flag to grub-install.

    Dual Booting with Windows

    Dual booting Windows has many traps for beginners so I don’t generally recommend it, but if you really want to do it you need to understand some limitations based on the Windows version you want to use:

    • Windows 8/8.1 and 10 32 bit only support booting from IA32 UEFI/GPT or BIOS/MBR
    • Windows 8/8.1 and 10 64 bit only support booting from UEFI/GPT or BIOS/MBR
    • Windows 11 supports 64 bit UEFI/GPT only

    To ensure compatibility you should use the same boot method on both Windows and Linux, regardless if they are on different drives or not.

    Generally it’s recommended to install Windows first then Linux but it can be done the other way around, Windows installed in UEFI mode will create an ESP if one doesn’t exist, this is by default too small to mount to /boot so you will have to resize it, or create the partition layout yourself, if possible I would strongly recommend having Windows and Linux on separate drives to make life a bit easier.

    Before you attempt anything read carefully through this wiki page and make sure you have enough time to deal with problems, once you’ve done it a few times it isn’t that difficult.

    Footnotes

    1. 4096 byte sectors are now also sometimes used ↩︎
    2. Referred to as the protective MBR ↩︎
    3. In practice the kernel can be within the ESP if there is sufficient space ↩︎

    Categories:

    ,

    Tags:

    , ,

  • Stable Diffusion Turbo – Comfy UI Workflows

    Date Posted:

    Recently Stability AI released two new models called SDXL Turbo and SD Turbo, these are designed to drastically reduce the number of steps required to as low as one step, this allows for rapid testing and real time applications, SD Turbo is specifically trained on SD 2.1 which is a bit of a poor choice in my opinion given the vast majority of users and content are for SD 1.5 and SDXL, most people skipped SD 2.1 entirely including myself, in this article I’m going to cover a number of ways you can make use of it, you may have also heard of another method to reduce steps needed known as LCM, in comparison Turbo is essentially always better and maintains higher quality.

    As a caveat the quality of these turbo models is lower, both of them are trained to output 512×512, but can be pushed as high as 640×640, there are ways around this which I will cover later in this article, but you should consider turbo to be more of a very useful tool than an option for directly producing high quality images.

    Ultra Fast

    For the fastest possible generation you’re going to need the following workflow:

    Naturally this workflow sacrifices quality for speed allowing one step generation, this works great for prompt testing and real time drawing with control nets (example at end), to maximize speed use the taesd or taesdxl VAE decoder (place in models/vae_approx), you may also want to launch Comfy UI with –gpu-only to avoid any model unloading, steps should not exceed 4 and CFG not above 1.5, due to the very low CFG negative prompt is practically useless.

    Model Merge and Turbo LoRA

    One thing that may be a deal breaker for you is being stuck with the rather limited base SD training, fortunately you can merge turbo with other models and still get most of the benefit, a number of merged models are already available ready to use on popular model sharing websites such as Civitai, you can also do this yourself with the Model Merge Simple and Model Merge Blocks nodes, you may need to play around with the ratio a bit, you should use a regular sampler and aim for 4-12 steps with CFG up to 2.5, you can also push the resolution more doing this with 1024×768 being possible with an SDXL merge, however turbo does still have somewhat of an influence on generated images.

    To remove the need to merge the models and reduce the influence of turbo there is a recently released Turbo LoRA by shiroppo which works very well, use this with the model only LoRA loader with a weight of 0.25 to 0.5.

    Further improvement to quality can be had by using FreeU_V2 (already integrated in Comfy UI), this also significantly improves the contrast and colour which is desirable with the more limited CFG range, the end result is you can get reasonably good quality images in as low as 6 steps which is a massive time saving particularly if you’re using a lower end GPU, you can further enhance these images with a regular image to image workflow making this very efficient.

    Samples

    Here is a few samples of what can be achieved, these were all made with Juggernaut V7 + Turbo LoRA 0.4 + FreeU_V2, clip skip 1, 12 steps, CFG 1.2, 768×1024.

    Categories:

    ,

    Tags:

    , ,

  • Stable Diffusion Inpainting Tutorial – Comfy UI

    Date Posted:

    Inpainting is a technique that allows you to make more controlled changes to an existing image, it works by defining an area called a mask for Stable Diffusion to work on, this masked area is then processed and blended into the image to ideally give a natural looking result, this is primarily used to adjust and improve existing content such as hands, faces, objects, etc, but can also be used to add new content to a picture.

    In this tutorial I will be showing you how to do it with Comfy UI using SDXL 1.0, along with the SDXL inpainting model which I strongly recommend for good inpainting (place this in ‘models/unet’), the same method will work for other models as well, SD 1.5 users may additionally want to use the inpainting control net.

    Recommended Addons

    I recommend installing ComfyI2I as it provides a lot of useful functionality when it comes to inpainting such as an improved mask editor, installation is easy and can be done via the following steps (ensure you have git installed on your system)

    cd <path to ComfyUI>
.\venv\scripts\activate
cd custom_nodes
git clone https://github.com/ManglerFTW/ComfyI2I.git
cd ComfyI2I
pip -r requirements.txt

    Basic Workflow

    The first step is to produce an image you want to inpaint, once you have the image you can load it with a ‘load image’ node, to speed things up use the copy and paste to clipspace functionality, to make a mask simply right click on the load image node and click Open in MaskEditor, or if you installed ComfyI2I use Open in ComfyShop, then you just need to paint the area you want to change and click save, alternatively for more control paint a solid colour mask in an image editor and load it in with another Load Image node, you can then convert the loaded image to a mask with a Image to Mask node.

    An example workflow of this is changing the hair colour of a person from brunette to blonde:

    The only differences here from a regular image to image workflow is the inpainting model from the UNET Loader is used instead of the checkpoint model, also the image and mask is given to the VAE Encode (for inpainting) rather than a regular VAE Encode, as such you should make sure your loaded image is of a sensible resolution for your Stable Diffusion model, you can use an Image Scale node to ensure this or do it externally.

    Advanced Workflow

    One thing you may notice is the inpainting doesn’t work well on smaller areas and detail can be less than expected, this is because the inpainting is done with the whole image rather than just the area we want, to do full resolution inpainting we need to cut out the area we want to inpaint, scale it up, inpaint, scale it down and paste it back into the original image, fortunately ComfyI2I provides nodes specifically to do this, and it can work on multiple masked areas at once making it great for things such as face replacement and enhancement, fixing hands and so on.

    This may look quite complicated but it essentially boils down to doing what I said before, the Mask Ops and Inpaint Segments nodes chop up the image, giving us three things:

    • Region Mask (rectangular mask of the area cut)
    • Cut Image (image cut out of the region)
    • Cut Mask (mask cut out of the region)

    The cut mask is then sent to the VAE Encode (for inpainting) once converted with an Image to Mask node, as well as the cut image, this is then inpainted as normal before being merged back in to the original image with the Combine and Paste node, ComfyI2I has much more functionality including prompt based masking so don’t forget to check out the examples.

    Outpainting

    Outpainting lets you expand the image outwards while ideally avoiding any visible seams in the image, this isn’t perfect by itself and can be significantly improved by using control nets, for best results you should outpaint a relatively small amount of pixels at a time, 128 to 512 works well for SDXL.

    The workflow is nearly identical to inpainting except for the Pad Image for Outpainting node, if there is too much of a visible seam try adjust the feathering amount.

    Conclusion

    Proper use of inpainting can greatly enhance your images so it’s an important skill to learn if you want to get the most out of SD, you can also try use it to add new content to your images however you may find it struggles unless you make a rough drawing of what you want first and then inpaint over it, currently there is no inpainting control net for SDXL which may mean you get better results out of SD 1.5 models.

    Categories:

    Tags:

    , , ,