[GLLUG] Initrd issue

[Ken Smith]

> On 12 Mar 2018, at 22:25, James Courtier-Dutton <james.dutton at gmail.com> wrote:
> 
>> On 12 March 2018 at 19:20, Ken Smith via GLLUG <gllug at mailman.lug.org.uk> wrote:
>> Hi All,
>> 
>> 
>> I know this is a long shot but I'm helping a colleague virtualise (Hyper-V)
>> a RedHat 8 system. Yes I know - ssh, tls, and on an on are full of holes.
>> But they have an application on the machine and well anyway......something
>> about the 2.4 kernel and the version of gcc.... Its burried inside a lan and
>> has no internet exposure. Anyway here's the issue....
>> 
>> 
>> I've done a test plain RH8 installation on Hyper-V and it runs fine, much to
>> my surprise. So even if its not supported it seems to work, network and all.
>> 
>> Meanwhile on the P to V migrated system I've fixed up grub, grub.conf and
>> fstab and rebuilt the initrd. I think its running the nash scripts in the
>> initrd and I get the error:
>> 
>> Warning: Unable to open the initial console.
>> 
>> Earlier I was having a problem when running the RH8 rescue system. I found
>> that the /dev/ filesystem needed manually mounted in /mnt/sysimage/dev
>> before I did "chroot /mnt/sysimage". grub-install wouldn't work without the
>> manual mount of /dev. I wonder if this is related. /dev/console is there
>> when I run mkinitrd with /dev mounted manually. But there is probably
>> something else in there I've missed. I removed the original cciss statement
>> from modules.conf to stop it looking for the raid controller on the original
>> host. I would have thought the a basic vga console module would be in there
>> anyway but perhaps not...
>> 
>> Any clues???
> 
> Hi,
> I have run into similar problems in the past.
> Redhat seems to only install in the initrd the modules that the hardware needs.
> So, when you move from hardware to virtual, you need to add the missing modules.
> The easiest way to fix this would be to copy the kernel and initrd
> from your working plain installation, onto the P to V version.
> It should then boot fine.
> This appears to be specific to Redhat.
> I think there is a config item for Redhat to make it more portable,
> but the default appears to not do it.
> 
> I have found that debian and ubuntu seem much more willing to move
> from system to system without modification of the HDD image.
> 
> Kind Regards
> 
> James

Hi all,

Thank you for all your replies. It's running now. My dive into the initrd was a red herring. 

I'm aware of the various device name changes but the thing that got me was that in a RH < 2.6 system /dev has some pre-configured devices, including /dev/console. My bad, I had overlooked that.

The original system is currently in production on physical hardware in a client data centre. The aim is to retire the elderly hardware and run it virtually elsewhere. As I said before, the application is stuck on 2.4 for various reasons........ For the benefit of others who may be daft enough to try this in the future, here's what we did. 

With most daemons shutdown and users off the system made a copy of it using rsync to a USB disk plugged in locally. That copy was tarred/gz up and copied over the 'net.

The tar image was unpacked using another vm, with a 2.6 kernel, to a virtual disk. This was the first error. When this virtual disk was mounted on a 2.4 rescue system the symlinks had vanished. Repeating this process on a 2.4 kernel and the symlinks restored just fine.

Using a RH8 rescue system, corrected fstab, grub.conf, ifcfg-eth0, removed the cciss reference from modules.conf to stop it looking for the raid controller in the original host. 

Went round in circles because I had omitted to bring /dev from the original system and after reinstating the grub boot loader and initrd, reconstituted /dev from a test RH8 install I had done. 

At that point boot success. There followed some network reconfigures and testing. We will restore a backup of the application and after checking integrity it will be promoted to production and the original system retired.

Thanks

Ken








-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.