Ok.

Perhaps it requires "netconsole"  for entering password if you don't have console access.
See https://www.kernel.org/doc/Documentatio … onsole.txt

That would  mean to use the "netconsole=" boot parameter rather than (or maybe together with) the "ip=" parameter. At the console end you can run a "socat" process, as per exmaple "3)" on that page.

EDIT: you might also want/need the pty option on the socat service, to make it "user friendlier".

EDIT 2: It's probably obvious, but I don't know anything about "clevis" or "tang", so keep filtering my loose ideas.

ok; ctrl+f4 shifts to vt4, which is dedicated to tail -f /var/log/syslog of the installer. Thus, you can use ctrl+f2 and less /var/log/syslog to explore that, or use nc to transfer it to another host.

Yes, "excalibur" is a testing release, and this is a good find.

@edsonwolf: please lodge a Debian bug report for package partman-crypto which apparently expects libgcc_s.so.1 to be an installed library in the installer but lacks dependency to ensure that. Specifically, it does depend on libc6-udeb rather than libc6 with the significant difference that it lacks the dependency on libgcc_s.so.1. The partman-crypto developer(s) need to decide how to handle that.

NOTE: a "Debian bug report" is an email to mailto:submit@bugs.debian.org where the first two body text lines would be

and the rest of the body would be any useful notes to in particular assist the developers in repeating the issue.

Bringing in javascript so members can avoid maintaining existential presence while composing a post is ruled out on policy grounds. That includes variant solution ideas such as adding javascript only for Altoid or expanding the timer concept to make the limit a profile setting.

(Well that last one is technically ruled out by virtue of its implied complexity relative to the body count at the developer team's morning tea)

Off hand a thing one could do without javascript would be an automatic preview kicking in after, say, 28 minutes (by using a so called "refresh tag"), but that would probably be more annoying than helpful.

The idle timer is a "security measure" where the underlying concern is "identity theft" with respect to forum posts. It's a common solution: a session key cookie with time limited validity where every interaction within that time either yields a new such key or (the weaker but simpler approach) just get a validity time extension for the current session key. Other solutions are possible but the morning tea body count is a barrier.

This forum has a half-hour timeout for the idle time between interactions which separates them into sessions. If you are editing a post, you may hit preview within that half-hour so as to maintain the session without making the post. That will extend the session timer with another half-hour. It will also refresh your thread view with any posts that have been made while you ahve been sitting there prefectering spelling.

How do/did you set up "full disk encryption"?

For me the chimaera installer only lets me reduce the disk to a single partition and encrypt that; is that what you mean?

But then, for me, the installer objects and goes into loop trying to force me to have a separate unencrypted /boot partition while not allowing me to erase the setup.

So, would you mind describing your "full disk encryption" (so I can trial it).

When installing the package usrmerge it will try to change the file system so that some root directories get changed into symbolic links for the same-named directories in /usr; those are what I call the "silly-links".

Unfortunately the usrmerge developers seemingly opted for going about this in the worst way possible, so the installation of usrmerge is likely to fail successively, requiring some amount of operator hands-on and reinstallation. Once installed, it gets replaced with the usr-is-merged package as indicator or flag for apt/dpkg to not install usrmerge again, ever.

All in all, it's better and almost necessary (esp for avoiding that operator hands-on) when shifting to excalibur, to install usrmerge on daedalus, i.e. before actually shifting. There is no technical difference difference between having or not having silly-links, except for the cases where a package installs binaries with a /bin path and then uses them on a /usr/bin path or vice versa (looking at you, busybox), in which case silly-links are required.

If you want to set up silly-links yourself you only have to make sure that the pathnames /lib* get copied and replaced with their links in "atomic steps"; i.e. you cannot use a shell script that separates "rm /lib" from "ln -sTf usr/lib /lib" specifically because the script intepreter's running of "ln" will require that the ELF-loader is found on its "/lib/.." path. (It's pretty obvious how to work around that though, for example by using busybox-static or , say, newlisp).

Argh! With the downloaded netinstall the failure is that "usr-is-merged" is unavailable.
I thought I had worked around that issue but obviously failed ... yes, failed to add that workaround to the commit.
Thanks for testing. There is a new collection (including that commit) coming up shortly.

Are you using "netinstall", "server" or "desktop" ? I'm using netinstall in a VM and have success with the hands-on I outlined. It you're using "server" or "desktop" I can check with those, though the installer software for the base system is meant to be the same.

Run the installation until that red screen, then push contine until the expert install menu comes up showing that you are on "Install the base system".

Now, step down to the "Change debconf priority"; select that and select the suggested "low" priority, which returns you to the expert menu and the "Install the base system" step.

Select that will now give you the option of choosing "yes" for silly-links, and that will then allow the base system installation to complete. Pick kernel and modules, and then use "go back" until the expert install menu again...

.... then it's just to pick your init, install grub, finish installation, and reboot.

Yes, no further testing is needed; there appears to be a mismatch between kernel and modules for excalibur so it won't work. Thanks for trying.

Possibly because it depends on $syslog which isn't started in the rcS collection.