Hello:

As long as what was done was the right thing, good going.
Congratulations. 8^D

I would not know how to use /etc/inittab.d so will not opine any further than this:

- the warning existed because sysvinit was looking for the /etc/inittab.d directory and did not find it.
- the (to me) obvious solution was to fix the installer to create it at install time; optional or not, sysvinit was looking for it.
- if there was some issue as how the *.tab files worked or had to be written, add the corresponding documentation.
- I am not too sure it is the right solution because the problem was not the warning, in itself a consequence.
- (to me) problem was the /etc/inittab.d not being where it should have been which generated the warning.

The use of /etc/inittab.d is a feature of sysvinit, maybe very few use it, maybe not.
The solution has only obscured its existence, I only learnt about it because of the warning and fsmithred's post.

As always, just my $0.02

Best,

A.

Hello:

Yes ...
But sysvinit asks for it (see link) so it should be there.

Hmm ...

Added via Debian?
Something that is directly related to sysvinit?   8^D !!!

Right ...
You could try filing a bug against INIT: no inittab.d directory found with the Debian devs.
But you will not like the reply.

TL;DR:
Something along these lines ...

"On your way, mate. This is not a bug, sysvinit is not part of the default Debian configuration".

Eventually and only for completeness' sake, someone with the required knowledge could volunteer to write a small metapackage to do that.

If not, just add it manually and get rid on an unneeded warning in syslog.

Best,

A.

Hello:

The basic Unix principle: Do one thing, and do it well has been broken for many years now.

Hmm....

If we* means the already overworked / short staffed group of people working as well as they can to keep Devuan systemd free, you may want to stop and think a bit.

The die is cast: unless an important group of distributions turn their back on systemd (and I choose systemd as the prime example of the enshittification of the Linux ecosystem) I do not think anything is happening.

* I was going to attempt a humorous approach to this with a "whatyoumin we white man?" quip but I decided against it.
Political correction and all.

Best,

A.

Hello:

Indeed, that is what I understood.

Blacklisting probably has the added effect of keeping rogue agents from doing it.

Best,

A.

Hello:

Always been a matter of common sense / common knowledge to me.

Little black book.
In my opinion, any system can be (eventually) hacked.

Best,

A.

Hello:

Indeed ...
Note the date on the post: March 11, 2012

This chap was bitching about this a whole five years before I started.
Imagine how bad things are now ...

Best,

A.

Hello:

Methinks you nailed it.  8^°

Best,

A.

Hello:

I just use my on-board sound hardware for the basics, but been following this thread to see if I learn something. 8^°

Out of curiosity ...
How does the system ID the USB sound card/s when you open a terminal and execute:

$ lsusb

Just a guess, there may be a clue in the printout.
Or not.

Best,

A.

Hello:

Right ...

Q1: do you need to recover any glass from that broken window?
ie: data you may need because you don't have/cannot find a back-up.

Q2: do you (for whatever reason) want to double boot on your T5600?

If the answer is no to both, you may want to consider doing a thorough clean-up and run tests before installing Linux.
ie: nuke any/every partiton on the HDD, re-format and run a comprehensive memtest.

From your OP it would seem that you are able to boot from a USB, so I expect that you should be able to get that done without issues.

Once you have your box set up and properly tested you can go ahead and install Devuan on it.

Thrashed Windows installations always leave a lot of crud behind.

Caveat:
Your T5600 is probably BIOS/UEFI so read up on the pertinent instructions for installing Linux on it.
eg:
Things like disabling secure boot, setting SATA to AHCI and boot mode to BIOS or UEFI.

To start off see here:
https://www.dell.com/support/kbdoc/en-u … nux-system

Best,

A.

Hello:

Sorry for the OT, will be brief.

So ...
You just did ...

# apt install mate

... and that was it?
No issues with XFCE?

Best,

A.

Hello:

This solution came from Daniel López Azaña's blog. 
I just relayed the message, so to speak.

There is also a page called [crontab.guru] where you can check your [crontab] syntax, among other things.
Go have a read, it is very comprehensive and useful to have in the browser bookmarks.

Here is how I do it, works a charm:
See man [crontab] on how to edit it.

# Entries added to keep log files from growing too large
# http://www.daniloaz.com/en/how-to-prevent-the-xsession-errors-file-from-growing-to-huge-size
#
# Set logfiles to 2Mb and 200 lines max. checking for size every 23 hours
# see https://crontab.guru/#0_*/23_*_*_*
#
# File size examples:
#
# 150Mb -> 150000
# 100Mb -> 100000
# 15Mb  ->  15000
# 10Mb  ->  10000
#  5Mb  ->   5000
#  2Mb  ->   2000
#
# to test cronjob run at 2 min intervals
# example -> */2 * * * *  echo "No systemd here"
#
# For /home/user/.xsession-errors
#
# ---
0 */23 * * * [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 2000 ] && tail -200 /home/$(whoami)/.xsession-errors > $
# ---

The above entry will keep the file under 2mb and when it grows over that limit it will clean up, keeping the last 200 lines.
2Mb of [.xsession-errors] is a lot of text.

eg:
Just now I see that my system's [.xsession-errors] file has 7249 lines and weighs in at a bare 784KiB.

Note:
I have looked at the glibberish that makes up the [.xsession-errors] file once or twice.
I could not make any sense from it and the system apparently worked properly.
And if it did not, I was never the wiser for it. 8^°

What it is useful for is to see just how much unfixed/crap code is routinely swept under the rug.
You know, all that [won't fix] stuff because [whatever].

The thing is that the main issue for most any Linux user is that the bloody file runs wild.
And if not checked, can grow to ridiculous sizes and cause problems.

Best,

A.