System doesn't start when power applied
The server starts when connected to the wall-plug. Almost always.
Once it did'nt, after an interrupted Linux installation.
I opened the system to short the power-switch connectors on the MotherBoard.
That solved the poblem.
The real solution:
Yes, there is a power button on the BBS2 !.
It is hidden behind the power logo on the front.
Press the logo gently, you feel a little click.
In the boot menu, set the computer to boot after power-restore.
Cannot boot from 1 TB disk
In one instance booting from a 1Tb disk seems not possible at all.
However, booting from a memory stick is aceptable in that situation.
In another situation (mine), booting from a 1Tb seemed only possible
when the 1Tb is in a Raid-controlled slot.
When placed in the mothermoard-slot, it isn't.
Even worse: the boot partition (mirrored) is then corrupted
by the synchronization with its mirror.
The 1Tb in the raid-controller seems to work fine.
Solution:
The mdadm driver gets it info from two places:
- the super-block on the mirrored partitions, if readable in time during boot
- the file /etc.mdadm/mdadm.conf during boot, on the initramfilesystem.
(I do not know how conflicts are handled).
You can update /etc/mdadm/mdadm.conf with an editor, or script update_mdadm.sh (provided in a few chapters before).
However, that updates only the version currently on yout root filesystem.
To sync the files on the initramfs with your current versions,
issue the following commands afterwards (in a root shell):
grub-mkdevicemap creates a table of current disk names,
update-intramfs -k `uname -r` -c -t recreates a ram filesystem
grub-install --root-directory=/ /dev/md0 adds a Grub boot menu to md0
Invalid UUID on /dev/md?
Sometimes a /dev/md? gets a wrong UUID,
or one of the md's UUID is copied to one of its members.
Suppose /dev/sdb2 and /dev/sdc2 are combined to /dev/md1.
The command blkid /dev/md1 /dev/dsb2 /dev/sdc2 then should
show 2 identical UUID's for /dev/sdb2 and /dev/sdc2,
and another (unique) UUID for /dev/md1.
If one of the partitions has the same UUID as the md,
or the 2 partitions do not have an identical UUID,
you messed up somewhere.
Break down the md and rebuild it like this:
- pvmove /dev/md1 will move data from md1 to other md's within the volume goup.
It will take a while until md1 is free of data.
While doing so, the volume group and its logical volumes
will remain working properly.
- vgreduce /dev/all_disks /dev/md1 will remove md1 from the volume group.
- pvremove /dev/md1 will clean the PV label from the md.
- mdadm --stop /dev/md1 will stop the md.
- mdadm --remove /dev/md1 will delete the md.
- mdadm --zero-superblock /dev/sdb2 will delete the mds's signature from sdb2.
- mdadm --zero-superblock /dev/sdc2 will delete the mds's signature from sdc2.
- blkid may still show the md's signatures on the sda and sdb2.
If so, then clean it more thouroughly with the following commands.
- for i in 0 1 2 3 4 5 6 7 8 9; do ls -al /bin; done > /dev/sdb2 will overwrite the md's signature from sdb2.
- for i in 0 1 2 3 4 5 6 7 8 9; do ls -al /bin; done > /dev/sdc2 will overwrite the md's signature from sdc2.
- blkid cannot show the md's signatures on the sda and sdb2 anymore.
If it still does, then you have no write access to the sdb and sdc.
(They are still active ? You are not root ?)
Then rebuild the array as described before.
Non autostarting MD's
After creating an MD (Mirrored Device) from 2 disk-partitions
is may not be restored after a reboot.
If it is part of a Volume Group, then the VG is not complete.
this may be caused by any of the PV's of the VG.
Then, no Logical Volume is derived from the VG.
If the root is on an incomplete LV, then there will be no root filesystem after booting.
After reboot, the console then shows an abnormal prompt:
(initramfs)
Possible cause
This situation may be generated by creating a mirrored disk
from 2 disk partitions,
followed by adding the md into a volume group,
without adding the new md into /etc/mdadm/mdadm.conf in the ramfs disk.
Continue booting
Enter the command: cat /proc/mdstat.
A list of Mirrored Devices (md's) is shown,
but one is missing [or more].
The command mdadm --auto-detect recovers the missing device.
Another cat /proc/mdstat command will show more md's.
Remember the name of that md; for example md4.
Also remember the names of the partitions being part of the md.
For example: sdb1 and sda1.
exit from the initramfs shell, to continue booting.
Maybe you're lucky !
If not , continue here ...
Now enter the missing md information into the mdadm.conf file as follows:
Find the UUID of the missing md withe the command:
UUID=`mdadm --detail /dev/md4 --scan | grep UUID | sed 's/ *UUID : //'`
Append this md's definition to the mdadm.conf file with:
echo "ARRAY /dev/md4 level=raid1 num-devices=2 UUID=$UUID" >> /etc/mdadm/mdadm.conf
Then exit to continue booting with restored md.
Repairing the ramfs
After booting, login and open a root shell.
Then grub-mkdevicemap creates a table of disk names,
update_mdadm to update /etc/mdadm/mdadm.conf, reflecting all current md devices
update-intramfs -k `uname -r` -c -t recreates a ram filesystem, including mdadm.conf
grub-install --root-directory=/ /dev/md0 adds a Grub boot menu to md0
Doesn't boot after a crash and a complete re-installation. The disk-lights remain on.
When you messed-up your MD's (Mirrored Devices) a little,
the must be re-synced again. That takes time. Several hours.
The file /etc/iniramfs-tools-conf.d/mdadm tells the computer to
- sync before continuing boot, or
- continue booting with a degraded boot-array, and sync it after booting.
Set BOOT_DEGRADED=yes if you do not want to wait.
After a fresh installation, and after installing the extra (mdadm) software,
the kernel may detect mirrored devices from a previous installation.
And tries to sync them.
This may take so long, that the system doesn't (seems not to) boot.
Shut down the system, and Remove half of the disks.
(leave the boot disk, of course).
Power-on, reboot, and clean the mirror information from the half-mirrored devices:
- mdadm md_dev --fail partition
- mdadm --stop md_dev
- mdadm --remove md_dev
here md_dev is something like /dev/md5, and partition is something like /dev/sde3.
disk reports to be 0 blocks.
You cannot create an MD with a disk partition because it appers to be too small,
or the number of partitions is too small.
Even when you try to create a filesystem onto it,
mkfs complains about the size.
You messed up the partition table.
Clean it:
- fdisk disk, remove all partitions, w
- fdisk disk, create 4 primary partitions of 10 cylinders, w
- fdisk disk, remove all partitions, w
- fdisk disk, create the partitions you needed, w
Cannot remove invalid MD's
You want to remove /dev/md3p1 (or alike), and use the commands:
mdadm --stop /dev/md3p1
It doesn't go away.
You probably got stuck in a previous attempt, and started over again.
One possible cause is a previous md's signature on a MD.
No, not the MD, just any md.
Try to stop all md's; maybe one is sucessful.
Then try again; if the first one has taken the others as hostage,
you may be more lucky now.
Another solution is: the md is part of a LVG (Logical Volume Group) as a PV (Physical Volume).
It may be have been auto-configured during boot.
First remove the PV from the LVG, and then you may stop the md.
Cannot remove PV from LV
You want to remove a physical volume (probably an MD) from a LVG (Logical Volume Goup),
and use the commands:
pvremove /dev/md3p1
It doen't go away.
You probably got stuck in a previous attempt, got stuck, and started over again.
A possible cause is a previous PV's signature on the MD.
The LVG is auto-assembled during boot.
A logical volume (/dev/all_disks/var) is activated,
and occupying the PV.
Move the data from the PV (pvmove), or just remove the LV from the LVG.
After that PV can be freed.
MySQL: cannot create database
After moving the /var directory MySQL cannot create a database anymore.
When using the -depth option, CPIO creates files first,
and directories on the fly as needed.
Those directories are then owned by the current uid.
Without the -depth option however, directories are created as copies of
the source, owned by the original owner.
In previous attempts the -depth option and subsequent wrong owner of
some directories made it for Mysql impossible to create a database.
Solution:(thanks: Dave Hartnoll).
Remove the -depth from cpio commands.
