I have an older Debian 4.0 linode profile that is failing to boot up after a reboot, and I am not sure why. The log it gives me is below. I am able to mount all of the partitions it uses from another profile, as well as the rescue system. fsck found no disk errors. Anyone have any suggestions on what might be causing this to happen?

Last login: Sat Aug 22 13:13:15 2015 from 10.4.1.11
[*** lish] Sat Aug 22 13:26:21 EDT 2015
[*** lish] Linode Shell (lish) Console starting...
[*** lish]
blkfront: xvdc: barriers enabled
xvdc: unknown partition table
XENBUS: Device with no driver: device/console/0
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
EXT3-fs: barriers not enabled
kjournald starting. Commit interval 5 seconds
EXT3-fs (xvda): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 202:0.
Freeing unused kernel memory: 412k freed
Write protecting the kernel text: 5704k
Write protecting the kernel read-only data: 1384k
NX-protecting the kernel data: 3512k
systemd[1]: Failed to mount tmpfs at /sys/fs/cgroup: No such file
or directory

For reference, there is no "tmpfs" called for in fstab. The devices match up with the drives associated with the machine's profile.

/dev/xvda /     ext3    defaults 0 0
/dev/xvdb swap  swap    defaults 0 0
/dev/xvdc /home ext3    defaults 0 0
proc    /proc   proc defaults 0 0

Are you aware that Debian 4 stopped getting security updates in 2010? You should be terrified that you are publicly admitting you have a Debian 4 server.

You should boot that in rescue mode, migrate your data off and upgrade to something recent, never to consider this poor ancient Linode again.

That being said, it sounds to me like you are running too new of a kernel. I may be wrong of course, but you may want to set your kernel back to 2.6.18 or something.

I have tried a variety of older kernel versions, but that doesn't seem to help. I really just need to get this box to boot once.. a migration plan is already in order.

The bit of log you posted seems to be a bit off to begin with. For starts Debian 4 probably didn't have systemd and systemd makes certain presumptions about how a system should behave these days.
Can you restore sysvinit - you'll probably have better luck. But I'm not sure how or what was done to get systemd on an old system like that.

This system appears to have been dist-upgraded to Debian 8 over time, possibly as a result of using sid packages. Going back to sysvinit may not be feasible.

How would one restore sysvinit on a linode? The information I can find on google tells me to boot into grub to change some kernel parameters, but I am not sure how that fits into the Xen vps system.

https://wiki.debian.org/systemd#Configuring_for_testing

What sorts of things might cause systemd to be unable to mount /sys/fs/cgroup?

Fyron,

In your configuration profile, there's a section called "Filesystem/Boot Helpers". In there, you may want to see if any of the features on are such as distro helper. If they are, I would turn them off. I think they make some assumptions about distros such as Debian that are only relevant for recent releases (6,7,8). This is of course if you still have a Debian 4 disk (or backup).

Worse comes to worse, you don't need it to boot to get your files off of it. You can mount your Debian 4 disk to a new distro.

Also, if you convert your Linode to the new KVM Linodes, you can use the new grub boot option. https://www.linode.com/docs/platform/kvm

The only thing that I need to recover from this system is MySQL data. I have found that my backup script appears to have stopped working correctly, and I do not have recent backups. I tried copying the data files to a new ubuntu-based host, but the mysql server on it was not able to read the innodb databases properly (MyISAM tables worked though). If I can get the old system running, I should be able to run mysqldump to get the data out.

Disabling the distro helpers option does not seem to have made a difference.

Converting this system from Xen to KVM seems a bit risky.