[vox-tech] Conversion

[Matt Holland]

On Thursday, May 22, 2003, at 10:52 AM, Mike Simons wrote:
> On Mon, May 19, 2003 at 01:41:41PM -0700, Richard Crawford wrote:
>> Hypothetically speaking, how difficult would it be to switch an
> existing
>> RH box to Debian?  Assuming, of course, that all of the home
> directories
>> and downloaded extra software live on different partitions than
> root...
>
>   This is easy ... as Gabe mentioned it can be done remotely.

Is it really?  I've been having problems doing this myself, as I try to 
migrate a Gentoo system to Debian stable.  The main problem is that I 
can't get the system to boot, and I think this is because I can't get 
mkinitrd to work.  I followed the instructions in the Debian install 
guide (section 3.8 or so, I think), but started having problems with 
the kernel installation step.  I get:

# apt-get install kernel-image-2.4.18-k6
<warning about initrd, telling me I need to configure my bootloader 
manually>
Setting up kernel-image-2.4.18-k6 (2.4.18-5) ...
/usr/sbin/mkinitrd: Cannot determine root file system
Failed to create initrd image.
dpkg: error processing kernel-image-2.4.18-k6 (--configure):
  subprocess post-installation script returned error exit status 29
Errors were encountered while processing:
  kernel-image-2.4.18-k6
E: Sub-process /usr/bin/dpkg returned an error code (1)

The key being "/usr/sbin/mkinitrd: Cannot determine root file system".  
Furthermore, if I try to spoon feed mkinitrd with:

# mkinitrd -o test.img -r /dev/hdb1 /lib/modules/2.4.18-k6

I get the same error.

I have noticed some curious things when I'm in the chroot environment.  
For one thing, /etc/mtab claims that /proc is the only mounted file 
system:

# cat /etc/mtab
proc /proc proc rw 0 0

And df has a similar view:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
proc                  1.1G  460M  616M  43% /proc

The curious thing is that it seems to think that the root filesystem is 
mounted under /proc; the used/available information is correct for the 
file system on the root device.  Doing a "mount -a" doesn't change 
anything.  My /etc/fstab looks like:

# file system   mount point     type    options         dump    pass
/dev/hdb1       /               ext2    defaults        1       1
/dev/hdb2       none            swap    sw              0       0
proc            /proc           proc    defaults        0       0
/dev/fd0        /mnt/floppy     auto    noauto,rw,sync,user,exec 0 0

So... it seems to me that maybe something is wrong in the chroot?  It 
seems that if this is the way things should be, it would be impossible 
to run mkinitrd from inside a chroot, in which case it would seem like 
for your initial boot you'd have to use a kernel that doesn't use 
initrd, but that hasn't come up in any of the documents I've read 
(including the Debian planet article that was mentioned earlier in this 
thread).  Maybe I should try this on a RH system so I have a basis for 
comparison.

Ah, one more thing.  I'm using Grub as my bootloader, as I'm keeping 
the Gentoo system around for the time being, and it's set up with Grub. 
  My Grub entry for Debian looks like:

title=Debian
root (hd1,0)
kernel /boot/vmlinuz-2.4.18-k6 root=/dev/hdb1 
initrd=/boot/initrd.img-2.4.18-k6
initrd /boot/initrd.img-2.4.18-k6

which I got from a newsgroup thread on booting a Debian kernel with 
initrd in some newsgroup somewhere.  But I'm right in assuming that 
this won't work without a working initrd image, no?  So far, every boot 
attempt I've made with the Debian kernel has resulted in a kernel panic 
because it can't mount the root file system.

Any idea what I'm doing wrong, or if maybe my Gentoo system is just 
sufficiently wonky that the chroot command doesn't work as it does 
elsewhere?

Matt

>   The main issue you should keep in mind is the various fancy Gnome and
> KDE applications might not cope with the .config files in your home
> directories.
>
>   If you have problems with any applications after the switch, you 
> might
> want to make a new user account and see if the new user has the same
> problem.  If they don't you should figure out which config file is a
> problem, or just copy your data some place else... nuke the old home
> directory and make a new one
>   deluser FOO; adduser
> then more the data back...
>
> -- 
> GPG key: http://simons-clan.com/~msimons/gpg/msimons.asc
> Fingerprint: 524D A726 77CB 62C9 4D56  8109 E10C 249F B7FA ACBE
> <mime-attachment>
--
Matt Holland
Population Biology Graduate Group
University of California
Davis, CA 95616