Trying to reconfigure F9 to new computer hardware... firstboot?

[Dan Thurman]

What happened was that I spent a lot of time configuring
computer "A", and rsync'd the root filesystem onto disk
at computer "B".  I then rsync'd from hard disk to computer
"C" and everything was fine except that the hardware is
clearly different.

My X came up fine (I manually ran Xorg -configure, but as
for the rest of the hardware such as sound and "other hardware"
was clearly not the same so I used firstboot.

The instructions were:

1) mv /etc/sysconfig/firstboot /etc/sysconfig/firstboot.bak
2) rm /etc/sysconfig/firstboot
3) chkconfig --level 34 firstboot on
4) reboot

On rebooting, the screen starts in text screen, then "flips" over
to gui screen, then back to text screen, repeatedly, "forever"

5) If 1-4 does not work, then: touch /etc/reconfigSys
6) reboot

Same thing.

I searched the websites and could not find a solution.

So how can I reconfigure computer "C" hardware and
general setup (keyboard, mouse, sound, ...)?

Thanks!
Dan

[Mikkel]

Les Mikesell wrote:
>  It would be _really_ nice if the installer could be re-run in this
>  situation, offering to fix only the things that needed to be fixed
>  (re-detect hardware, build a working initrd, install grub, fix your
>  modprobe.conf and check your fstab and network setup).  You can do
>  this gunk by hand, but it means you have to know as much as anaconda
>  (which doesn't seem to be all that well documented...) about hardware
>  and drivers.  You can sort-of get most of the effect by making /boot a
>  separate partition, doing a basic install on the new hardware, then
>  removing everything except /boot and copying in your old stuff, but
>  that seems unnecessarily cumbersome.
>  
I wounder what doing an upgrade instead of a new install would do.
Would it accept the current install's values hardware and such, or
would it do its own checking/setup?

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

[Bruno Wolff III]

On Wed, Oct 29, 2008 at 10:14:43 -0500,
  Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  It would be _really_ nice if the installer could be re-run in this  
>  situation, offering to fix only the things that needed to be fixed  
>  (re-detect hardware, build a working initrd, install grub, fix your  
>  modprobe.conf and check your fstab and network setup).  You can do this  
>  gunk by hand, but it means you have to know as much as anaconda (which  
>  doesn't seem to be all that well documented...) about hardware and  
>  drivers.  You can sort-of get most of the effect by making /boot a   
I would think you could fix things up with a rescue disk pretty easily.
The rescue kernel will have the needed device drivers and you can chroot
to /mnt/sysimage and then run mkinitrd to fix up the initrd img files.
If the architecure and disk layout is the same this should cover most of
your configuration. Things that are missing are mostly going to be per
user preferences on which dvd drive is the default and the like.

[Les Mikesell]

Mike wrote:
>  Dan Thurman <dant <at> cdkkt.com> writes:
>  
> >
> > What happened was that I spent a lot of time configuring
> > computer "A", and rsync'd the root filesystem onto disk
> > at computer "B".  I then rsync'd from hard disk to computer
> > "C" and everything was fine except that the hardware is
> > clearly different.
>  
>  I am not sure that copying the root partition from one machine to another
>  is a good way to install Linux.
>  
>  Was there some special reason not to use one of the normal install methods
>  from the DVD or Live CD?  
The usual reason for doing this is that you have done extensive 
configuration and/or installed local or 3rd party software that would 
take a lot of time to repeat.  Or you just want to know how things will 
work out if you have to restore from your backups on a new machine.  Or 
maybe your computer died and you really do have to restore from backups now.

Or, you installed under VMware with a different host OS to test 
usability and now that you know everything works, you want to migrate 
your working setup to real hardware.

It would be _really_ nice if the installer could be re-run in this 
situation, offering to fix only the things that needed to be fixed 
(re-detect hardware, build a working initrd, install grub, fix your 
modprobe.conf and check your fstab and network setup).  You can do this 
gunk by hand, but it means you have to know as much as anaconda (which 
doesn't seem to be all that well documented...) about hardware and 
drivers.  You can sort-of get most of the effect by making /boot a 
separate partition, doing a basic install on the new hardware, then 
removing everything except /boot and copying in your old stuff, but that 
seems unnecessarily cumbersome.

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

[mike cloaked]

Dan Thurman <dant <at> cdkkt.com> writes:

>  
>  
>  What happened was that I spent a lot of time configuring
>  computer "A", and rsync'd the root filesystem onto disk
>  at computer "B".  I then rsync'd from hard disk to computer
>  "C" and everything was fine except that the hardware is
>  clearly different. 
I am not sure that copying the root partition from one machine to another
is a good way to install Linux.

Was there some special reason not to use one of the normal install methods
from the DVD or Live CD?

[Dan Thurman]

Les Mikesell wrote:
>  Mike wrote:
> > Dan Thurman <dant <at> cdkkt.com> writes:
> >
> >>
> >> What happened was that I spent a lot of time configuring
> >> computer "A", and rsync'd the root filesystem onto disk
> >> at computer "B".  I then rsync'd from hard disk to computer
> >> "C" and everything was fine except that the hardware is
> >> clearly different.
> >
> > I am not sure that copying the root partition from one machine to 
> > another
> > is a good way to install Linux.
> >
> > Was there some special reason not to use one of the normal install 
> > methods
> > from the DVD or Live CD? 
>
>  The usual reason for doing this is that you have done extensive 
>  configuration and/or installed local or 3rd party software that would 
>  take a lot of time to repeat.  Or you just want to know how things 
>  will work out if you have to restore from your backups on a new 
>  machine.  Or maybe your computer died and you really do have to 
>  restore from backups now. 
Well said!
>  Or, you installed under VMware with a different host OS to test 
>  usability and now that you know everything works, you want to migrate 
>  your working setup to real hardware. 
Yup!
>  It would be _really_ nice if the installer could be re-run in this 
>  situation, offering to fix only the things that needed to be fixed 
>  (re-detect hardware, build a working initrd, install grub, fix your 
>  modprobe.conf and check your fstab and network setup).  You can do 
>  this gunk by hand, but it means you have to know as much as anaconda 
>  (which doesn't seem to be all that well documented...) about hardware 
>  and drivers.  You can sort-of get most of the effect by making /boot a 
>  separate partition, doing a basic install on the new hardware, then 
>  removing everything except /boot and copying in your old stuff, but 
>  that seems unnecessarily cumbersome.
>  
Perfect!

Also...

1) To test and see if rsync would work in restoring crashed,
     update-damaged, user or "act of god" missing/destroyed
     filesystem or broken hard disk as a backup/restore method.

2) Clone rsync'd filesystems to other computers to save a LOT
    of time, which remains to be seen.

I discovered that the reason for the text-screen/gui-screen flip-flop
was that I created a new xorg.conf file to reflect the new graphics
hardware and used the Xorg --configure command to create the
xorg.conf file which was placed in ~/xorg.conf.new.

I then copied this file to /etc/X11, rebooted, and there was flip-flopping.

I read on a forum that in F9, you simply do not have to have xorg.conf
in /etc/X11 and xorg would automatically find and setup the graphics.
Ok, so I renamed xorg.conf to xorg.conf.bak, rebooted, and lo and behold!
It worked! So the problem is figuring out how to create a xorg.conf file
that will work properly - although I could just leave it missing in /etc/X11
but what are the consequences in doing that?

Then, I redid the steps 1-4, rebooted and firstboot comes up!

However....

When I got to the last step for "Hardware profiles", it came up with
a blank textbox showing no hardware!  Hmm...  I pressed the "Back"
button hoping that it would redo the hardware profiling - no luck!
So, how can I force a new hardware profiling?

BTW: Ever since I had been rebooting since the first time I rsync'd
root into my partition, HAL failed to start and I have not been able
to get this to work on boot.  When I was fully booted, logged in as
a normal user, became root and issued the command:

/usr/sbin/hald --verbose=yes

hald had started with no errors....  what gives?

All of my services started with no errors except for hal.

So at this point, I am left wondering if all of my hardware
was even detected and updated (which I doubt), the xorg.conf
question, and that the hal daemon fails to start at boot time.
Seems this is all (so far) that I need to resolve.

Any ideas on where I can go from here?

Thanks!
Dan

[Dan Thurman]

Bruno Wolff III wrote:
>  On Wed, Oct 29, 2008 at 10:14:43 -0500,
>    Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>    
> > It would be _really_ nice if the installer could be re-run in this  
> > situation, offering to fix only the things that needed to be fixed  
> > (re-detect hardware, build a working initrd, install grub, fix your  
> > modprobe.conf and check your fstab and network setup).  You can do this  
> > gunk by hand, but it means you have to know as much as anaconda (which  
> > doesn't seem to be all that well documented...) about hardware and  
> > drivers.  You can sort-of get most of the effect by making /boot a  
> >     
>
>  I would think you could fix things up with a rescue disk pretty easily.
>  The rescue kernel will have the needed device drivers and you can chroot
>  to /mnt/sysimage and then run mkinitrd to fix up the initrd img files.
>  If the architecure and disk layout is the same this should cover most of
>  your configuration. Things that are missing are mostly going to be per
>  user preferences on which dvd drive is the default and the like.
>     
I tried this:

1) Boot F9 LiveCD
2) Press Ctrl-Alt-F1 for text mode login
3) log in as root
4) mkdir /tmp/sysroot
5) mount /dev/sda7 /mnt/sysroot          (sda7 = root partition)
6) mount /dev/sda6 /mnt/sysroot/boot (sda6 = boot partition)
7) chroot /mnt/sysroot
8) cd /boot
9) mkdir orig
10) mv initrd* orig
11) mkinitrd -f /boot/initrd-2.6.26.6-79.fc9.i686 2.6.26.6-79.fc9.i686

      Note: the following message was spit out after running mkinitrd:
      # resolveDevice: device spec expexted
      # resolveDevice: device spec expexted

      I think that perhaps something is wrong here.... as seen below
      when the kernel fails to start with this new initrd

12) chcon -u system_u initrd-2.6.26.6-79.fc9.i686
13) exit
14) umount /mnt/sysroot/boot
15) umount /mnt/sysroot
16) reboot

On rebooting, then grub starts.
Headers showing grub specific selection for
vmlinuz & initrd and the details are displayed,  then

Decompressing Linux... Parsing ELF... done.
Booting the Kernel.
Redhat nash version 6.0.52 starting
Mount: error mounting /dev/root on /sysroot as ext3: No such file or 
directory
setuproot: moving  /dev failed: No such file or directory
setuproot: moving  /proc failed: No such file or directory
setuproot: moving  /sys failed: No such file or directory
Mount failed for selinixfs on /selinix: No such file or directory
switchroot: mount failed: No such file or directory

I next went back and restored the original initrd and it booted fine
as before I created new mkinitrd, although the hardware devices are
still wrong (sound, for example).

So... what's next?

Dan