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
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?
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 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
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
On Wed, Oct 29, 2008 at 10:14:43 -0500, Les Mikesell lesmikesell@gmail.com 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.
Bruno Wolff III wrote:
On Wed, Oct 29, 2008 at 10:14:43 -0500, Les Mikesell lesmikesell@gmail.com 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
-
Bruno Wolff III -
Dan Thurman -
Les Mikesell -
mike cloaked -
Mikkel