burmilla / os Goto Github PK

View Code? Open in Web Editor NEW

This project forked from rancher/os

205.0 205.0 13.0 84.67 MB

Tiny Linux distro that runs the entire OS as Docker containers

Home Page: https://burmillaos.org

License: Apache License 2.0

Shell 11.67% Go 87.05% Makefile 0.21% Dockerfile 0.58% Smarty 0.48%

os's People

Stargazers

Watchers

Forkers

meierdan dgiebert isgasho olljanat rakshasa justledbetter madchr1st altb tredger tim6332001 laxmankk corrs sskf

os's Issues

Initramfs unpacking failed: uncompression error & kernel panic

BurmillaOS Version: (ros os version)
burmillaos-v1.9.0-rc1

Where are you running BurmillaOS? (docker-machine, AWS, GCE, baremetal, etc.)
baremetal

Which processor architecture you are using?
64bit Intel i5 650

Do you use some extra hardware? (GPU, etc)?
Don't believe so.

Which console you use (default, ubuntu, centos, etc..)
debian

Do you use some service(s) which are not enabled by default?
No

Have you installed some extra tools to console?
No

Do you use some other customizations?
No

Please share copy of your cloud-init (remember remove all sensitive data first)

None

I came across BurmillaOS after seeing the news of RancherOS's EOL. My home server's running Proxmox. I tried creating a VM with 4GB of memory and ran burmillaos-v1.9.0-rc1.iso and burmillaos-v1.9.0-rc1-proxmoxve.iso. Both experience kernel panics on boot.

I got some screenshots of the boot up messages.
https://i.imgur.com/5KH2Uwl.png

initramfs unpacking message
https://i.imgur.com/BEzsES5.png

kernel panic
https://i.imgur.com/0QIiYHo.png
https://i.imgur.com/CL9Z8Ih.png

I'm still able to boot rancheros-proxmoxve.iso (v1.5.6). I installed rancheros 1.5.6 and did the burmilla upgrade commands and it installed and rebooted fine.

sudo ros config set rancher.upgrade.url https://raw.githubusercontent.com/burmilla/releases/v1.9.x/releases.yml
sudo ros os upgrade

Add early SSH for LUKS

Hi :-) I love it that rancheros has now a community-edition to stop it from EOL :-). It is one of the best systems I've had :-). Therefore I have some very cool ideas how burmilla can become even better than rancheros was :-).

rancheros supported full disk encryption, but didn't has early-ssh to decrypt it. It would be really cool if one could configure early-ssh with the cloud config. That would make rancheros even more secure :-).
rancher#2545
a colorfull terminal would be a nice gimmick :-). Like this os:
https://blog.hypriot.com/
Support for pi4

Hope this get's integrated :-) if someone has more ideas or can offer help to the developers of this os that would be nice :-) I would be in for testing :-)

EPIC: Setup repositories and build/release automation for BurmillaOS repositories

As I'm currently working alone with this repository I will use this issue to keep track about progress.

TODO:

Removal of Open-iSCSI ?

BurmillaOS Version: Not yet installed, still using rancheros

Where are you running BurmillaOS? Baremetal at Hetzner

Do you use some service(s) which are not enabled by default? open-iscsi

I am planning to do a test run of BurmillaOS including installation and documentation for Hetzner, was there a reason to remove the open-iscsi service as it would be needed for Longhorn ?

https://longhorn.io/docs/1.0.2/deploy/install/#installation-requirements

The system boot sample is not the correct one

As you can see in the image ros-sysinit keeps throwing messages after requesting the login user
This is confusing for the user when he has to enter the login data.

Burmilla v1.9.1 ISO's console boot up takes a very long time

Burmilla v1.9.1 ISO's console boot up takes a very long time, about 5+ minutes.

The console stops at message "BurmillaOS v1.9.1 started.", and silently it will be stuck there for about 5+ minutes.

I am not sure what it is waiting on.

This can be reproduced by using a VirtualBox VM that boots the ISO. non-ISO based booting (e.g. boot from hard drive after installation) does not seem to have this same issue.

The next message on dmesg is "random: crng init done". maybe it is initializing the random number generator? It feels an unexpected long time for that.

Another guess would be it is downloading something, but even for that 5+ minutes seems too long.

Changing default console to Debian and include most common tools to it

Based on #6 Ubuntu looks to be most common console so I propose that we change it to default and drop other consoles (to simplify maintenance).

Then we can also implement these changes to defaults:

Install open-iscsi with apt (and drop open-iscsi system service) like proposed on rancher#2636
Install these commonly used tools by default:
- iputils-ping
- ~~git~~

Those will increase size of image a little bit but we can also create releases for virtualization platforms without firmwares (using rancher#2810) so outcome is most probably very near of current one.

@ToeiRei I see that you are using Debian console, any objections about using Ubuntu instead of it?
@PrplHaz4 I see that you are using default (Alpine) console, any objections about using Ubuntu instead of it?

Best/correct way to relocate /var/lib/docker for user-docker

BurmillaOS Version: (ros os version)
1.9.0

I'm trying to move the docker folder to another partition, mostly because burmilla is currently running on a very small VM and I'd like to preserve the disk space.

In a standard linux distribution, my usual way is stop docker, rsync /var/lib/docker to the new destination, either change the data-root path or directly symlink the old folder to the new location.

I'm not sure how to achieve this because of the volumes structure.

AFAIU, container docker has /var/lib/user-docker mapped to /var/lib/docker that is owned by the container container-data-volumes. Needless to say/var/lib/user-docker is not available from the burmilla console.

Thanks!

Use UEFI instead of BIOS

Rancher OS works only with BIOS.

All modern hardware and most of the virtualization platforms supports UEFI so I think that on BurmillaOS we can go to other end drop BIOS support totally which (at least on theory) will simplify build process.

Related issues:

Existing/partly implemented solution:

v1.9.0 release tag instructions should switch to debian console

BurmillaOS Version: (ros os version)
v1.9.0

The instructions in the v1.9.0 tagged release says to switch console to default, but I believe it should be debian.
https://github.com/burmilla/os/releases/tag/v1.9.0

Current:

sudo ros console switch default

Update to:

sudo ros console switch debian

Update or replace system-docker

Currently the version is currently pinned to 17.06

The buildsystem the following forks with the main change linked:

github.com/rancher/docker-cli changes
github.com/rancher/docker changes
github.com/rancher/docker-ce-packaging changes

Do you want to also create a fork or use patch files instead ?

Upgrade from rancher/os to burmilla/os incomplete

BurmillaOS Version: (ros os version)
1.9.0
Where are you running BurmillaOS? (docker-machine, AWS, GCE, baremetal, etc.)
baremetal
Which processor architecture you are using?
x86-64
Do you use some extra hardware? (GPU, etc)?
GPU, HBA
Which console you use (default, ubuntu, centos, etc..)
default
Do you use some service(s) which are not enabled by default?
zfs,kernel-header,kernel-extras
Have you installed some extra tools to console?
lm-sensors
Do you use some other customizations?
Nope
Please share copy of your cloud-init (remember remove all sensitive data first)

#cloud-config
hostname: storage
rancher:
  modules:
  - coretemp
  - nct6775
  - sata_sil
  services_include:
    kernel-extras: true
    kernel-headers: true
    zfs: true
  state:
    dev: LABEL=RANCHER_STATE
    wait: true
ssh_authorized_keys:
    ......

I just upgraded my server from rancher/os 1.5.6 to burmilla/os 1.9.0 and things went smoothly in general. However I realized that the config option "rancher.repositories.core.url" wasn't upgraded to burmilla/os-services so I had to do that manually.

Just wanted to give you a heads up that it's either a step missing in the upgrade guide or that something that should be taken care of during upgrade isn't happening as expected.

Strategy to update the zfs service to use openzfs

I have a fork of os-services with zfs updated to both 0.8.6 and 2.0.1.

How do we want to handle this?

ZFSonLinux has rebranded to OpenZFS with version 2.0.0.

I could do a PR with the zfs services bumped to 0.8.6 and include a new service openzfs which will be using version 2.0.1.

Or I could do a PR where I just bump the zfs service to version 2.0.1 directly.

From what I can tell, OpenZFS (2.0.1) can import older pools and you need to manually enable any new features that a later version bings (just as it's always been) so I guess we won't be breaking anyones zfs setup by bumping the zfs service to 2.0.1 directly.

Thoughts?

Missing assets from release: vmlinuz, initrd, rootfs.tar.gz

Rancher/os release these assets with theirs releases: vmlinuz, initrd, rootfs.tar.gz
These files are used for iPXE installation. Is it possible to add them to your released assets too?

Update rsync

Hello,

Is it possible to update rsync to the latest version?
Currently BurmillaOS uses version 3.1.3 from 2018. The latest version is 3.2.3 https://rsync.samba.org/.

Thx

BurmillaOS Version: (ros os version) v2.0.0-beta3

Where are you running BurmillaOS? (docker-machine, AWS, GCE, baremetal, etc.) Proxmox VM

Which processor architecture you are using? AMD64

Which console you use (default, ubuntu, centos, etc..) default

Please share copy of your cloud-init (remember remove all sensitive data first)

rancher:
  environment:
    EXTRA_CMDLINE: /init
  network:
    interfaces:
      eth0:
        address: 192.168.2.39/24
        dhcp: false
        gateway: 192.168.2.1
        mtu: 1500
  services_include:
    docker-compose: true
  state:
    dev: LABEL=RANCHER_STATE
    wait: true
ssh_authorized_keys:
- XXX

Communications - slack, gitter, discord, irc?

Hi guys,

I was thinking about some community chat to make development easier and enabling us to evaluate some stuff a bit more efficient instead of going back and forward on github issues (not saying that issues shouldn't be there - just that they are not the right medium for 'chatter')

Import paths in `burmilla/trash` is not updated, still pointing to `rancher/trash`

In the main Dockerfile.dapper (the ubuntu one), it builds and installs burmilla/trash using go get github.com/burmilla/trash. However, import paths in the burmilla/trash repository still points to rancher/trash. As a result, the trash binary will be compiled from both code from burmilla/trash and rancher/trash. If code rancher/trash changes, the build process might break.

This is at least an inconsistency. Do we treat rancher/trash as our official upstream? Or we want to go full branch off and use everything from github.com/burmilla (we can still optionally keep tracking updates on rancher, but we need to update all import path).

Other go-gettable build tools (such as the dapper forked repo) have similar issues.

Another higher level thing is that the build process currently fetches a lot of stuff from the Internet, mostly without checking against any hashes. IMHO, this is a huge reliability -- and even security -- issue. Although most channels and fetching-sources can be considered trustworthy, many of them are quite mutable (and it is not unheard of that attackers might be able to poison trusted software distribution channels).

Failure example: burmilla/os-kernel@6a6748a
(and rancher is still ignoring my pr: rancher/dapper#93 ; I suspect the project is dying..)

So folks, a high level question: is it a desirable goal to build as much as possible from source (with a fixed set of toolchain docker images) without Internet access?

Unable to mount NFS

BurmillaOS Version: (ros os version)
v1.9.0

Where are you running BurmillaOS? (docker-machine, AWS, GCE, baremetal, etc.)
Proxmox KVM

Which console you use (default, ubuntu, centos, etc..)
default

Do you use some service(s) which are not enabled by default?
enabled qemu-guest-agent
enabled volume-nfs

Please share copy of your cloud-init (remember remove all sensitive data first)

hostname: burmilla-docker
mounts:
- - 192.168.1.10:/mnt/zfs-spin-storage
  - /mnt/zfs-spin-storage
  - nfs4
  - ""
rancher:
  console: default
  environment:
    EXTRA_CMDLINE: /init
  network:
    dns:
      nameservers:
      - 192.168.1.1
    interfaces:
      eth0:
        address: 192.168.1.15/24
        dhcp: false
        gateway: 192.168.1.1
  services_include:
    qemu-guest-agent: true
    volume-nfs: true
  state:
    dev: LABEL=RANCHER_STATE
    wait: true
  upgrade:
    url: https://raw.githubusercontent.com/burmilla/releases/v1.9.x/releases.yml

$ system-docker logs console

FINISHED: /sbin/agetty --noclear tty4 linuxtime="2020-12-25T03:11:06Z" level=error msg="Networking not available to load resource"

time="2020-12-25T03:11:06Z" level=error msg="Networking not available to load resource"

mount: /mnt/zfs-spin-storage: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program.

time="2020-12-25T03:11:06Z" level=error msg="Failed to mount /mnt/zfs-spin-storage: exit status 32"

[            ] respawn:info: respawn BurmillaOS
built: '2020-12-14T03:55:31Z', v1.9.0
respawn BurmillaOS

Mount has no problem on a standard ubuntu server. Haven't been able to figure this out.

Should I be able to mount this directly from console? Looks like the same error.

rancher@burmilla-docker:/mnt$ sudo mount -t nfs4 -vvvvvv 192.168.1.10:/mnt/zfs-spin-storage /mnt/zfs-spin-storage
mount: /mnt/zfs-spin-storage: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program

Documentation needs navigation

RancherOS documentation have been copied and update to use term BurmillaOS on https://github.com/burmilla/burmilla.github.io
Those files are using GitHub markup and they are published as GitHub Pages to https://burmillaos.org
Issue however is that when I removed Rancher layout from documentation we lost side navigation which why it is very hard find anything from those documents.

That why we should investigate how to implement navigation to GitHub Pages.

Hostname in /etc/hostname is incorrect

BurmillaOS Version: (ros os version)
v1.9.1-rc1

Where are you running BurmillaOS? (docker-machine, AWS, GCE, baremetal, etc.)
Nutanix AHV

Which processor architecture you are using?
amd64

Not sure yet it if this is bug on Burmilla or just issue on way how we deploy these servers but I noticed that after a while /etc/hostname value ends up to be "burmilla"

$ hostname && cat /etc/hostname
olli-test.lab.local
burmilla

Have seen this only on latest RC so far. Changed between it and latest release version can be seen on v1.9.0...v1.9.1-rc1

We need new name (and logo) for community maintained Rancher OS

As far I'm aware of all Rancher OS components are using Apache License 2.0 license which means that we can create community maintained version of Rancher OS but we need rename project as Rancher Labs, Inc own trademark "Rancher".

Directly quote from license file:

Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.

Any ideas about new name?

You can also upvote others proposals by giving 👍 for those comments.

Remove rancheros from boot menu

Hi,
I've just upgraded from rancherOs 1.5.7 quite smoothly, everything seems to work as expected 👍 and I already purged all the unused rancher images

In the boot menu I still see rancherOS tho, can you tell me how to remove it?

Edit: since I'm here, what's the correct way to rename/migrate the "rancher" user?

Thanks!

Kernel and iSCSI parameters are not optimal

BurmillaOS supports kernel parameters changes with sysctl and boot parameters but currently we have only one sysctl setting set by default:

os/os-config.tpl.yml

Lines 98 to 99 in cea643e

    
           sysctl: 
        
             fs.file-max: 1000000000

However problem is that Linux kernel defaults are made with idea that they works on all possible uses cases and are not that why optimal for purpose build operating systems like BurmillaOS

Proposal of changes
We have used these to sysctl settings so far on our environments:

vm.max_map_count: 262144 which is needed by ElasticSearch https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html
fs.inotify.max_user_watches: 1048576 which is needed by prometheus/cadvisor google/cadvisor#1581

afaik those does not have any drawbacks so I propose that we include those to default settings.

Another interesting source for kernel and iSCSI optimizations is Nutanix guidance that how to configure Linux servers to get maximal performance out of them https://portal.nutanix.com/page/documents/solutions/details/?targetId=BP-2105-Linux-on-AHV:BP-2105-Linux-on-AHV

I propose that we take these sysctl settings from it:

Settings	Value	Purpose
vm.overcommit_memory	1	Disables memory overcommit handling.
vm.dirty_background_ratio	5	As a percentage. Contains the number of pages at which the background kernel flusher threads start writing out dirty data.
vm.dirty_ratio	15	As a percentage. Contains the number of pages at which a process that is generating disk writes starts writing out dirty data itself.
vm.dirty_expire_centisecs	500	This tunable defines when dirty data is old enough to be eligible for writeout by the kernel flusher threads.
vm.dirty_writeback_centisecs	100	The kernel flusher threads periodically wake up and write old data out to disk. This tunable expresses the interval between those wakeups.
vm.swappiness	0	This tunable defines how aggressively the kernel swaps memory pages. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high-water mark in a zone.

These iSCSI (/etc/iscsi/iscsid.conf) settings:

node.session.timeo.replacement_timeout = 120
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 10
node.session.cmds_max = 2048
node.session.queue_depth = 1024
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 1048576
node.session.iscsi.MaxBurstLength = 16776192
node.conn[0].iscsi.MaxRecvDataSegmentLength = 1048576
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 1048576

And grub parameters:

transparent_hugepage=never as I seen that underload also khugepaged starts to waste CPU.
scsi_mod.use_blk_mq=1 as there is two options and our kernel version supports this one.

Documentation should describe supported/non-supported use cases

Currently it is still bit unclear that which use case will be supported by BurmillaOS and key driver to define scope is feedback given on #6

However I think that we can say for sure that:

These use cases are not supported:

Kubernetes/K3s (because k3OS is made for those use cases)
Rancher 2.x (because we do not support Kubernetes)
Other Kubernetes specific tools

These use cases are supported:

Standalone Docker containers (docker run / docker create)
Multi-container Docker applications (docker-compose)
Docker Swarm mode (docker stack deploy / docker service)

Also it is worth to mention that with "not supported" I mean that users are free to use BurmillaOS for those use cases if that works but any issues related to those will be considered to be on low priority.

Change restart/shutdown logs

When doing sudo poweroff or sudo reboot the logs are not displayed correctly, nothing is understood.
The process logs add dots as they are executed which causes the display to be garbled.

Openstack image

Will an openstack image be available? The docs seemed to indicate that there would be, but I'm not seeing one in the releases.

Fresh RancherOS to BurmillaOS wrong console

Starting from a clean Installation of RancherOS 1.5.6 and following the upgrade instructions listed in the release: https://github.com/burmilla/os/releases/tag/v1.9.0-rc1

I cannot change the console:

> sudo ros console list
current  default
> ros console switch debian
FATA[0000] ubuntu is not a valid console

Booting back to the RancherOS using executing ros switch console and back to burmilla "fixed" it

This was done with an empty cloud config besides the ssh keys

Floating IP configuration in burmilla OS cluster

Hello there!
It would be nice to add a package to configure a floating IP for a burmilla cluster in a simple way.
For example adding keepalived inside os to be able to set a floating IP for the cluster easier.
What do you think about this feature?
Thanks!

Config syslinux does point to rancher

While testing commands while migrating to Hugo:

sudo ros config syslinux
Unable to find image 'rancher/os-console:v1.9.0-rc1' locally
system-docker: Error response from daemon: manifest for rancher/os-console:v1.9.0-rc1 not found.
See 'system-docker run --help'

Out of Memory situation is not handled correctly

This issue also exists on RancherOS but I think that we can fix it here.

Currently it quite easy overload system on way that even admin cannot login anymore and troubleshoot problem.

Steps to reproduce

Create small VM (I used 1 CPU + 1 GB RAM, no swap partition)
Start new containers until system runs out of memory:

for number in {1..300}
do
  docker run -d nginx
done

See that it is not possible to connect with SSH and if you manage login from console it is still almost impossible to use any tools.

Also kswapd0 process starting to use lot of CPU time even when there is no swap on system:

Why this happens
BurmillaOS uses system-docker + user docker combination and out of memory settings are not optimized correctly.

Docker it selves have some logic which makes sure that containers gets killed before it https://docs.docker.com/config/containers/resource_constraints/ However that affects only system-dockerd process. User docker have same priority than containers running top of it. You can verify that by checking process PIDs with command ps -Af and checking those adjusted score from /proc/<PID>/oom_score_adj files.

Second problem is that we OOM killer does not reverse enough memory for new processes. Based on https://www.kernel.org/doc/Documentation/sysctl/vm.txt normally it should be possible to reserve memory for admin users with admin_reserve_kbytes setting but looks that on BurmillaOS we need to actually use user_reserve_kbytes setting. I assume that it is because we run also console inside of container.

Proposal of changes
Based on my tests so far it looks like that situation can be improved a lot by importing config like this with sudo ros config merge -i config.yml

rancher:
  docker:
    extra_args: [--oom-score-adjust, -250]

which makes sure that user docker have higher priority than containers on top of it.

and by sysctl changes like these which make sure that enough memory will be kept free for admin (64 MB instead of 8 MB which is default value):

echo vm.user_reserve_kbytes=65536 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

After those I was not able to crash the system. It still gets slow and example docker commands often gives "out of memory" errors but still SSH to system and smaller command line tools works fine.

Missing assets from the release: vmlinuz, initrd, rootfs.tar.gz

Rancher/os release these assets with theirs releases: vmlinuz, initrd, rootfs.tar.gz
These files are used for iPXE installation. Is it possible to add them to your released assets too?

Update v1.9.x to Docker 20.10.x

If I understand https://www.docker.com/blog/extending-support-cycle-docker-community-edition/ correctly it means that Docker 19.03.x versions are supported 7 months after 20.10.0 release which means that so on July we should release v1.9.x version with latest Docker 20.10.x.

Open issues which are targetted to be fixed on Docker 20.10.6 can be found from https://github.com/moby/moby/issues?q=is%3Aopen+is%3Aissue+milestone%3A20.10.6 and especially moby/moby#41775 is critical to verify if that happens on BurmillaOS too.

Does BurmillaOS need newer kernel version and how it can be provided?

Rancher OS is currently using 4.14.x kernels which will get security patches until January 2024. That why there is no urgent need switch to newer releases.

However I would like to get comments about what are new features on newer kernels which would be useful for Rancher OS?

Kernel build process is described on https://rancher.com/docs/os/v1.x/en/installation/custom-builds/custom-kernels/ and I already got 5.4 build process working on tree https://github.com/rancher-os-community/os-kernel/tree/5107e0728769ea4afceff06cb9bf21b20c14d55d (automatic build using GitHub actions) and it pushed release to https://github.com/rancher-os-community/os-kernel/releases/tag/v5.4.61-rancheroscommunity but boot fails with that one so we need figure out which changes are needed to kernel configuration.

Feature Request: Support for MIPS64el architecture

I noticed that someone was asking about how to port RancherOS to MIPS64el on rancher#3027 and out of curiosity I did investigate it a bit and added initial configs for it to os-base, os-initrd-base and os-kernel when I was working on those and tried to get new buildroot version working (that is not ready like you can see from #12).

However, now it looks to be we might have potential #2 (comment) maintainer for this use case so we can consider finalize that work.

High level TODO list:

Finalize os-base build configuration
Finalize os-initrd build configuration
Finalize os-kernel build config and setup build environment for it.
Add MIPS64el support to system-docker
Implement MIPS64el CI to os-services (at least for user docker)
Add OS build scripts for MIPS64el to this repository.

It is also worth to mention that Debian supports that architecture and here is some info from them https://www.debian.org/ports/mips/

BurmillaOS :)

Hi,
I'm still using RancherOS and happy to see active developed and maintenanced BurmillaOS! 👍
After some backups I'll try to migrate from RancherOS 1.5.6 to BurmillaOS :)

RancherOS was server focused, but it would be also a great desktop linux distribution. Do you plan to add some desktop related features (kernel and modules)?

Update to buildroot 2020.02.8

Currently os-base and os-initrd-base uses quite old buildroot 2018.02.11-1.

We should update to latest LTS version which currently is 2020.02.8

Full change log between those versions:
https://github.com/buildroot/buildroot/blob/00e80cb1769047ad8c768d35003ae68fb4c3b0f0/CHANGES#L643-L3277

I have already made test configs to os-base/os-initrd-base with latest stable (not LTS) version 2020.08.1 but looks that something went wrong on config updates because OS build with that one will end up to Kernel panic on boot.

Add to releases a format supported by Digital Ocean

https://www.digitalocean.com/docs/images/custom-images/#image-requirements

Image Requirements

Images you upload to DigitalOcean must meet the following requirements:

Operating system. Images must have a Unix-like OS.

File format. Images must be in one of the following file formats:
Raw (.img) with an MBR or GPT partition table
qcow2
VHDX
VDI
VMDK

Size. Images must be 100 GB or less when uncompressed, including the filesystem.

Filesystem. Images must support the ext3 or ext4 filesystems.

cloud-init. Images must have cloud-init 0.7.7 or higher, cloudbase-init, coreos-cloudinit, ignition, or bsd-cloudinit installed and configured correctly. If your image's default cloud-init configuration lists the NoCloud datasource before the ConfigDrive datasource, Droplets created from your image will not function properly.
Click here to display detailed cloud-init instructions.

SSH configuration. Images must have sshd installed and configured to run on boot. If your image does not have sshd set up, you will not have SSH access to Droplets created from that image unless you recover access using the Droplet console.

You can also upload a custom image that meets the above criteria as a compressed gzip or bzip2 file.

Cluster health check failed: cluster agent is not ready problem

BurmillaOS Version: (ros os version)
v1.9.0

Where are you running BurmillaOS? (docker-machine, AWS, GCE, baremetal, etc.)
ESXi-6.5.0

Which processor architecture you are using?
x64

Do you use some extra hardware? (GPU, etc)?
No

Which console you use (default, ubuntu, centos, etc..)
default

Do you use some service(s) which are not enabled by default?
No

Have you installed some extra tools to console?
No

Do you use some other customizations?
No

Please share copy of your cloud-init (remember remove all sensitive data first)

rancher:
  environment:
    EXTRA_CMDLINE: /init
  services_include:
    open-vm-tools: true
  state:
    dev: LABEL=RANCHER_STATE
    wait: true
ssh_authorized_keys:
- ssh-rsa

Hello,

I've tried to install a clean version of latest Rancher, but I'm still getting error: Cluster health check failed: cluster agent is not ready when adding a new custom cluster. Any idea where could be a problem? I've also tried to install it on Debian and that was without any problems.

Thank you

Wanted: Maintainers

If we want keep Rancher OS alive by the community we will need 5-10 maintainers (I can be one of those but I don't want to be only one).

Most important task where we need maintainers is to have some one review, comment and approve pull requests when we get them. Anyone who is able to review code and is willing to sacrifice some of their time for better good can be maintainer.

We will also need agree pull request approval practice. My proposal is that anyone can create pull request and all pull requests much be reviewed by at least one maintainer and it must be different person than who created pull request (simple peer review practice to avoid human errors).

So anyone who is interest to be maintainer to this project please leave a comment.

Should BurmillaOS support kubernetes?

I open this issues so that they give arguments that why we should support kubernetes in the project.
Specify concrete cases of use so we can make the best decision and if you give affirmative it helps us to make the documentation in a future.

Add docker-compose by default

And if possible, would be great to have docker-compose as part of the OS available as well

The user @x-jokay proposed in the issues #6 add by default docker-compose in BurmillaOS
We could create an option in the cloud-config.yml to enable docker-compose

How/where you use Rancher OS? Please share your configuration?

Rancher OS supports quite a lot of different kind of platforms and configurations. I don't want maintain anything which no one is using so please comment to this issue using template below (copy/paste it to comment and answer to questions) and share how you currently using Rancher OS and/or you are planning to use community maintained version if that configuration would be supported.

I will then based on this feedback remove those non-used parts at least from first version and enable them back later if someone request about them later.

**Where are you running/planning to run Rancher OS/Burmilla OS? (docker-machine, AWS, GCE, baremetal, etc.)**

**Which processor architecture you are using?**

**Do you use some extra hardware? (GPU, etc)?**

**Which console you use (default, ubuntu, centos, etc..)**

**Do you use some service(s) which are not enabled by default?**

**Have you installed some extra tools to console?**

**Do you use some other customizations?**

**Please share copy of your cloud-init (remember remove all sensitive data first)**
<replace with sudo ros config export output>

EDIT: Decisions made so far:

BurmillaOS development happens on two tracks (decided on #5 (comment))
- Version 1.9.0 will be running latest 4.14.x kernel and be fully compatible with RancherOS and production ready.
- Version 2.0.0 will be running next LTS kernel (most probably 5.9.x) and Docker 20.10.x. It also might not be fully production ready because of big jump on versions. Production readiness comes then maybe on 2.1.0, etc.
Debian console will be set as default and only console to simplify maintenance but still keep mostly used features (decided on #9)

Do we want to have subscriber service (like on RancherOS)?

RancherOS 1.5.1 added subscriber service like this:

There is now a built-in service for system upgrades that requires access to the internet. By default, it can detect system updates and downloads the required files. It will not automatically apply the patch. If you want to completely disable this feature, just run ros config set rancher.upgrade.policy none

It was added by rancher#2667 and I assume that they used it to get understanding that how widely RancherOS have been used. It collects processor architecture, system UUID and OS version with these commands and reports them to Rancher:

uname -m
sudo cat /sys/class/dmi/id/product_uuid
sudo ros -v | awk '{print $2}'

Besides of data collection it also will pre-download OS upgrades or even do upgrades automatically if user have enabled it ros config set rancher.upgrade.policy auto

Currently subscriber service is disabled from BurmillaOS beta versions but similar data would be useful for its maintainers too.
What others think, are those infos anonymous enough that we can have enabled by default (and users will be still able to disable it if they want)?

What comes to auto download/upgrade feature. I don't want to have one big "master switch" but instead of it we should make that URL and schedule configurable so users can use it to mass deploy upgrades when they want.

Nvidia GPU support?

Hi,

Does anyone know if it's at all possible to install the nvidia drivers + nvidia-container-runtime such that I might be able to use the GPU from docker containers?
It seems there's some old stuff in the rancher repos:

But it's quite hard to figure out how much of that is still relevant since some comments suggests "runtime isn't required anymore, the nvidia gpu support is baked into Docker 19.03"

So if anyone could point me in the right direction I'd be grateful.

Thanks in advance.

Feature Request: make BurmillaOS replacing Rancher with Hetzner Cloud

With Hetzner Cloud (a European mid-size "cloud provider"), you can boot your VPS on RancherOS.
It would be nice to make BurmillaOS known as RancherOS fork. The name BurmillaOS is not very meaningful without connection with Rancher (Rancher was a well-known and reassuring brand). It could good be good for BurmillaOS.

Update Docker version and move from rancher/os-docker to burmilla/os-docker

Capturing this here until it's no longer needed...

RancherOS Version: (ros os version)
1.5.6

Where are you running RancherOS? (docker-machine, AWS, GCE, baremetal, etc.)
NA

Courtesty of @olljanat @ rancher#3000 (comment)

I did build now later Docker versions than currently are available on official version. You can use those like this.

First set new repository location:
sudo ros config set rancher.repositories.docker.url https://raw.githubusercontent.com/rancher-os-community/os-services/master
Then you can switch to latest Docker using commands 19.03.13:
sudo system-docker pull rancheroscommunity/os-docker:19.03.13
sudo system-docker tag rancheroscommunity/os-docker:19.03.13 rancher/os-docker:19.03.13
sudo ros engine switch docker-19.03.13
or if you want to test Docker 20.10.0-beta1 version you can do it with commands:
sudo system-docker pull rancheroscommunity/os-docker:20.10.0
sudo system-docker tag rancheroscommunity/os-docker:20.10.0 rancher/os-docker:20.10.0-beta1
sudo ros engine switch docker-20.10.0-beta1

[Question] Is RancherOS / BurmillaOS eat up disk space over time?

At the moment I'm running latest RancherOS and will migrate to BurmillaOS soon.

Last years it feels like RancherOS eat up my disk space and maybe some old / unneeded files not removed during os update?

Removed all stopped containers, images and volumes in user-docker and system-docker, but still it seems need to much disk space for a small set running user-docker / swarm services?

Filesystem                Size      Used Available Use% Mounted on
overlay                  46.7G     28.2G     16.0G  64% /

If missing BurmillaOS should clean up old data on update / migration?

Checked host rootfs from inside of a privileged system-docker container

sysdocker run --rm -ti -v /=/host --privileged alpine sh

checking disk usage. /host/home contains the rancher user home directory and data.

/ # du -sh /host/*
1.2G    /host/boot
0       /host/dev
768.0K  /host/etc
5.3G    /host/home
0       /host/lib
16.0K   /host/lost+found
4.0K    /host/media
16.0K   /host/mnt
16.0K   /host/opt
0       /host/proc
8.0K    /host/root
2.2M    /host/run
0       /host/sbin
0       /host/sys
4.0K    /host/tmp
0       /host/usr
177.7M  /host/usr-v1.0.1
183.2M  /host/usr-v1.0.3
197.3M  /host/usr-v1.1.0
202.3M  /host/usr-v1.1.3
102.8M  /host/usr-v1.2.0
182.8M  /host/usr-v1.4.0
183.2M  /host/usr-v1.4.2
215.4M  /host/usr-v1.5.1
210.9M  /host/usr-v1.5.2
213.8M  /host/usr-v1.5.4
224.7M  /host/usr-v1.5.5
223.8M  /host/usr-v1.5.6
20.2G   /host/var

/boot

/host # ls -lh boot/
total 1G     
-rw-r--r--    1 root     root           1 Dec 21  2016 append
-rw-r--r--    1 root     root         105 Jul 29  2020 global.cfg
drwxr-xr-x    5 root     root        4.0K Dec 21  2016 grub_backup
-rw-r--r--    1 root     root       26.7M Jun  5  2016 initrd-v0.4.5-rancheros
-rw-r--r--    1 root     root       35.4M Sep  6  2016 initrd-v0.5.0-rancheros
-rw-r--r--    1 root     root       35.8M Sep  6  2016 initrd-v0.6.0-rancheros
-rw-r--r--    1 root     root       35.8M Sep  2  2016 initrd-v0.6.0-rc7-rancheros
-rw-r--r--    1 root     root       35.8M Sep 24  2016 initrd-v0.6.1-rancheros
-rw-r--r--    1 root     root       35.8M Sep  7  2016 initrd-v0.6.1-rc1-rancheros
-rw-r--r--    1 root     root       35.6M Dec 21  2016 initrd-v0.7.1-rancheros
-rw-r--r--    1 root     root       36.1M Mar  3  2017 initrd-v0.8.1
-rw-r--r--    1 root     root       34.4M May 10  2017 initrd-v1.0.1
-rw-r--r--    1 root     root       35.6M Jul 14  2017 initrd-v1.0.3
-rw-r--r--    1 root     root       38.8M Sep  6  2017 initrd-v1.1.0
-rw-r--r--    1 root     root       39.2M Jan 15  2018 initrd-v1.1.3
-rw-r--r--    1 root     root       49.0M Feb  6  2018 initrd-v1.2.0
-rw-r--r--    1 root     root       63.5M Jun  2  2018 initrd-v1.4.0
-rw-r--r--    1 root     root       64.0M Nov  7  2018 initrd-v1.4.2
-rw-r--r--    1 root     root      108.3M Feb 15  2019 initrd-v1.5.1
-rw-r--r--    1 root     root      106.7M Jun 18  2019 initrd-v1.5.2
-rw-r--r--    1 root     root      109.6M Sep  6  2019 initrd-v1.5.4
-rw-r--r--    1 root     root      120.4M Dec 31  2019 initrd-v1.5.5
-rw-r--r--    1 root     root      119.6M Jul 29  2020 initrd-v1.5.6
-rw-r--r--    1 root     root        1.3K Jul 29  2020 linux-current.cfg
-rw-r--r--    1 root     root        1.3K Dec 31  2019 linux-previous.cfg
-rw-r--r--    1 root     root       12.4K Jul 29  2020 rancher.png
drwxr-xr-x    2 root     root        4.0K Mar  3  2017 syslinux
drwxr-xr-x    2 root     root        4.0K Dec 21  2016 syslinux_backup
-rw-r--r--    1 root     root        5.3M Jun 18  2019 vmlinuz-4.14.122-rancher
-rw-r--r--    1 root     root        5.3M Jul 29  2020 vmlinuz-4.14.138-rancher
-rw-r--r--    1 root     root        5.3M Jun  2  2018 vmlinuz-4.14.32-rancher2
-rw-r--r--    1 root     root        5.3M Nov  7  2018 vmlinuz-4.14.73-rancher
-rw-r--r--    1 root     root        5.3M Feb 15  2019 vmlinuz-4.14.85-rancher
-rw-r--r--    1 root     root        4.7M Mar  3  2017 vmlinuz-4.9.12-rancher
-rw-r--r--    1 root     root        4.7M May 10  2017 vmlinuz-4.9.24-rancher
-rw-r--r--    1 root     root        4.7M Jul 14  2017 vmlinuz-4.9.34-rancher
-rw-r--r--    1 root     root        4.7M Sep  6  2017 vmlinuz-4.9.45-rancher
-rw-r--r--    1 root     root        4.7M Jan 15  2018 vmlinuz-4.9.75-rancher
-rw-r--r--    1 root     root        4.8M Feb  6  2018 vmlinuz-4.9.78-rancher2
-rw-r--r--    1 root     root        3.6M Jun  5  2016 vmlinuz-v0.4.5-rancheros
-rw-r--r--    1 root     root        3.9M Sep  6  2016 vmlinuz-v0.5.0-rancheros
-rw-r--r--    1 root     root        4.5M Sep  6  2016 vmlinuz-v0.6.0-rancheros
-rw-r--r--    1 root     root        4.5M Sep  2  2016 vmlinuz-v0.6.0-rc7-rancheros
-rw-r--r--    1 root     root        4.5M Sep 24  2016 vmlinuz-v0.6.1-rancheros
-rw-r--r--    1 root     root        4.5M Sep  7  2016 vmlinuz-v0.6.1-rc1-rancheros
-rw-r--r--    1 root     root        4.5M Dec 21  2016 vmlinuz-v0.7.1-rancheros

5.1G    /host/var/lib/system-docker

burmilla / os Goto Github PK

os's People

Stargazers

Watchers

Forkers

os's Issues

Thx

Recommend Projects

Recommend Topics

Recommend Org