RAID Virtual-Disk Recreation: Changed SCSI ID Prevents Legacy Linux Boot

Source symptom and evidence

The source says an accidentally deleted RAID1 virtual disk on a 2208 controller was recreated, after which the OS could not boot. The initrd waited for an old /dev/disk/by-id/scsi-... partition identifier:

The later directory listing contains a different SCSI identifier:

The source attributes the boot failure to stale identifiers in fstab, GRUB configuration and the initrd after virtual-disk recreation. Recreation can change an identifier; it does not prove that data was preserved or that an array should be recreated to fix an ordinary boot issue. Do not delete/recreate an array as a generic recovery step.

Identify the actual installed system

The narrative identifies SUSE11SP3 and a matching toolkit kernel, then uses lsblk and mount to inspect the installed partitions. Its supplied lsblk screenshot, however, shows CentOS-labelled LVM and /dev/sda2 mounted as /boot:

That screenshot does not establish the root layout of the stated SUSE system. The later /dev/sda2 mount below is only the source’s separate rescue example. Determine the real root filesystem/LVM and any separate boot/EFI filesystems first; substituting a boot partition for root makes the chroot invalid.

Source rescue workflow, with device placeholders

1. Boot the matching installation/rescue medium. The source uses F11 to select DVD-ROM, then Rescue System. 2. Log in using that rescue environment’s documented console method. The source’s media-specific login description is not a password-recovery method for an installed system.

3. Mount the verified installed root filesystem. The source printed mount /dev/sda2 /mnt; use the actual identified root device instead:

mount <ACTUAL_ROOT_DEVICE> /mnt
cd /mnt

4. Inspect the installed /etc/fstab and legacy GRUB /boot/grub/menu.lst. From the rescue shell these are under /mnt. Correct stale device references consistently to verified current persistent identifiers, preserving mount options and partition roles. The source’s later menu.1st spelling is corrected to menu.lst. Its suggestion to replace identifiers with sd* names is not a stable universal mapping; verify the exact disk/partition instead of using a wildcard or guessed enumeration.

5. Mount any required separate boot filesystems for the actual system before rebuilding, then prepare the source’s chroot bind mounts:

cd /
mount /dev /mnt/dev -o bind
mount /sys /mnt/sys -o bind
mount -t proc none /mnt/proc
chroot /mnt

6. In the installed SUSE environment, rebuild its initrd after correcting configuration:

mkinitrd

7. Review successful completion and the selected boot/initrd configuration, leave the chroot, then complete the planned rescue shutdown/reboot workflow:

exit
reboot

The source’s final mkinitrd step is necessary for its stale-initrd case; editing only on-disk configuration leaves old embedded references. The exact dependencies differ by distro/release, and this is not an instruction to run a legacy SUSE tool on the CentOS screenshot’s system. No volume recreation, filesystem repair or recovery guarantee is implied.