chimera-linux / chimera-live Goto Github PK

Running ./mklive-image.sh -b gnome on x86_64 it appears linux-lts package must be installed directly instead of linux:

However even with adding -p linux-lts to args it fails on linux-modules-zfs:

I guess it got renamed to linux-lts-zfs-bin? sed 's/linux-modules-zfs/linux-lts-zfs-bin/' -i mklive-image.sh at least seems to make it work again.

Since I'm trying the command in a Chimera VM it appears mtools is also broken presumably due to some CFI or similar hardening options:


(Sorry for the screenshots, would be nice if virt-manager stuff was integrated in GNOME images by default and allowed for copy-paste etc)

Probably good to make sure the rest of the scripts are still functional too :)

from the verbose output i cant see that it has identified that its a zfs pool yet, and https://chimera-linux.org/docs/installation/zfs only notes about the old grub config caveat finding the root

# grub-install --efi-directory=/efi -v
[...]
grub-install: info: no LVM signature found.
grub-install: info: Partition 0 starts from 2048.           [EFI]
grub-install: info: Partition 1 starts from 411648.       [SWAP]
grub-install: info: Partition 2 starts from 21383168.  [ZFS]
grub-install: info: drive = 0.
grub-install: info: the size of hostdisk//dev/sda is 234441648.
Illegal instruction

hardware is Intel C2550 CPU so question is if its something like the x86_64 image is built for x86_64-v2 or v3 subarchitecture that is messing with me? or that the old-atom is missing some instruction in the instruction-set?

to rule out zfs as the culprit i'm going to redo the install on ext4 root and see if same issue hits.

used image 'chimera-linux-x86_64-LIVE-20221115-base.iso'

Hello. I interested in chimera-linux because that have a simple & very great targets Implementation. I try it today but seems like new image (chimera-linux-x86_64-LIVE-20221012-base.iso) has broken! I mean that stuck in both EFI & Legacy mode on booting kernel step. For more info I try chimera with older image (chimera-linux-x86_64-20220912-base.iso) and everything is good!
I attach images & videos about this issue.

Images checksums:

1e61ff05c7d1bcc6777c94fa4d1b157275722cf83da82c3656b4acec92883fa1  chimera-linux-x86_64-20220912-base.iso
aa7913140085131028fc670d1a1d07eda470686cab06ebb9c39ff1bcfe7e9a8f  chimera-linux-x86_64-LIVE-20221012-base.iso

Runned on Real hardware:
AMD Ryzen 5 3500x
NVIDIA Geforce GTX 1650
ASUS PRIME B450M-A

Images writed into a USB stick. with dd if=IMAGE of=/dev/sdc bs=1M

Images & Videos:
pending

I'm trying to install chimera in purely console/server mode using qemu-system-aarch64. Is it possible ?

Everything seems to work until here:

...
[  OK  ] syslog-ng
[  OK  ] local.target
[  OK  ] pre-network.target
[  OK  ] init-local.target
[  OK  ] dbus-prepare
[  OK  ] dhcpcd
[  OK  ] network.target
[  OK  ] turnstiled
[  OK  ] chrony-dir
[  OK  ] chronyd
[  OK  ] dbus
[  OK  ] polkitd
[  OK  ] elogind

After the elogind message things seem to "hang". There are no errors.

My guess is the flow shifts to a graphical interface after this point ??

I'm using the chimera-linux-aarch64-LIVE-20230915-base.iso image with u-boot.bin that I compiled myself.

I am trying to build a live iso inside an alpine linux container and it complains about read only variables... The instructions for using mklive aren't very clear either.

-> doas nerdctl run --rm -it -w /src -v $(pwd):/src alpine:edge
/src # ./mklive.sh -- -f theos
./mklive.sh: readonly: line 16: PROGNAME: is read only

How about supplying a Docker image? That's the quickest and easiest way for most people these days to test out a distribution that whose uniqueness lies in userland.

Following the install docs and using ext4 as the root filesystem as suggested will result in:

ERROR: The target directory is not empty.

The just formatted ext4 filesystem already has one directory inside removing which makes the install process possible:

rmdir /media/root/lost+found

The script should perhaps ignore this directory if it's the only thing on the rootfs; don't know if similar cases exist for other plausible root filesystems.

How about adding the --help and -h options to chimera-live-install?

Greetings! Love this project. I have run into a strange quirk that I don’t know how to fix. I was wondering if anyone here might be able to help me out. As follows:

When I boot my Chimera Linux VM, it goes through the boot sequence, then dumps me at a console login prompt. I enter my username and password and the login goes through. Shortly thereafter, the screen is taken over by the GDM greeter, and I log in again to start GNOME. (Note that GDM appears after a period of time whether or not I log into the console; the timing is just that I can get to a shell before GDM takes over.)

I want the GDM greeter to appear immediately. My first thought on how to do this is to disable getty. Unfortunately, I have no idea how to disable agetty under dinit. There are multiple service definitions, so a simple dinitctl stop agetty won’t work. Furthermore, that kind of change would not survive a reboot AFAIK. I have read the dinitctl manpage, but can find no command there for disabling a service so it won’t relaunch on reboot. I’d rather not simply delete the agetty files completely. Thanks so much!

I was installing Chimera for the first time and chimera-bootstrap failed with an error
WARNING: updating and opening https://repo.chimera-linux.org/current/main: temporary error (try again later) ERROR: unable to select packages: chimerautils (no such package): required by: world[chimerautils] ERROR: initial installation failed

This creates the /proc and /var in /mnt/root that need to be removed.

A solution I found was to rm /etc/resolv.conf and touch /etc/resolve.conf (couldn't write to it even in super user) and add a nameserver (ex: 1.1.1.1) and then restart networkmanager dinitctl restart networkmanager I then updated apk apk update. Then I could bootstrap again.

Before you enter the chroot, make sure you copy the resolv.conf over cp /etc/resolv.conf /mnt/root/etc/resolv.conf

Inits that could be considered are:
66
Sysvinit
Runit(This is the one I use at VoidLinux)
OpenRC(I like this one the most)