Any idea why Debian complains about a start job failure on boot after a new install?
- 
 @Pete-S Yeah I tested it with a VM yesterday on my desktop in Virtual Box after I had my problems on the physical machine. Worked fine. I even did my md -> lvm > XFS setup using two VHDs. Installed and fired right up with a nice RAID 1 array. I can’t figure it out. It’s like there is something up with both disks. I’ve blown them out with Gparted and DD. I guess I can change the disk label to GPT and see if that makes a difference. I’m at a total loss... 
- 
 @Pete-S I’ll try later with the default install that the partitioner wants to do and see if that changes things. Man, this is a real head scratcher. 
- 
 I did another try with setting things up manually in the installer with raid1 as well. 
 Also works. If I were you I would have a look at uefi settings in your bios. 
 I usually just disable it so I don't have to deal with any problems, but maybe you need it.Some BIOS also have bugs in their uefi implementation. So maybe upgrade the BIOS as well. 
- 
 @biggen said in Any idea why Debian complains about a start job failure on boot after a new install?: @Pete-S Yeah I tested it with a VM yesterday on my desktop in Virtual Box after I had my problems on the physical machine. Worked fine. I even did my md -> lvm > XFS setup using two VHDs. Installed and fired right up with a nice RAID 1 array. I can’t figure it out. It’s like there is something up with both disks. I’ve blown them out with Gparted and DD. I guess I can change the disk label to GPT and see if that makes a difference. I’m at a total loss... Label shouldn't make any difference. When reusing drives that has been in md raid you can use mdadm --zero-superblock /dev/sdXto wipe the raid info from it.
- 
 @Pete-S Yeah I have the Bios set to Legacy Boot which I assume means that UEFI is turned off, When I say “disk label” I mean partition type. So DOS = MBR. That is how the disk is partitioned now. I appreciate you testing in a VM. I’ll try it again later with the default installer partitioning. If it fails to work then I don’t know... I’ve tried to zero the md superblock, after that fact, I’m not sure it works anymore. If I boot into Debian (after waiting for the failed job start) on that disk and run that command, I get “couldn’t open for write. Not zeroing” for that drive /dev/sda”. I swear I’ve never had issues with Debian. Very odd indeed. 
- 
 @biggen said in Any idea why Debian complains about a start job failure on boot after a new install?: I’ve tried to zero the md superblock, after that fact, I’m not sure it works anymore. If I boot into Debian (after waiting for the failed job start) on that disk and run that command, I get “couldn’t open for write. Not zeroing” for that drive /dev/sda”. If you created the raid on the device, I think you should zero the superblocks on /dev/sda But if you created the raid on the partition I think you need to zero the superblocks on /dev/sda1 
- 
 @biggen said in Any idea why Debian complains about a start job failure on boot after a new install?: When I say “disk label” I mean partition type. So DOS = MBR. That is how the disk is partitioned now. What you say is confusing to me. What does fdisk -llook like on the system?
- 
 @Pete-S I’m not there now but shows disklabel as “dos” if I remember correctly. So partition type should be plain ole MBR I believe. 
- 
 @biggen said in Any idea why Debian complains about a start job failure on boot after a new install?: @Pete-S I’m not there now but shows disklabel as “dos” if I remember correctly. Please post it when you have access to the system. And also the exact error you get in the log. 
- 
 @Pete-S Ok, I went ahead and let the installer partition it using the defaults for LVM. Everything is working! The installer creates a small primary partition and installs /boot to it. It then creates an extended partition with the remainder of the drive and slices up logicals out of that for the LVM. It puts “/“ in vg1 as “lv root” and puts /swap in vg1 as well as lv swap”. I was not creating a /boot. Never have. I was just creating a primary for the “/“ and then saving some of it for an extended /swap. I’ve done this forever. It even works in a VM. I have no idea why I couldn’t get it to work on the physical machine.