It works !!!!!!!! xDDD

2 tries, a soft and a hard reboot, and mouse/kb is operational immediately after booting to desktop!

EDIT:
I did however get this when the system has detected a btrfs drive:

udevd[3098]: failed to execute '/lib/udev/${exec_prefix}/bin/udevadm'.
'${exec_prefix}/bin/udevadm trigger -s block -p ID_BTRFS_READY=0':.
No such file or directory

Not a show stopper though, system continues to work.

EDIT2:
Booting the iso from hdd using grub also works perfectly!

Well, do the next step and add remove/insert usbhid to rc.local and try to load the desktop.

Also, are you using the latest refracta iso, or latest beowulf beta iso?

I tested on the refracta iso.

I don't have an extra box right here to ssh from, so I am working on a single machine.
Remove/reinsert usbhid while in console (before booting to desktop) doesn't affect the mouse - it works before, and after that. Checked with gpm.

But when I edit rc.local to replace psmouse with usbhid and go on to desktop, the mouse isn't working.

Also: you've said that this shouldn't be done 'too early', i.e. in live config scripts.
Maybe rc.local isn't the best place for this as well? I have quite a long delay (20-30, maybe 40 sec) while desktop boots with the dvd screeching around loading stuff. Is it possible that rc.local is run, usbhid gets reinserted, but too early, and the "freezing" of mouse happens AFTER the rc.local script has already run?

Is it possible maybe to insert the reinsert hack into some other place... Maybe /etc/xdg/autostart or some such, which is GUARANTEED to be executed after the desktop is already loaded.

Let me know what you think of this.

Couldn't get it to work with usb mouse/kb.
Changing 'psmouse' to 'usbhid' didn't help.

No lvm errors though.

Update:
Trying to remove/reinsert the host controller 'uhci_hcd' didn't work as well, and also gave an error message about it being in use.

I don't think lvm is the root cause of the problem here.
Including the fixes does sound like a good idea though.

Also, maybe don't start lvm at all during boot?
People who will mount complex lvm/raid configs will type a lot of commands, it's probably not too much trouble to type one more command to start lvm.
On the other hand, if you freeze during boot or your mouse/kb won't work, lvm is useless for you.

Also: what is it that the "toram" parameter does that unhugs the boot process and allows everything to work?
It can't be just the delay, because "rootdelay=300" doesn't help.
Maybe take a closer look at the scripts activated by "toram" parameter. Something they do allows the boot to proceed.

I'm not that familiar with the internals of a debian/devuan initramfs to know where to look.

Same thing - booting from dvd.
Lvm/udev loop timeout, mouse and kb not working in desktop (though they do in console).
"Toram" helps, I can login to desktop, but I have a freeze on shutdown (maybe the same loop going on somewhere in the background).

One thing is constant among all beta versions: screen font doesn't change when things aren't working (from dvd, no "toram") - means problem is already there when udev is detecting my videocard? Also when mouse/kb stop working, it happens exactly the moment when display manager starts and switches me to the x display-console away from console.

Maybe my video driver gives udev some confusion? i915 module. Any way to boot with some kind of "default generic safe-mode video driver"?

Beowulf already installed to hd using debootstrap continues to work marvelously through all of this.

I only use zfs since jessie, so I started when all the stuff was already conviniently packaged.

The beowulf package tree is apparently ready, the thing that's being worked on right now are the install images themselves.
You can use debootstrap (ascii or beowulf version) to set up your system. That's the smallest and slickest install image available, seems to have no bugs right now. I've done so, and everything seems to work fine, including zfs root. As I said, I've almost jumped ship from jessie myself.

Maybe try Arch Linux? I've heard they have more frequent releases...

Seriously though, devuan is working slow and steady. That approach is good for stability. And general health of your systems (including your nervous one).
And yes, I also wish beowulf would be done already.

Surely that approach is more reliable in general. Had this happened on a production server, I would have done the same or cancelled the upgrade altogether.
I did make a snapshot before the upgrade, ability to do so is the primary reason to use zfs for me.

Devuan team must be working their asses off trying to release beowulf any minute now. Right? I mean they have to be, right?
Let's not disturb them.

After they release beowulf, we can bombard them with bug reports for ascii.

As to whose bug this is, I leave it to the devuan team to comment on this one.

I can't use sudo in single user mode - root password or ctrl-d to continue to boot to runlevel2.

The only thing that allows me to boot the dvd is using "toram".
The extracting of the squashfs was interrupted once by "crng init done" message, after that boot proceeded to desktop normally. At least for the first minute or two, didn't try longer.

I did a few more reloads and inspected the logs - difference between boot from dvd and hd.

First difference - apparmor, I didn't disable apparmor in my grub entry for the iso, so when booting from hdd I always have apparmor on, and I boot successfully. Removing the apparmor entry from dvd command line (thus enabling apparmor) didn't do anything.

Udev entries are in a different order - all the pci, usb etc. controllers seem to be there though, but I didn't compare each and every device. The usb host controller and kbd and mouse drivers do get loaded correctly in the dvd, but the devices themselves don't work. (Until I tried the "toram" option).

One time after rebooting and trying to load from hdd I got the "booting smp configuration" freeze. It seems to happen very early on - right after (or during) the microcode update, which seems to be the first thing happening during boot. The message only appeared once out of about 5 reboots.

The system in the already installed form on hdd is working perfectly through all of this.

Ok, enough reboots for today. Let me know if you come up with any tests I should run.

UPDATE:
Using "toram" seems to always work and allow me to boot from the dvd, as well as hdd.
I tried using "rootdelay=300" for 5min timeout, but it didn't help - still the same "/dev/sdx not initialized" and mouse/kbd not working in desktop.

My experience:

Boot iso from hdd using grub:
Almost immediate freeze on "booting smp configuration". Hard poweroff helps.
In the upper part of the screen I see messages regarding microcode. Bad microcode loaded or my cpu not supported?

Boot from real dvd:
Starts ok, gets to loading lvm vgroups, spews out the "/dev/sdX not initialized after ...", ctrl-c cancels it, boots to desktop and hard freezes immediately after showing the xfce desktop.

Would like to point out: I have an installation of beowulf (created using debootstrap) on this machine which I think may become my main system on main box real soon now. It works very well, so I know all my hw is supported.

Also, since we are getting so strict and pedantic about our sources.list, which IS the right approach if we want a stable system to actually be stable.

I've read many times on this form that preferred way to access the official repositories is using

deb.devuan.org

in our sources.list. And it's been that way for some time already.

Why, then, my recently installed copy of beowulf contains

http://pkgmaster.devuan.org/merged

in file

/etc/apt/sources.list

???

Installation was performed by using debootstrap.

I think golinux said somewhere on this forum that devuan is 98% pure debian. That means using packages built against a corresponding debian release is 98% likely to work, on average. Unless you get packages which are heavily systemd related.

If it doesn't work, you can always blame golinux for lulling you into a false sense of security with the 98/2 statistics. (jk) :-)

I use oss4 packages from deb-multimedia on ascii system and they fit perfectly.

Great, straight on target!
That worked for the chroot.

I have debootstrapped another test system now, but when I boot it these messages still appear in the "starting lvm volume groups phase." Ctrl-c makes it go away, boot seems to proceed normally.

I am now having trouble getting the wireless network interface to come up. eth0 is there, but no wireless in sight. I am rebooting into an ascii system to look up for clues on the internet.

UPDATE:
Another test install completed.
Some feedback:
1)Kernel modules for my wifi card didn't load automatically, although they are present right there in the linux-image package.
Had to load them manually, than add them to /etc/modules to trigger their autoload at boot time.
2)Message udevd[672]: specified group 'kvm' unknown appears during boot time.
3)Sometimes the message about 'dev/sda not present in udev database' still appears during 'starting lvm' phase, ctrl+c gets rid of it.
4) Of course, after installing nvidia proprietary drivers (nvidia-legacy-...) system changed resolution and froze, had to do hard reset that boot into single user mode and finish config from there. Hello nvidia!

On the plus side, I've set up lvm, crypt, and zfs root and was able to boot successfully.

EDIT: Removed some complaints which turned out to be due to my misconfiguration rather than beowulf bugs.

I also had these warnings when on an beowulf test install.
I was running on bare metal.
Don't know why they appear or how to get rid of them.