You are not logged in.
1) "Normally" a migration is done with the running OS, and in that case it's really a VT console level activity.
Last time I looked into it, the Debian system seemed to have some new layers of confusion with a series of (Windows-ish) steps to go through to reach a VT console level. That might be different now. The important bit is of course that the migration script needs to not be terminated prematurely when the init transition occurs, and therefore the shell that runs it must not be under any "session process control".
In your case, you could instead hook up drive B as the disk for a qemu virtual machine, and then migrate within that while idling in front of the browser on the "main" OS, drive A. The only particular quirk with that would be how to make drive B bootable by qemu (perhaps using extlinux)
In all cases you'll need a final grub setup after the migration; i.e. running update-grub with OS A to let it (re-)discover the drive B OS.
Though, I think I would call that a 201 activity as it does require sllghtly more than notional knowledge about running a qemu virtual machine, and about equipping it with an extlinux boot. It might not be your ideal solution but that's the way I can think of to let you view the instructions while following them. Printed on paper might be a better option.
2) You will need to re-update grub with OS A. Possibly already at the first of the two migration reboots.
3) The pinning will be preserved and shouldn't cause any issue ... unless, well, unless something.
4) And it shouldn't be an issue with keeping the old Tk either.
One option is that you identify which mirror is good or the best for you, and then add that resolution into your /etc/hosts.
Why not pick one of the installer ISOs instead?
They have desktop, server or netinstall in their names.
https://www.devuan.org/get-devuan
One option would be that something is outdated elsewhere in the "certificate chain" on the failing systems.
I.e., the "leaf level" certificate of www.devuan.org is fine, but in your environment some "parent" certificate in the certificate chain it stands on is outdated.
E.g., check your ca-certificates package.
Is anyone (still) getting those warnings from
wget --no-check-certificate https://www.devuan.org/get-devuanWARNING: The certificate of ‘www.devuan.org’ is not trusted.
WARNING: The certificate of ‘www.devuan.org’ has expired.
The certificate was updated 2 weeks ago, and is valid some 8 or so weeks more. So there shouldn't be or have been any warnings.
right. so pasting that int openssl x509 -text gives me (among other things):
Serial Number:
04:63:9c:cc:d4:86:e8:46:e0:95:f9:c7:31:93:fb:36:87:06
...
Validity
Not Before: Oct 20 23:55:06 2022 GMT
Not After : Jan 18 23:55:05 2023 GMTwhich looks all fine and dandy.
Is your clock ok?
No, nothing special or strange.
You post the link for the paste here, and then anyone can follow it while it's valid.
sorry; I wrote it while doing something else, it's of course https://paste.debian.net
Note that the certificate was Issued On Friday, October 21, 2022 at 10:55:06 AM and it Expires On Thursday, January 19, 2023 at 10:55:05 AM, so something strange is happening here.
Please do the following to download the certificate complained about
echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org \
| openssl x509 > /tmp/wwwdevuanorg.certand then upload that to pastebin.debian.org for us to review.
Well, https://www.devuan.org/get-devuan.html is the correct one which also references the actual html file; the abbreviation link (without .html) also works, but via server re-writes.
Obviously they don't work for you, which is slightly more difficult to debug. It'd be either your browser wanting to be helpful and intelligent, or something "environmental" relating to your Internet access.
Perhaps you can install "surf" and try with that?
maybe you can teach your browser something by adding .html to the end instead of /
I don't really need screenshot;
that link, https://www.devuan.org/get-devuan seems fine to me;
are you saying that that link doesn't work for you, or
that there is a link on that page that doesn't work for you?
If the latter, which link?
EDIT: hmm you have a / at the end of it, and having that seems to not bring the right page.
EDIT2: where did you find that bogus one, with a / at the very end?
which link?
If you want the full disks as raid members, then you skip to step 2 directly, and create a RAID device...
It all happens in the partitioning step:
first you declare partitions for use in raid setup
then you set up the raid device linking it to its partitions
and then you partition that into the filesystem partitions you want
I have "security=none" and
stuga% cat /sys/kernel/security/lsm ; echo
lockdown,capability,yama i.e., "yama" belongs to the unavoidable default collection of Linux Security Modules
https://kernsec.org/wiki/index.php/Projects
"installing the base system" at 6% is where packages are loaded and validated; nothing yet unpacked.
If it breaks there, then it's due to one of 3 things:
1) that your media is "corrupted"/broken or
2) that the target partition is too small or broken, or
3) that the RAM (which holds the installer system itself) is too small.
libsemanage-common_3.1-1_all.deb is a mere 20K, and loaded after maybe at about 30Mb has been used on the partition.
Unless you make a mistake when partitioning, it would suggest that your media is corrupted.
The published ISO image does not come with that corruption (as evidenced by that it's the same image since start and more than a few people have used it successfully)
You need to verify your download of that image using the published SHA256SUM, and you may well need to verify the physical media it is placed on as well.
ok
.. skip detecting network
.. skip configure network
.. skip "setup users and passwords"
.. skip configure the clock
.. do detect disks
.. do partition disks.. manual: which partition layout? how large partition(s)?
and how much RAM do you have?
Ok;
.. so I choose language (english), location (US.. lying), locale (en_US.UTF-8), no additional; just "continue"
.. I skip past access software
.. I skip past speech synthesizer
.. I do configure keyboard (am english)
.. it skips selecting layout automatically
.. I let it detect media
.. I load the default components only (select nothing of the extras, then "continue")
are we same enough so far?
My first attempt to induce that problem was not successful, so perhaps you could enumerate the installation choices you are making that leads to that problem.
As from power-up: the installation splash screen comes up:
* is this a BIOS boot or UEFI boot?
* and then, what's your sequence of choices/actions?
So you have difficulty with the chimaera netinstall iso? Do you want assistance?
Hah! I'm clearly full of wrong! Not only that, but there is also the possible overrides of insserv that can be used an misused in all sorts of ways. ![]()
@Head_on_a_Stick, when you get your systemd pants on you really get fanboi tedious; taking any odd behaviour from the systemd bug collective and cast it as an advantage over something else with sysvinit. Now you seem to want to claim that overriding a service definition is the same as disabling a service?
Yes, sysvinit does not have overriding, and I can see how you might use that to override the service definition in a way that ends up not starting the daemon. Obviously this would compete with any prior overriding, but presumably overriding is actually quite unusual to use for any other purpose? (Otherwise I'd expect someone would have revised the rc script to include it)
I suppose a sysvinit way to achieve a similar override could be to add a premature exit into the startup script. Doing so would likely have the effect (advantage?) that the package installation system would query about that change upon upgrade, and you would then again automatically reconsider whether or not that "override" remains appropriate.
Clearly neither systemd nor sysvinit have a way to block package installation from installing into the boot sequence. I think this is more a result of the Debian principle to deploy services when installing them.
In any case, I'd agree that apt-get purge apparmor is best here, and that it also seems to need a security=none setting (or similar) on the boot command line to make the kernel bypass apparmor kernel code.
This is a disadvantage of sysvinit compared to systemd
What do you mean with that kind of fud?
The "thrid answer" you allude to is just tiny-brain wiffle-woffle with not much relevance, and I'm pretty sure you know that.
Generally it's a stance in Debian that when you install a package that offers a service, then the installation includes deploying that service, so therefore apparmor is deployed when installed, and a user must un-deploy it; there is no difference depending on init systems here.
A minimalistic approach might be to review the ArchWiki page on ppp, install pppconfig and configure.