You are not logged in.
Yes.
I just ran into the very same problem. Changing line 333 in refractasnapshot from:
(cpio -i ; zcat | cpio -i) < "$initrd_image"to this:
cpio -i < "$initrd_image"succeeds.
I don't know why that 'zcat' is there when initrd is uncompressed.
Oh oh ... thanks, that makes it work ![]()
Could somebody give me a hint how to set up a minimal devuan chroot environment with debootstrap? I can install debian:
# debootstrap --variant=minbase stretch ./chroot http://deb.debian.org/debian
[...]
I: Base system installed successfully.
But I cannot install devuan:
# debootstrap --variant=minbase chimaera ./chroot http://deb.devuan.org/devuan
I: Retrieving InRelease
I: Checking Release signature
I: Valid Release signature (key id 72E3CB773315DFA2E464743D94532124541922FB)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://deb.devuan.org/devuan...
I: Retrieving apt 2.2.4+devuan1
I: Validating apt 2.2.4+devuan1
I: Retrieving libapt-pkg6.0 2.2.4+devuan1
I: Validating libapt-pkg6.0 2.2.4+devuan1
I: Retrieving base-files 11.1+devuan3
I: Validating base-files 11.1+devuan3
I: Retrieving devuan-keyring 2022.09.04
I: Validating devuan-keyring 2022.09.04
I: Retrieving libeudev1 3.2.9-10~chimaera1
I: Validating libeudev1 3.2.9-10~chimaera1
I: Retrieving init-system-helpers 1.60+devuan1
I: Validating init-system-helpers 1.60+devuan1
I: Retrieving bootlogd 2.96-7+devuan2
I: Validating bootlogd 2.96-7+devuan2
I: Retrieving initscripts 2.96-7+devuan2
I: Validating initscripts 2.96-7+devuan2
I: Retrieving sysv-rc 2.96-7+devuan2
I: Validating sysv-rc 2.96-7+devuan2
I: Retrieving sysvinit-core 2.96-7+devuan2
I: Validating sysvinit-core 2.96-7+devuan2
I: Retrieving sysvinit-utils 2.96-7+devuan2
I: Validating sysvinit-utils 2.96-7+devuan2
I: Retrieving bsdutils 1:2.36.1-8+devuan2
I: Validating bsdutils 1:2.36.1-8+devuan2
I: Retrieving libblkid1 2.36.1-8+devuan2
I: Validating libblkid1 2.36.1-8+devuan2
I: Retrieving libmount1 2.36.1-8+devuan2
I: Validating libmount1 2.36.1-8+devuan2
I: Retrieving libsmartcols1 2.36.1-8+devuan2
I: Validating libsmartcols1 2.36.1-8+devuan2
I: Retrieving libuuid1 2.36.1-8+devuan2
I: Validating libuuid1 2.36.1-8+devuan2
I: Retrieving mount 2.36.1-8+devuan2
I: Validating mount 2.36.1-8+devuan2
I: Retrieving util-linux 2.36.1-8+devuan2
I: Validating util-linux 2.36.1-8+devuan2
I: Chosen extractor for .deb packages: dpkg-deb
I: Extracting base-files...
I: Extracting libeudev1...
I: Extracting init-system-helpers...
I: Extracting bootlogd...
I: Extracting initscripts...
I: Extracting sysv-rc...
I: Extracting sysvinit-core...
I: Extracting sysvinit-utils...
I: Extracting bsdutils...
I: Extracting libblkid1...
I: Extracting libmount1...
I: Extracting libsmartcols1...
I: Extracting libuuid1...
I: Extracting mount...
I: Extracting util-linux...
W: Failure trying to run: chroot "/tmp/chroot" dpkg-deb -f Version
W: See /tmp/chroot/debootstrap/debootstrap.log for details
W: Failure trying to run: chroot "/tmp/chroot" mount -t proc proc /proc
W: See /tmp/chroot/debootstrap/debootstrap.log for details
W: Failure trying to run: chroot "/tmp/chroot" mount -t sysfs sysfs /sys
W: See /tmp/chroot/debootstrap/debootstrap.log for details
W: Failure trying to run: chroot "/tmp/chroot" /sbin/ldconfig
W: See /tmp/chroot/debootstrap/debootstrap.log for details
/tmp/chroot/debootstrap/debootstrap.log:
chroot: failed to run command 'dpkg-deb': No such file or directory
chroot: failed to run command 'mount': No such file or directory
chroot: failed to run command 'mount': No such file or directory
chroot: failed to run command '/sbin/ldconfig': No such file or directory
(END)
So "dpkg-deb" is missing in the evironment.
Forcing it to the include list also fails:
# debootstrap --variant=minbase --include=dpkg chimaera ./chroot http://deb.devuan.org/devuan
I: Checking Release signature
I: Valid Release signature (key id 72E3CB773315DFA2E464743D94532124541922FB)
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://deb.devuan.org/devuan...
E: Couldn't find these debs: dpkg
Any clue what I missed?
Go to aliexpress.com and search for "RK3288" (ASUS Firefly) or "RK3399" for OrangePi4. Both have bad support (armbian at its best). And you can wonder who would be willing to pay €€€ for these ...
New image for RPi + chimaera + TDE: https://dev1galaxy.org/viewtopic.php?pid=31220#p31220 (no LinuxCNC any more)
I have uploaded a new version of Devuan Chimera + TDE:
Image: https://github.com/zwieblum/devuan-imag … tde.img.xz
sha256: https://github.com/zwieblum/devuan-imag … .xz.sha256
Release Notes: https://github.com/zwieblum/devuan-imag … /README.md
# UID / PWD:
pi / pi
root / < no password >Enjoy ![]()
Screenshot: https://github.com/zwieblum/devuan-imag … pshot2.png (sorry, don't know how to get the img tag working)
I uploaded a new chimaera image for RaspberryPi: https://dev1galaxy.org/viewtopic.php?pid=30913#p30913 - version with TDE will come in some days.
I just uploaded a new chimaera image for RaspberryPi 3A+ / 3B+ / Rpi400. This is a minimal image. It fits fine on a 4GB SD-Card. WiringPi is included, as are the special programs from raspberrypi.org (raspistill, raspi-config ...) - just the right thing to get you started.
Release notes and download link:
https://github.com/zwieblum/devuan-imag … 2021.07.29
direct download link:
https://github.com/zwieblum/devuan-imag … -29.img.xz
another of my proposal was make the trinity desktop the default in devuan but as aways rejected and without interes
The reson given was that the TDE build sould run iside the devuan buildbot environment. As there is not enough manpower to do this (and from the TDE side there's no need to do this) it will not happen in the "near" future.
That is a shame, trinity desktop looks better visually then kde or gnome in my opinion...
Definitly. But it's just 5 lines to install TDE on devuan ![]()
You should get a RPi 3 and try to get chimera running. Fun guaranteed ![]()
Traditional? Is there an other approach? I mean, ok, pure WMs like fvwm or tiling WMs are different ... but DEs? All "modern" DEs simply fall flat when it comes to configurability.
Your screenshots don't show. "This content has been restricted. Using Cloudfare's basic service in this manner is a violation of the Terms of Service ..."
Could you please attach the screenshots to your postings?
Not any difference in EU. Education system is transformed to create consume drones.
Microsoft doesn't care.
I think they care a lot. It's just they care for the wrong reason.
Sorry, due to problems with the LinuxCNC project I removed the images. When I find some spare time I'll upload new Chimaera+TDE images - but without LinuxCNC.
UT99 still works like a charm with the lastest ptches from this year. And "Die Siedler 2" .. ok, dosbox, but it works ![]()
That makes live easier, thank you!
Now I have :
# /etc/modprobe.d/alsa-base.conf
options snd_usb_audio index=0
options snd_hda_intel index=3,2,1 enable=0,0,1This makes the soundblaster (3rd card) the soundcard with index #1 and hides the other 2 builtin cards. I still have to assign uniq indizes to the individual cards, otherwise #0 is gone again.
# cat /proc/asound/cards
0 [CinemaTM ]: USB-Audio - Microsoft® LifeCam Cinema(TM)
Microsoft Microsoft® LifeCam Cinema(TM) at usb-0000:00:1d.0-1.7, high speed
1 [Creative ]: HDA-Intel - HDA Creative
HDA Creative at 0xf3200000 irq 16The fun part of that: with only 2 cards left, chromium can handle exact one input source per card correctly, be it card#0 or card#1. Oh my ... ![]()
Ok, not solved, but there's a workaround for that piece of crap aka chromium:
Make sure the webcam is plugged in at boottime, otherwise alsa card enumeration will assign #0 to some other card. Then make snd_usb_audio card#0 and all other cards "not the default":
# /etc/modprobe.d/alsa-base.conf
options snd_usb_audio index=0
options snd_hda_intel index=-1Then reboot and observe:
$ cat /proc/asound/cards
0 [CinemaTM ]: USB-Audio - Microsoft® LifeCam Cinema(TM)
Microsoft Microsoft® LifeCam Cinema(TM) at usb-0000:00:1d.0-1.8, high speed
1 [MID ]: HDA-Intel - HDA Intel MID
HDA Intel MID at 0xf3120000 irq 37
2 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xf3000000 irq 17
3 [Creative ]: HDA-Intel - HDA Creative
HDA Creative at 0xf3200000 irq 16Now chromium https://meet.jit.si/just-a-room]https:/ … ust-a-room can be started. The preselected mic is still the first input source of the internal soundcard, but by some miracle the usb mic is now selectable and working - at least one of the 12 virtual mics of the single usb mic, usally the second. And what a surprise: the usb mic stays #0 if it's unplugged/replugged.
Now the next question: isn't there a way to reserve #0 for snd_usb_audio, regardless if it's present or not? Assinging a fixed index to snd_hda_intel does not work, as all 3 internal cards are served by that module.
EDIT: Using options snd_hda_intel index=1,2,3 will reserve card #0 for the 4th soundcard or snd_usb_audio - whatever comes first. You might call that a mатрёшка workaround ![]()
I prefer not to build my own kernel - the deb-src for 5.10.28 is gone, as are kernel + headers --> nvidia drivers will not be happy ... and most likely everything with alsa in its name needs to be reverted and rebuilt. Sonds like a doomsday plan to me ![]()
Nop, does not work. linux-headers-5.10.0-0.bpo.5-amd64=5.10.24-1~bpo10+1 would like linux-compiler-gcc-8-x86, which is not available on chimera. Adding beowulf repositories and trying to install that kernel+header results in apt suggesting to kill my system.
Isn't there an archive where I can get the older kernel+headers?
apparmor is not installed, but libapparmor1 - it's pulled in by dbus.
Any idea where I can get the older kernel and headers? I can repackage the kernel from my other machine, but I did not install the headers there (and I need them for nvidia)
Definitly. To be more precise: a clone of users homedirectory running on a devuan that was not upgraded (Kernelpackage 5.10.0-6-amd64 and chromium 89) does not show this problem. Chromium 89 + 5.10.0-7 alsow shows this problem.
/dev/snd/controlC0: samhain 2217 F.... kmix
/dev/snd/controlC1: samhain 2217 F.... kmix
/dev/snd/controlC2: samhain 2217 F.... kmix
/dev/snd/controlC3: samhain 2217 F.... kmixIf that were a problem, chromium could not access card#0, either. Nor could audacity, which works like expected. Killing kmix does not make any difference (well, the device is not accessed by anything then).
My user is in group audio, all sound devices are accessable. Otherwise audacity would not work (see my first post):
$ ll /dev/snd/*
crw-rw----+ 1 root audio 116, 12 7. Jun 08:56 /dev/snd/controlC0
crw-rw----+ 1 root audio 116, 13 7. Jun 08:56 /dev/snd/controlC1
crw-rw----+ 1 root audio 116, 20 7. Jun 08:56 /dev/snd/controlC2
crw-rw----+ 1 root audio 116, 22 7. Jun 09:01 /dev/snd/controlC3
crw-rw----+ 1 root audio 116, 11 7. Jun 08:56 /dev/snd/hwC0D0
crw-rw----+ 1 root audio 116, 7 7. Jun 08:56 /dev/snd/hwC1D0
crw-rw----+ 1 root audio 116, 19 7. Jun 08:56 /dev/snd/hwC2D1
crw-rw----+ 1 root audio 116, 9 7. Jun 09:04 /dev/snd/pcmC0D0c
crw-rw----+ 1 root audio 116, 8 7. Jun 08:56 /dev/snd/pcmC0D0p
crw-rw----+ 1 root audio 116, 10 7. Jun 09:04 /dev/snd/pcmC0D2c
crw-rw----+ 1 root audio 116, 6 7. Jun 08:56 /dev/snd/pcmC1D10p
crw-rw----+ 1 root audio 116, 2 7. Jun 08:56 /dev/snd/pcmC1D3p
crw-rw----+ 1 root audio 116, 3 7. Jun 08:56 /dev/snd/pcmC1D7p
crw-rw----+ 1 root audio 116, 4 7. Jun 08:56 /dev/snd/pcmC1D8p
crw-rw----+ 1 root audio 116, 5 7. Jun 08:56 /dev/snd/pcmC1D9p
crw-rw----+ 1 root audio 116, 15 7. Jun 09:04 /dev/snd/pcmC2D0c
crw-rw----+ 1 root audio 116, 14 7. Jun 09:04 /dev/snd/pcmC2D0p
crw-rw----+ 1 root audio 116, 18 7. Jun 09:04 /dev/snd/pcmC2D1c
crw-rw----+ 1 root audio 116, 17 7. Jun 08:56 /dev/snd/pcmC2D1p
crw-rw----+ 1 root audio 116, 16 7. Jun 09:04 /dev/snd/pcmC2D2c
crw-rw----+ 1 root audio 116, 21 7. Jun 09:04 /dev/snd/pcmC3D0c
crw-rw----+ 1 root audio 116, 1 7. Jun 08:56 /dev/snd/seq
crw-rw----+ 1 root audio 116, 33 7. Jun 08:56 /dev/snd/timer"kmix" uses /dev/controlC* non-exclusively. Killing kmix does not make any difference (as expected).
Does not change anything.
Maybe I did not make myself clear: The problem is not changing the default sound card. The problem is, that chromium cannnot access any mic other than the ones on card#0 (see the error messages in my first posting).