Beowulf Beta is here!

dev-1-dash-1 · 2020-05-19 21:08:36

fsmithred wrote:

Now we're cross-posting. See my update above.

Yes, I've read it just now We were posting the same info at the same moment.

I think just using single-threaded boot may not be enough here, we probably need unique <X,Y> numbers in /etc/rc.<X>/S<Y>script files, so that the scripts would be sorted and executed in the correct order.

fsmithred · 2020-05-19 21:22:26

No change on booting with CONCURRENCY=none

dev-1-dash-1 · 2020-05-19 22:44:00

It seems that udev is confused, that's why not all modules are loaded.

The first initscripts to boot on a beowulf system already installed to hd in runlevel S:

/etc/rcS.d:
@S01mountkernfs.sh
@S02eudev

The first init scripts to boot on the beowulf live-image from dvd in runlevel S:

/etc/rcS.d:
squashfs-root/etc/rcS.d/S01live-config
squashfs-root/etc/rcS.d/S02mountkernfs.sh
squashfs-root/etc/rcS.d/S03eudev

It is possible that live-config does something which works when using "toram", but fails when booting from the dvd.

Can you change the order of execution so that live-config runs after udev, or it HAS to be the first thing to run?

Again, just a wild guess here.

ralph.ronnquist · 2020-05-20 07:14:06

According to my /etc/inittab my boot control script is called /etc/init.d/rc, and that is a link to /lib/init/rc, which is a shell script that by the looks of it has a great number of ways to avoid concurrent boot.
For example put concurrency=none on the boot command line.

fsmithred · 2020-05-20 10:02:47

For example put concurrency=none on the boot command line.

Thanks. That's easier, and it has the advantage of showing up in /proc/cmdline, so I can check if I used it or not. Unfortunately, it doesn't help. Lots of modules are missing, including snd.

The problem also exists on isohybrid-imaged usb. It's not limited to optical media.

Multi-boot usb does not have the problem.

Andre4freedom · 2020-05-21 10:57:35

I've just tested the devuan_beowulf_3.0.0_beta3_netinstall-amd64 iso.
Looks good.
It's important to check the release notes.
I tested netinstall, selecting the Cinnamon DE and OpenRC
The few things to note:
1. I had to add " non-free contrib" to /etc/apt/sources.list to get firmware-amd-graphics (No problem)
2. Language settings / locales were respected (Great)
3. Lightdm-greeter had to be edited. Bug 438 is closed and fix will be backported to Beowulf. Thanks to the maintainer. (It's in the release-notes)
4. /etc/pulse/client.conf.d/00-disable-autospawn.conf must be modified. (It's in the release-notes)
5. Every other thing is just "smooth sailing". Beowulf is very robust and reliable. Thanks to the Devuaners!

Lomax · 2020-05-22 02:52:17

Tremendously excited about this new release - a big thanks to everyone who's been involved in making it happen, you guys rock! Keen to upgrade from ASCII and try out the new shiny things, but dist-upgrade wants to remove a bunch of critical packages:

The following packages will be REMOVED:
  clamav clamav-daemon clamav-freshclam cmake elogind gnome-themes-standard-data kicad libboost-python1.62-dev libboost-python1.62.0 libboost1.62-dev libclamav9
  libclang1-3.9 libcupscgi1 libcupsmime1 libcupsppdc1 libgsl2 libllvm3.8 libllvm3.9 libllvm3.9:i386 libmariadbclient18 libnomacscore3 libnomacsgui3 libnomacsloader3
  libpam-elogind libqalculate5-data libqalculate5v5 libreoffice-style-galaxy libsensors4 libsensors4:i386 libthunarx-2-0 network-manager network-manager-gnome
  network-manager-openvpn network-manager-openvpn-gnome nodejs-dev virtualbox virtualbox-ext-pack virtualbox-qt

This is on an up-to-date ASCII installation and the following atp/sources.list:

deb http://deb.devuan.org/merged beowulf main non-free contrib
deb http://deb.devuan.org/merged beowulf-updates main non-free contrib
deb http://deb.devuan.org/merged beowulf-security main non-free contrib
deb http://deb.devuan.org/merged beowulf-backports main non-free contrib

I could understand if things like Virtualbox might disappear, but cmake!? Something's clearly not right here, what could that be?

Last edited by Lomax (2020-05-22 02:54:01)

wingcommander1999 · 2020-05-22 03:39:02

Andre4freedom wrote:

I've just tested the devuan_beowulf_3.0.0_beta3_netinstall-amd64 iso.
Looks good.
It's important to check the release notes.
I tested netinstall, selecting the Cinnamon DE and OpenRC
The few things to note:
1. I had to add " non-free contrib" to /etc/apt/sources.list to get firmware-amd-graphics (No problem)
2. Language settings / locales were respected (Great)
3. Lightdm-greeter had to be edited. Bug 438 is closed and fix will be backported to Beowulf. Thanks to the maintainer. (It's in the release-notes)
4. /etc/pulse/client.conf.d/00-disable-autospawn.conf must be modified. (It's in the release-notes)
5. Every other thing is just "smooth sailing". Beowulf is very robust and reliable. Thanks to the Devuaners!

I see recently that Beowulf came in Release Candidate, see joined pix:

At the Beta page we can read that ASCII are moved to oldstable, but on the official page ASCII are the latest stable release at the moment, can someone confirm the thing?

Last edited by wingcommander1999 (2020-05-22 03:45:19)

larsH · 2020-05-22 06:05:58

Hi

Beowulf is not released yet.

You do not need to enable pulseaudio. The problem without for most users are to chose soundcard, and adjust volume. But alsamixer on terminal does this just fine. There are as well a couple of apps for the dektop (volumeicon-alsa and others) you can use as well. Pulseaudio in itself is actually not using any hardware on your system just software. So there is a overhead using pulseaudio. Alsa uses the supported hardware directly.

Have a nice day

Lars H

Lomax · 2020-05-22 14:06:52

Lomax wrote:

I could understand if things like Virtualbox might disappear, but cmake!? Something's clearly not right here, what could that be?

I managed to fix most of these by removing some application specific repos, and uninstalling a few things I wasn't really using. dist-upgrade no longer wants to remove cmake for example. But it still wants to drop network-manager, and elogind:

The following packages will be REMOVED:
  elogind gnome-themes-standard-data libboost-python1.62-dev libboost-python1.62.0 libboost1.62-dev libclang1-3.9 libcupscgi1 libcupsmime1 libcupsppdc1 libcurl3
  libgsl2 libllvm3.8 libllvm3.9 libllvm3.9:i386 libmariadbclient18 libnomacscore3 libnomacsgui3 libnomacsloader3 libpam-elogind libqalculate5-data libqalculate5v5
  libreoffice-style-galaxy libsensors4 libsensors4:i386 libthunarx-2-0 network-manager network-manager-gnome network-manager-openvpn network-manager-openvpn-gnome
  nodejs-dev virtualbox virtualbox-ext-pack virtualbox-qt

Isn't elogind required for Gnome to work without systemd-logind? And how can I retain network-manager?

Lomax · 2020-05-23 20:51:25

Using aptitude full-upgrade instead gives me the following:

The following packages have unmet dependencies:
 libpolkit-backend-consolekit-1-0 : Conflicts: elogind but 241.4-2 is to be installed
                                    Conflicts: libpam-elogind but 241.4-2 is to be installed
                                    Conflicts: elogind:i386 but it is not going to be installed
 virtualbox : Depends: python3 (< 3.6) but 3.7.3-1 is to be installed
 libelogind0 : Conflicts: libsystemd0 but 241-7~deb10u4 is to be installed
               Conflicts: libsystemd0:i386 but 241-7~deb10u4 is to be installed
The following actions will resolve these dependencies:

     Remove the following packages:                                    
1)     virtualbox [5.2.24-dfsg-4~bpo9+1 (now)]                         
2)     virtualbox-ext-pack [5.2.24-2~bpo9+1 (now)]                     
3)     virtualbox-qt [5.2.24-dfsg-4~bpo9+1 (now)]                      

     Keep the following packages at their current version:             
4)     elogind [234.4-2 (now)]                                         
5)     libelogind0 [234.4-2 (now)]                                     
6)     libpam-elogind [234.4-2 (now)]                                  
7)     libpolkit-backend-consolekit-1-0 [0.105-25+devuan0~bpo2+1 (now)]
8)     libpolkit-gobject-consolekit-1-0 [0.105-25+devuan0~bpo2+1 (now)]

     Leave the following dependencies unresolved:                      
9)     virtualbox-dkms recommends virtualbox (>= 5.2.24-dfsg-4~bpo9+1)

Maybe some clues in there?

rolfie · 2020-05-23 21:13:57

Look at the Release Notes. You got the following issue:

libpolkit-backend-consolekit-1-0 <> elogind re. libpolkit-backend-elogind-1-0

Let your old VBox go, and re-install the latest version from Oracle directly.

rolfie

Last edited by rolfie (2020-05-23 21:14:23)

Lomax · 2020-05-23 22:10:22

rolfie wrote:

Look at the Release Notes. You got the following issue:
libpolkit-backend-consolekit-1-0 <> elogind re. libpolkit-backend-elogind-1-0
Let your old VBox go, and re-install the latest version from Oracle directly.
rolfie

Great, thanks! I read up a bit on consolekit vs. elogind and decided to remove consolekit. I also removed Virtualbox, and all i386 packages, as well as the i386 architecture. Looking better now, but aptitude full-upgrade still chokes on

libelogind0 : Conflicts: libsystemd0 but 241-7~deb10u4 is to be installed

Lomax · 2020-05-23 22:41:49

That was easily fixed by simply doing

apt-get install libelogind0

I now get a clean upgrade plan in aptitude.

12:50 Press return.

Lomax · 2020-05-24 01:28:49

The upgrade seems to have gone well, but at the end of it I got a curious warning from update-initramfs:

cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries 
    nor crypto modules. If that's on purpose, you may want to uninstall the 
    'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs 
    integration and avoid this warning.

I have spent a good two hours trying to determine if this will mean my system won't boot (I have encrypted swap & home dir), but I'm still not quite sure. I understand that the wording of the warning is a little misleading; it's not saying you cannot include cryptsetup binaries in initramfs but that none are present although the systems may need one in order to boot. My crypptab:

# <target name> <source device>         <key file>      <options>
cryptswap1 UUID=a01249eb-d97d-47d1-975e-3d34d2dfe94a /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

Without really knowing what I'm doing I tried adding CRYPTSETUP=y to /usr/share/initramfs-tools/conf-hooks.d/cryptsetup and re-running update-initramfs -u but still got the same warning. I suspect the warning is spurious, and that my system will boot just fine, but I am loath to try without being sure. Can anyone confirm?

dev-1-dash-1 · 2020-05-24 01:45:34

Lomax wrote:

The upgrade seems to have gone well, but at the end of it I got a curious warning from update-initramfs:

If your root is unencypted you may boot but will have to unlock crypt partitions manually.

If you've only encrypted home and swap then you don't need cryptsetup in the initramfs and can ignore the warning. The root will be mounted and after that the cryptsetup binaries are accessible to the system in order to unlock the rest of partitions.

If you've described the situation accurately, you'll probably be able to boot and login as root. After that you can unlock the rest and add the required lines to crypttab/fstab.

Last edited by dev-1-dash-1 (2020-05-24 02:02:52)

Lomax · 2020-05-24 02:03:48

dev-1-dash-1 wrote:

Lomax wrote:
The upgrade seems to have gone well, but at the end of it I got a curious warning from update-initramfs:
If you have encrypted root try adding it to crypttab.
That warning means cryptsetup probably won't get included in initramfs unless you manually added it. So do fix it before going on.
If your root is unencypted you may boot but will have to unlock crypt partitions manually.

Thanks! I thought adding CRYPTSETUP=y to /usr/share/initramfs-tools/conf-hooks.d/cryptsetup was how to "manually add it" to initramfs, but since the warning persisted that's probably not correct. How should I do it? I don't have encrypted root, only swap partition and home directory. Home directory isn't decrypted at boot of course, and a missing swap partition should be easy to get around - but I'd still need to fix it...

Edit: Just saw your edited post.

dev-1-dash-1 wrote:

If you've only encrypted home and swap then you don't need cryptsetup in the initramfs and can ignore the warning. The root will be mounted and after that the cryptsetup binaries are accessible to the system in order to unlock the rest of partitions.

Excellent, then it is as I thought, and the warning is misleading. Thank you!

Last edited by Lomax (2020-05-24 02:08:18)

dev-1-dash-1 · 2020-05-24 02:17:58

Lomax wrote:

Excellent, then it is as I thought, and the warning is misleading.

The warning isn't misleading, because it says cryptsetup won't be included in the initramfs, and that's exactly what will happen.
But you simply don't need the cryptsetup binaries in the initramfs if your root isn't encrypted. The binaries will be accessible when the root filesystem is mounted.

Adding CRYPTSETUP=y to /usr/share/initramfs-tools/conf-hooks.d/cryptsetup isn't exactly including it manually. This just specifies that cryptsetup will be added automatically if the root filesystem itself is encrypted.

Hope it helps.

Last edited by dev-1-dash-1 (2020-05-24 02:19:47)

Andre4freedom · 2020-05-24 11:26:30

wingcommander1999,
I have tested the RC just after my post, and yes, now it's the "devuan_beowulf_3.0.0_RC_netinstall-amd64.iso", and it shows the exactly same results, so my comment is valid for the RC as well.
Devuan is really great. Just don't forget to read the release notes. Thanks to all.

fsmithred · 2020-05-24 11:57:36

Adding CRYPTSETUP=y to /usr/share/initramfs-tools/conf-hooks.d/cryptsetup isn't exactly including it manually. This just specifies that cryptsetup will be added automatically if the root filesystem itself is encrypted.

Setting CRYPTSETUP=y will cause cryptsetup to be added to the initramfs if the root filesystem is NOT encrypted. (just tested this to be sure.) If root is encrypted, it'll be added without this setting. The wording in the comment for this setting suggests that in the future, it will be added if cryptsetup is installed, regardless of the root filesystem.

I use this setting in some live isos so that they can be used on a live-usb with an encrypted volume for full persistence.

You can check if the initramfs contains cryptsetup by running 'lsinitramfs' (from initramfs-tools-core package)

CRYPTSETUP=y

$ lsinitramfs /boot/initrd.img-4.19.0-9-amd64 | grep cryptsetup

usr/lib/cryptsetup
usr/lib/cryptsetup/askpass
usr/lib/cryptsetup/functions
usr/lib/x86_64-linux-gnu/libcryptsetup.so.12
usr/lib/x86_64-linux-gnu/libcryptsetup.so.12.4.0
usr/sbin/cryptsetup

I commented out that setting, ran 'update-initramfs -u' and re-checked with lsinitramfs. None of the above listed files were present.

dev-1-dash-1 · 2020-05-24 12:17:22

Setting CRYPTSETUP=y will cause cryptsetup to be added to the initramfs if the root filesystem is NOT encrypted. (just tested this to be sure.) If root is encrypted, it'll be added without this setting. The wording in the comment for this setting suggests that in the future, it will be added if cryptsetup is installed, regardless of the root filesystem.

I stand corrected.

I do remember though that when getting the warning

cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries 
    nor crypto modules. If that's on purpose, you may want to uninstall the 
    'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs 
    integration and avoid this warning.

I did get into trouble (unable to decrypt root filesystem) a few times because cryptsetup bins were not included. So I learned to pay attention to it if I need to decrypt something at the initramfs stage.

The preferrable way of including cryptsetup bins for me is adding 'initramfs' to options column of crypttab. Like this:

# <target name> <source device>         <key file>      <options>
target_device_name   UUID=<..uuid here..>   none  luks,initramfs

And you don't need to add CRYPTSETUP=y. This is for ascii and later.

I hope Lomax was able to boot successfully.

Lomax · 2020-05-24 13:37:43

Thanks guys, I've learned a lot here - and yes, reboot went without issue, though I jumped as I saw the red boot screen Only niggle is slightly odd mouse pointer acceleration compared to what I'm used to (I'm a TrackPoint user), and that's really quite minor. I'll get used to it. Beowulf is noticeably faster than ASCII on my machine, which is great! Big thanks once again to the Devuan team for all the hard work you're putting into this project - it's clearly paying off!

Geoff 42 · 2020-05-24 13:59:57

I tried the desktop live and the netinstall isos :-

devuan_beowulf_3.0.0_RC_amd64_desktop-live.iso
devuan_beowulf_3.0.0_RC_netinstall-amd64.iso

I tried them as DomU under Xen. While the straightforward way would be to use debootstrap, I wanted to try using the installers on the isos.
The desktop live install was very straight forward, although I report a few things to watch. One is mainly related to Xen. I don't know if the others are.

I failed to get netinstall to go passed the disks.
Xen passes over 2 disk areas

/dev/xvda1 swap
/dev/xvda2 /

While the live desktop can just use them, the netinstall wants to repartition them and fails.

Things to watch

Under Xen, the framebuffer can be passed through qemu to a vncserver, which is running in the host OS (Dom0).
You can then simple run:-

vncviewer :0

in Dom0 and you are presented with the login under slim.
The only problem is the size, which is 800x600. Fortunately you can select larger or smaller fonts from the XFCE desktop. I have not been able to work out how to make this framebuffer larger, so I install vnc4server on the new OS and ssh in to it, setting up a tunnel with

ssh -L 5901:localhost:5901 beowulf

and running the vncserver with :-

vncserver -geometry 1600x1000

Then, back on Dom0 I can then run

vncviewer :1

This works well, but does not test slim.

One problem is the root password not working. I wonder whether this is a problem with keyboard mapping changing betweeen install and use, between C and en-gb. (Or is it en-us and en-gb?)
One workround is to use a simpler temporary password which avoids characters that change between mappings and then setting the real password once fully installed.

If installing openrc, then it has to do a lot of dependency loop breaking. Most include live-tools, so if you are not using them, uninstall live-tools.

dmesg reports :-

udevd[1057]: specified group 'kvm' unknown

so add kvm to /etc/group. I don't know if this is related to my running under Xen.

It is able to use the disk partitions given it by Xen.
/dev/xvda1 swap
/dev/xvda2 /
when asked to select which partition you want to use, it is important to select one! I was offered only one partition for swap. It is important to select it before continuing as I couldn't see anyway to go back and try again!

Geoff

dev-1-dash-1 · 2020-05-24 18:24:08

Booting the beowulf live image rc into runlevel 1, after that

service eudev stop
groupadd kvm
service eudev start

seems to fix the issue with missing modules.

Geoff 42 · 2020-05-26 10:52:49

Geoff 42 wrote:

One problem is the root password not working. I wonder whether this is a problem with keyboard mapping changing betweeen install and use, between C and en-gb. (Or is it en-us and en-gb?)

I believe that this was probably my fault. I have tried setting the keymap in the configuration file for the VM, and the VNC display via qemu now uses the key mapping I want. In my case this line in the Xen config file for this VM is :-

# Graphic display
vfb = [ 'vnc = 1, keymap = "en-gb"' ]

Geoff

The officially official Devuan Forum!

#201 2020-05-19 21:08:36

Re: Beowulf Beta is here!

#202 2020-05-19 21:22:26

Re: Beowulf Beta is here!

#203 2020-05-19 22:44:00

Re: Beowulf Beta is here!

#204 2020-05-20 07:14:06

Re: Beowulf Beta is here!

#205 2020-05-20 10:02:47

Re: Beowulf Beta is here!

#206 2020-05-21 10:57:35

Re: Beowulf Beta is here!

#207 2020-05-22 02:52:17

Re: Beowulf Beta is here!

#208 2020-05-22 03:39:02

Re: Beowulf Beta is here!

#209 2020-05-22 06:05:58

Re: Beowulf Beta is here!

#210 2020-05-22 14:06:52

Re: Beowulf Beta is here!

#211 2020-05-23 20:51:25

Re: Beowulf Beta is here!

#212 2020-05-23 21:13:57

Re: Beowulf Beta is here!

#213 2020-05-23 22:10:22

Re: Beowulf Beta is here!

#214 2020-05-23 22:41:49

Re: Beowulf Beta is here!

#215 2020-05-24 01:28:49

Re: Beowulf Beta is here!

#216 2020-05-24 01:45:34

Re: Beowulf Beta is here!

#217 2020-05-24 02:03:48

Re: Beowulf Beta is here!

#218 2020-05-24 02:17:58

Re: Beowulf Beta is here!

#219 2020-05-24 11:26:30

Re: Beowulf Beta is here!

#220 2020-05-24 11:57:36

Re: Beowulf Beta is here!

#221 2020-05-24 12:17:22

Re: Beowulf Beta is here!

#222 2020-05-24 13:37:43

Re: Beowulf Beta is here!

#223 2020-05-24 13:59:57

Re: Beowulf Beta is here!

#224 2020-05-24 18:24:08

Re: Beowulf Beta is here!

#225 2020-05-26 10:52:49

Re: Beowulf Beta is here!

Board footer