Note: I just learned that the "pinning" of ascii seems to require a "pinning" of testing as well, so I've updated my post above (#6) for that. It doesn't really make a difference tor the topic here; it's just if someone tries that tidbit on some other quest.

So, the problem relates to the nouveau module, rather. The 3.6 kernel appears to have these modules compiled into the kernel, so comparisons of kernels don't say much.

I then see some 3 lines of inquiry, including that of declaring mode lines (and backgrounding @Geoff's point). The other two are to look into the solutions around "optimus/bumblebee", and/or using an nvidia module instead of nouveau.

There may be more of course, and I don't know which approach is most likely to succeed (if any).

Declaring mode lines might be the "least intrusive", but perhaps also the least likely to succeed. The steps for this would be:

• Use cvt 1024 768 to get a mode line to use

• Use X -configure to generate a xorg.conf file, where you

  • remove everything except the Monitor section,

  • add the mode line twice, with the first renamed to be "0x0",

  • before installing it as /etc/X11/xorg.conf

That should be it, I think. Run startx and capture the log, unless it works of course. The renamed mode line is as an attempt to pick up on the defaulted one as per the log; though that one is likely to, if it makes anything happier, still result in rendering a 0x0 screen, which isn't too useful. You also have a couple of test variations where you exclude the one or the other of the mode lines.

Ah, you need to undo my useless suggestions about i915.

Ah, there should be a newline; though I'm not sure that makes a difference by itself. Perhaps you should add the following line as well (with newline):

install i915 /bin/false

and probably rename the file to /etc/modprobe.d/blacklist.conf
The install line supposedly fools the kernel to run the /bin/false program as way of trying to install the module, with the desired effect of not installing it. Apparently, with "just" a blacklist line, the module might be loaded anyhow due to a dependency from another module, whereas the added install line should counteract that load path as well.

... and add it into the initramfs of course.

Indeed. Lucky the bar isn't too high, though.

No, xserver-xorg-legacy is in ASCII.

If @fsmithred meant for you bring it in from ASCII, you should make sure to "pin" ASCII as well, e.g. by a file /etc/apt/preferences.d/reluctant-ascii with the following content:

Package: *
Pin: release a=ascii
Pin-Priority: 10

Package: *
Pin: release a=testing
Pin-Priority: 10

Then you can (temporarily) add a lline to your sources.list:

deb http://pkgmaster.devuan.org/merged ascii main

And install xserver-xorg-legacy using the special command

# apt-get install -t ascii --no-install-recommends xserver-xorg-legacy

However if that threatens to bring in a lot and/or remove a lot, you should probably abort, rather.

The explanation is in how the bash expands commands, and how "-x" works.

Without quotes, a phrase like

[ -x $(type -p gedit)]

gets "expanded" into the following phrase when "gedit' is missing (aka "type" returns nothing):

[-x  ]

i.e., "-x" without argument, and that succeeds. Whereas with quotes around it, the expansion is

[ -x "" ]

i.e. "-x" with an empty string as argument, and that fails.

Perhaps your statement should have been like

if type -p $program > /dev/null ; then echo UGH ; else echo NÖF; fi

That would be using the return code of "type" as condition, with 0 meaning success and non-0 meaning fail.

Just a little bit of background:

When '/etc/network/interfaces' (or any one of its sourced files) includes a line "auto eth0", it is a signal to the networking init script, that it should bring up eth0 on boot. That init script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.

When '/etc/network/interfaces' (or any one of its sourced files) includes a line "allow-hotplug eth0", it is a signal to udev, that it should bring up eth0 on boot (and also keep monitoring for later cable events). Its control script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.

Of course, dhclient is only used as part of bringing up the interface if '/etc/network/interfaces' also has the line 'iface eth0 inet dhcp'.

If you are using a network manager, then you should avoid telling the networking init script or udev to bring up eth0, but rather let the network manager daemon deal with it. Whether that induces a boot delay or not depends on whether it has been improved in parity with the scripts.

btw, for the sake of clarity: I write 'improved' but I mean 'destroyed'.

That's such a beautifully mis-informed notion!

It reads as a praise to the layers and layers of code in between the person and the action, simply to make a drawing of it, so it can be operated without articulated thought.

Other than that, I have nothing

You probably can set something up based on using a network namespace for the proxy server. That's in principle the same as the notion of it running in a VM, but without the VM.

The default namespace would be set up with its default route into the proxy namespace. The proxy namespace would be set up with its default route through NAT back out to the default namespace, and that traffic would need rule based routing to channel it through an outgoing NAT.

Or alternatively, you use rule based routing to direct traffic into the proxy namespace, and rely on the default route for the final channeling. I think you'll need the two NAT in either case.

The direct answer is "No". The notion of "master file" only concerns that example, and refers to the "salient path name" encoded into the automatic setup script. (As you know, that example is not ideal in my view, with the automatic setup attached to and repeated with any and all interface(s) coming up.)

iptables-persistent instead enshrines the path names /etc/iptables/rules.v4 and /etc/iptables/rules.v6 as being its "master files".

Hmm, by attaching the loading of table rules to the event(s) of bringing up an interface, you probably make life a little bit difficult for yourself. It's not "wrong" per se, and probably the only major complication is that in a typical set up, the network interfaces are brought up by udev in the pre-pivot boot up stage.

If that is your case, you will need to ensure that the rules files are included in your initrd, as well as the iptables-restore program and its dependencies (libraries). (I believe the if-pre-up.d script gets pulled in to the initrd automagically when remaking initrd).

Or alternatively, make that not be your case by not letting udev start networking. I.e., remove all "allow-hotplug" phrases from /etc/nework/interfaces. Possibly use "auto <if>" phrases instead, which tells the post-pivot networking init script that "these are yours, mate", or if then you also have a separate network manager, you'll need to leave all song and dance to it.

EDIT: I see from your other post that you're using wicd, so my thought about udev is probably not applicable here. Maybe it's enough to make your script exit more promptly when lo is brought up; or even tie it explicitly to $IFACE=wlan0.

Yes, according to FSSTND, you'll need to venture off the ranch for that one.