<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<atom:link href="https://dev1galaxy.org/extern.php?action=feed&amp;tid=2465&amp;type=rss" rel="self" type="application/rss+xml" />
		<title><![CDATA[Dev1 Galaxy Forum / remote migration from stretch to ascii failed]]></title>
		<link>https://dev1galaxy.org/viewtopic.php?id=2465</link>
		<description><![CDATA[The most recent posts in remote migration from stretch to ascii failed.]]></description>
		<lastBuildDate>Sat, 03 Nov 2018 21:30:31 +0000</lastBuildDate>
		<generator>FluxBB</generator>
		<item>
			<title><![CDATA[remote migration from stretch to ascii failed]]></title>
			<link>https://dev1galaxy.org/viewtopic.php?pid=12629#p12629</link>
			<description><![CDATA[<p>I followed instructions at <a href="https://devuan.org/os/documentation/dev1fanboy/migrate-to-ascii" rel="nofollow">https://devuan.org/os/documentation/dev … e-to-ascii</a>&#160; including manual network configuration.<br />1st reboot was fine. then after last step on the instructions and 2nd reboot, i could not login to the remote machine.</p><p>when i reviewed the session i noticed that the following were running just before i rebooted:<br /> 389 ?&#160; &#160; &#160; &#160; Ss&#160; &#160; &#160;0:00 /lib/systemd/systemd-udevd --daemon<br />1804 ?&#160; &#160; &#160; &#160; S&#160; &#160; &#160; 0:00 /lib/systemd/systemd-logind</p><p>i also noticed that libpam-systemd had (of course) been removed by apt-get but didnt think to check what it had been replaced with.</p><p>it seems too late to fix, so i will have to ask the remote colo provider to reinstall a fresh copy of debian 9.&#160; in case i decide to try migrating again, would you folks have any hints what i should look for, just prior to the 2nd reboot, to ensure the system will be accessible afterwards?</p><p>[update]<br />when i got the freshly installed machine the ethernet interface was named &quot;eno1&quot; for some reason and i left it as is.&#160; the migration may have automatically renamed it somewhere to eth0 (perhaps in the udev rules?), but not in /etc/network/interfaces .&#160; also something was different about the sshd setup.&#160; the colo providers fixed the issue and i am back up and running!</p>]]></description>
			<author><![CDATA[dummy@example.com (keb)]]></author>
			<pubDate>Sat, 03 Nov 2018 21:30:31 +0000</pubDate>
			<guid>https://dev1galaxy.org/viewtopic.php?pid=12629#p12629</guid>
		</item>
	</channel>
</rss>
