Azure Linux Documentation

repository·4.0·Indexed 26 days ago

https://github.com/microsoft/azurelinux

An open-source Linux distribution optimized for Azure, built on Fedora Linux for virtual machines, containers, and bare-metal platforms using the RPM package ecosystem. Includes documentation on the base project structure, distribution definitions, ISO installation, and specific packaging guides for Node.js and Python (PEP 517/518) using RPM macros.

Tokens
40.9K
Snippets
88
Records
241
Agent score
90%

What's inside Azure Linux

  1. Overview of libdrm

    4.0

    libdrm is a low-level userspace library used to access the Direct Rendering Manager (DRM) on Linux, BSD, and other operating systems supporting the ioctl interface.

    It provides:

    • Wrapper functions for ioctls to avoid exposing the kernel interface directly.
    • Support for tracking relocations and buffers for chipsets with a DRM memory manager.

    It is typically used by graphics drivers such as Mesa, X drivers, libva, and similar projects. While new kernel DRM drivers may require a newer libdrm, a newer libdrm is designed to remain compatible with older kernels.

  2. Understand the Kernel build and maintenance workflow

    4.0

    The Azure Linux kernel is not maintained directly in the dist-git repository. Instead, it is managed via a separate source tree.

    Key components of the workflow include:

    • Specfile Management: The .spec file is maintained as a template within the source tree.
    • Build Automation: The source tree contains build scripts used to generate configurations, (S)RPMs, and to populate the dist-git repository.
    • Patch Sets: Downstream patches are located in the source tree. You can view them using git log master..ark-patches or via the online repository.
    • Releasing: Every release in dist-git corresponds to a tag in the source repository. Tags follow the format name-version-release (note that the release portion does not include the dist tag, as the source can be built for various roots like Fedora or CentOS).
  3. Usage terms for Natural Earth map data

    4.0

    All versions of Natural Earth raster and vector map data are in the public domain. You are permitted to use the maps for any purpose, including:

    • Modifying content and design
    • Electronic dissemination
    • Offset printing
    • Personal, educational, and commercial use

    No permission is required from the authors, and crediting them is not mandatory.

  4. Explore the `base` project structure

    4.0

    The base project directory contains the core definitions for the Azure Linux distribution. It is organized into the following main sections:

    • Components (packages): Located in comps/, this directory defines the individual software packages that make up the distribution.
    • Images: Located in images/, this directory contains the definitions and configurations for the system images.
    • Tests: Contains the testing infrastructure for the base project components.
  5. Understand AI Agent Support Mechanisms in Azure Linux

    4.0

    Azure Linux uses several instruction and skill files to provide context to AI agents (like GitHub Copilot) for component management workflows. These mechanisms ensure agents understand the TOML-based metadata system, the overlay system, and the azldev tool.

    Supported Discovery Mechanisms

    MechanismDiscoverySupported Surfaces
    .github/copilot-instructions.mdAutoVS Code, Visual Studio, GitHub.com, Copilot CLI
    AGENTS.md (root and subdirectories)AutoVS Code, Copilot CLI
    Agent Skills (.agents/skills/*/SKILL.md)On-demand (description match)VS Code, Copilot CLI, Copilot coding agent
    .github/instructions/*.instructions.mdAuto (via applyTo globs)VS Code, Copilot CLI
    .github/agents/*.agent.mdUser-selected / inferredVS Code, Copilot CLI
    .github/prompts/*.prompt.mdUser-invoked (/command)VS Code only
    .mcp.jsonAutoCopilot CLI
    .vscode/mcp.jsonAutoVS Code only
  6. Access Unicode Emoji Version 16.0 data files

    4.0

    This directory provides the final data files for Unicode Emoji, Version 16.0. The following files are available in the Public/emoji/16.0/ directory:

    • emoji-sequences.txt: Contains emoji sequences.
    • emoji-zwj-sequences.txt: Contains Zero Width Joiner (ZWJ) emoji sequences.
    • emoji-test.txt: Contains test data for emoji validation.

    Additional related files for Version 16.0 can be found in the Unicode Character Database (UCD) at Public/16.0.0/ucd/emoji/:

    • emoji-data.txt: Core emoji data.
    • emoji-variation-sequences.txt: Emoji variation sequences.
  7. Understand the distro directory structure

    4.0
    The distro/ directory contains .toml files that define distributions and their specific versions. These files are used to specify distro-wide default configurations and resource URIs. Note that this directory does not contain definitions for components, packages, images, or tests; those are defined elsewhere in the repository.
  8. Understand the structure of `base` components

    4.0

    The base sub-project of the Azure Linux distribution is composed of various components defined via .toml files.

    • Standard Components: Most components imported without modification are listed in components.toml.
    • Customized Components: Components that require specific configuration, customization, or are defined using locally stored .spec files are organized into their own dedicated subdirectories.

    The directory structure is managed using includes keys within the .toml files to ensure all components are correctly loaded by the azldev tool.

  9. Migrate NetworkManager profiles from ifcfg to keyfile format

    4.0

    NetworkManager has deprecated the ifcfg format (stored in /etc/sysconfig/network-scripts/) in favor of the keyfile format (stored in /etc/NetworkManager/system-connections/). The keyfile format is INI-based and easier to parse.

    To migrate all existing profiles at once, use the nmcli connection migrate command. To migrate a specific profile, provide its name, UUID, or D-Bus path.

  10. Run tox-based tests with %tox

    4.0

    To run tests using tox in the %check section, first ensure dependencies are generated using the -t or -e flags in %pyproject_buildrequires. Then, use the %tox macro.

    Usage Patterns:

    • Standard: %tox runs the default environment.
    • Custom Environment: %tox -e %{toxenv}-integration.
    • Custom Flags: Use -- to pass flags to tox: %tox -- --flag-for-tox.
    • Custom Posargs: Use two sequential -- to pass arguments to posargs: %tox -- --flag-for-tox -- --flag-for-posargs.
    %check
    %tox
  11. Install Azure Linux Copilot skills as a plugin

    4.0

    To access Azure Linux skills from any working directory (cross-repo access), install the repository as a Copilot plugin locally:

    # One-time install — skills persist across sessions
    copilot plugin install --plugin-dir /path/to/azurelinux
    
    # Or load for a single session
    copilot --plugin-dir /path/to/azurelinux

    After installation, use /skills to list available skills.

    copilot plugin install --plugin-dir /path/to/azurelinux
  12. Implement timers and handle expiry

    4.0

    The application is responsible for providing timestamps to the library.

    • Timestamp Type: ngtcp2_tstamp (nanosecond resolution). Use a monotonic clock.
    • Duration Type: ngtcp2_duration (nanosecond resolution).
    • Invalid Timestamp: Do not pass UINT64_MAX as a ngtcp2_tstamp unless explicitly allowed.

    Timer Workflow:

    1. Get the next deadline using ngtcp2_conn_get_expiry().
    2. When the deadline is reached, call ngtcp2_conn_handle_expiry().
    3. Handle Results:
      • If it returns NGTCP2_ERR_IDLE_CLOSE, drop the connection immediately without calling ngtcp2_conn_write_connection_close().
      • Otherwise, call ngtcp2_conn_writev_stream() to send pending data.
    4. Reset Timer: After handling expiry and writing, call ngtcp2_conn_get_expiry() again to get the new deadline.