Boot Problems with using EXT4 in XEN environment

I run a XEN virtualization platform based upon SLES 11 SP4. I’ve noticed that OpenSUSE 42.3, LEAP 15 and SLES 12 SP4 will all fail when installing as a new client.
The installation will run and then after a reboot, the CPU will go to 100% and you have to eventually kill the virtual client.

My testing with LEAP 15 seems to indicate that it is an issue with EXT4. At this stage, I’m not using BTRFS and normally choose EXT4 as the root disk format.
After trying all sorts of ACPI/PCI kernel switches, what finally worked was not to use EXT4. On a test machine I used BTRFS and on my new real machine, I used EXT3 and they both rebooted okay.
Don’t know is this is a bug, or a documented ‘feature’ but it caused me a lot of grief and I thought I’d share my experience in case someone else can benefit.

Wouldn’t it bee better to have this asked in the Virtualization sub-forum, where most probablt other users that use Virualization will look if they can help?
When you agree, please ask here for this to be moved there.

Agreed that this type of post would go relatively unnoticed in this Forum and should have been posted in the Virtualization forum.

That said,
There isn’t enough detail to know what is happening for those machines which can’t boot, Circumstantially it might appear to be an EXT4 problem, but hard evidence is needed because unless a bug was introduced recently I don’t know anyone else who has noticed what you describe.

Especially since your VM does seem to boot up the first time successfully and has a problem only on first reboot points even more so to a problem likely unrelated to the fs.

The following article is pretty exhaustive describing how to collect logs, one will work for you. There might also be something in your HostOS logs.


Happy for this post to be moved to Virtualization sub-forum. My initial context was hours of Internet searching where people had reported the same issue with bare metal laptops, most going down the acpi track, some unresolved as far as the post. EXT4 could well have been the issue in some of those as well, but this is only speculation.

Just a clarification on the boots.
The first boot is the first boot of the install sequence which is off a DVD or in my case a network installation point.
The second boot of the install sequence (which is the first boot of the new virtual) is the one that fails.

I have now conclusively determined that using EXT4 is what causes the issue. I’ve now built a couple of Virtuals using either EXT3 or BTRFS and they install and run withot a hitch.
As for logs, there is nothing in the HOSTOS logs. As I can never get to the faulty machine, I’ll have to try another test install using EXT4, kill the machine and try mounting the filesystem externally to try and see any logs.

Essentially, using EXT3 solves the issue for me and I’m simply reporting the problem in case someone else has a similar problem.

A standard install for any OS and any distro typically goes through 2 stages…

Stage 1 - configure, and then apply a layout to the target disk, including partitioning, and formatting.
Stage 2 - Writing to the disk, including OS files, application files, configurations, etc.

There is a reboot after Stage 1 to enable the changes written to the disk, which includes disk formatting
No files can be written to an unformatted disk, the install has to fail (ie no files written to disk) if the partitions aren’t created and formatted first.
After Stage 2, then the system reboots for the last time, and then the User is presented either with a login page or is automatically logged in and sees the Desktop for the first time.

So, unless you look at the disk and the partitions are completely empty or there are no partitions, I can’t see how the EXT4 formatting has anything to do with a boot failure… More likely there is a bootloader problem of some kind, but unless you collect your bootlog for your first boot, you can’t know what actually happened.


Will be moved to Virtualialization and is CLOSED for the moment.

Moved from Install/Boot/Login and open again.