Debian stucks at formatting 33%

Question

I'm trying to install Debian Squeeze 6.0.5 on a new HP Proliant Microserver N40L with 4 GB RAM and 1.5 GHZ and 2 new Seagate BARRACUDA 2TB HDD (delivered yesterday). The installation stuck at the point of formatting the 2 TB HDD at 33%. I gave him 16 hours, then I aborted the formatting and started the SEATOOLS HDD Utility to check for errors. The HDD passed the check and I freshly ereased both hdd with zero's by the SEATOOLS Utility. Now I restarted the installation and it got stuck again at 33%. How long I need to wait for this formatting?

Partitions of Software-Raid 1: /boot 500MB ext2 / 1995.9 GB ext3 swap 4 GB

With Alt + F4 I can't see any errors in the terminal, because the whole time my USB-Devices appear..., Swichting back to Alt + F1, it keep staying at 33%.

Is there any way to speed up this formatting? The hdd are new, so there is no need of secure deleting etc...

Update:

I found now out, that resync is incredible slow: http://up.picr.de/11594927qr.jpg writing with 700 k/sec. How could this happen? -> Estimated time: 30 Days!

I set already echo 50000 >/proc/sys/dev/raid/speed_limit_min without any change...

Thank you very much!

Answer 1

The "formatting" step inside the installation is not entirely precise with percentages (in fact it just divides 100% by the number of partitions to create), so when it appears to hang it might indeed be working properly.

I agree that 16 hours seems excessive, even for the notoriously slow ext3 initialization (writing to block devices happens synchronously, and ext3 initialization requires a lot of data to be written in small chunks spaced far apart, which is about the worst case), however keep in mind that at the same time the RAID initialization is also running with a certain minimum bandwidth (i.e. the disks are thrashing heavily).

Things you can do:

• think about your partitioning schema:
  • If the / partition is a real partition rather than an LVM volume, there is no need for a separate /boot, and you almost certainly want your swap space in the middle of the disk rather than at the end.
  • a 2 TB / partition is hell, because it takes ages to check if anything ever goes wrong, and you can do nothing about that.
• initialize the RAID with --assume-clean. This means that the RAID will not initially synchronize the disks, which is fine if you already wrote them as zeros
• create the file system from the command line (so you see more granular progress).

If you change your partitioning schema, I'd suggest something like

• partition 1: /boot (500 MB)
• partition 2: LVM PV
  • LV 1: / (500 MB)
  • LV 2: /usr (8 GB)
  • LV 3: /var (4 GB)
  • LV 4: /home (size according to personal preference, 100 GB is what I use)
  • LV 5: swap
  • LV 6: /srv/ (size according to personal preference and machine purpose)

It is totally okay to leave most of the space unallocated, you can change that later on, when the system is installed, and you can also add additional file systems for specific services that use lots of space, which means that if one of these services malfunctions and starts filling up the disk, it will only fill up its own partition (this is also why you have separate /var -- logging can work when the root partition is full.

Answer 2

16 hours is excessive. Something has gone wrong. When you say "the whole time my USB devices appear", do you mean that its spewing messages constantly? If so, what messages? Easy way is to take a screenshot using a phone camera, and just post that. What USB devices do you have connected?

Have you verified your install media is intact? I believe there is a menu option in the installer to check the install media.

Anyway, assuming none of the above is the problem:

First, use ext4, not ext3. There isn't really any good reason to use ext3. Also, consider using enterprise drives in servers (e.g., the Constellation line), depending on the type of duty this server will see. Much more expensive, but better able to handle a constant workload.

Second, you could do the format using mkfs from the command line. Just hit alt-f2, and press enter to get a command prompt. Then mkfs.ext4 -v -L "label" /dev/whatever (add whatever other options you want, see the mke2fs manpage). Then switch back to alt-f1, and get the thing to rescan (by going back to the main menu, etc.). You can then tell it to not format the disk, and just tell it the mount point.

Answer 3

Thank you very much for your answers.

The solution was to prepare the installation for raid 1, but just mount one hdd in the raid.

(Active devices: 2, reserved devices: 0, but just SDA and not SDA + SDB)

This solved the problem with resync and the installer worked normally.

After the installation of debian, I simply added the second hdd to my raid:

mdadm --add /dev/md0 /dev/sdb1 (this for every partition)

Result: resync speed increased from 750 k (at the installer) to 70000 k at the running system.

Answer 4

I would try two things.

I have noticed for some reason (and whether this is true or not, I'm not sure) that Linux is more sensitive to failing hardware. I have seen this on my home office computer a couple of times.

I've never had much luck with SeaTools. I've always used HDD Regenerator to double check for bad sectors, even on new drives. It isn't free, but it works really well.

The next thing I would try (or the first, since its free) would be a Memtest.

For that I would recommend Ultimate Boot CD. I would let it run a minimum of an hour - overnight preferably.

Out of those two, I would bet a lot of money that something would show up defective - and my money would be on memory.

Answer 5

The same thing happen to me when formatting a friend notebook, I tried to install 5 Linux distros and a Windows 7, and the same thing happened on all these O.S. then I discovered that the problem come from the HD, because It was damaged.

Answer 6

This is (the short version of) the explanation I found:

mkfs is prompting to confirm if existing ext4 partition detected. Prompt is not handled, causing install to hang.

In my case the log files stated a different question ("Found a dos partition table in /dev/sda1") but I bet the problem was the same. So I guess it could also be the same problem with any other command used by the installer (mdadm etc.).

The following workaround described at the Ubuntu bug report 1447600 was the thing that worked for me:

1. go to virtual console (alt+F2)
2. search for mkfs process (for me it was 'mkfs.ext4 /dev/sda1')
3. sudo kill -9 pid of that process
4. execute the same command: sudo mkfs.ext4 /dev/sda1 [had to confirm y/n]
5. go back to gui (alt+F1), where the installation automatically did a step backwards
6. restart the installation step

Answer 7

I had the problem with Ubuntu 16.4.3 installation.
Here my harddrive (250GB SSD) was formatted from a previous installations attempt of *ubuntu (there I chose guided installation with LVM within lubuntu).
ubuntu desktop and server installation stuck at 33% every time (switching to the console with alt+F4 (?!) the last statement was somethin like "DOS detected...")
wipefs on the destined drive didn't work for me(next install attempt stuck at 33%, too)

Solution for me:

- boot from a live medium and start gparted.
- try to delete all partitions
(!It was not possible to delete the LVM partition within gparted, I had to start the console and remove the logical volume (lv) and volume group (vg) by hand with (first search for the names with lvs and vgs) lvremove /dev/myname-vg/root lvremove /dev/myname-vg/swap_1 vgremove myname-vg
I dont know, maybe you can just remove the volume group, but dissolving the whole logical device with pvremove /dev/sda did not work)
- when all partitions are deleted, create a new ext3/4 partition that take all the space and write the changes to disk
- restart, then reinstall