testing - fresh install with debootstrap
Hey all,
Just thought I'd share some of my recent experiences with doing a fresh
install of debian - testing.
What I normally do when setting up a fresh install is to plug the disk
into a removable hdd tray that I have but this time I used a usb - ide
interface instead which didn't effect anything except for speed - usb
1.1 controller.
I then partition the drive, make the file systems and use debootstrap to
install the base:
debootstrap --arch i386 --unpack-tarball /tmp/basedebs.tar woody /mnt/
and I got basedebs.tar from, I think:
http://http.us.debian.org/debian/dists/woody/main/disks-i386/base-images-current/basedebs.tar
After that I normally chroot to the mount and mount proc:
chroot /mnt /bin/sh
mount -t proc proc /proc
I will then update /etc/apt/sources.list and run base-config - which I
didn't this time and is why it ended up being so painful, I instead
updated sources.list and straight away did a apt-get update and upgrade
- but through dselect. One of the first packages I selected for install
was udev - dooh, don't do this :( cause it stuffs everything from here
on in, why:
ssh and a few other packages failed to install because of a whine about
chage - which after a little search I realised was linked to passwd and
and shadow passwords which I knew where configured by base-config so I
tried to run it and got:
#base-config
Terminated
dooh - strace showed that it was failing to open some files in dev,
which didn't exist cause I'd already installed udev.
a bit more of a search and I found that I could configure passwd with:
dpkg-reconfigure passwd
I could then at least finish the upgrade.
I then built a kernel and installed it (2.6.12 - debian version).
What I normally do then is to put the drive in the target system boot up
the target with knoppix and install grub, why do I do this? because I've
never found a way to do it in the other system, where you have two hard
drives in a system and trying to install it on the "secondary" drive.
Anyways I boot with the cd and mount all the partitions, chroot and then
run:
# grub
grub> root (hd0,0) # where your /boot is
grub> setup (hd0) # puts GRUB files on /dev/hda, modify if you want
grub> quit
a partition table will probably help those ?
# fdisk -l /dev/hda
Disk /dev/hda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 6 48163+ 83 Linux
/dev/hda2 7 249 1951897+ 82 Linux swap / Solaris
/dev/hda3 250 19457 154288260 5 Extended
/dev/hda5 250 492 1951866 83 Linux
/dev/hda6 493 1221 5855661 83 Linux
/dev/hda7 1222 1464 1951866 83 Linux
/dev/hda8 1465 19457 144528741 83 Linux
# mount
/dev/hda5 on / type ext3 (rw,errors=remount-ro)
tmpfs on /dev/shm type tmpfs (rw)
/dev/hda1 on /boot type ext2 (rw)
/dev/hda6 on /usr type ext3 (rw)
/dev/hda7 on /var type ext3 (rw)
/dev/hda8 on /home type ext3 (rw)
Anyway the grub install didn't work this time because, you guessed it no
dev (whinged about no BIOS, or something), so I did a hack, from out of
the chroot I did:
rsync -av /mnt/dev/ /mnt/dev.udev/
rsync -av /dev/ /mnt/dev/
and then from within the chroot ran grub again and it worked :) - yeah
I then rebooted my machine, and you guessed it forgot to rsync the udev
back - but hey it booted, I then played around installed X (xorg),
installed the nvidia drivers and some other stuff, remembered to rysnc
udev back again and rebooted and managed to end up where I was a week
ago (hey I wasn't in a hurry and it was usb 1.1), where it failed to
boot, the kernels last message was, something like:
failed to init Console
(if someone has the correct log here it might help those who are
searching for it)
my only guess was that rsyncing the udev dev back again had deleted the
console device and for some reason udev isn't populating it, so I
rebooted with knoppix and rsync'ed knoppix's dev back on and rebooted
and it worked - yeah :D
This would have to be a bug somewhere but since I've got a machine at
work that is pretty well the same:
amd - nvidia .... and I've got debian-testing installed, it's upto date,
same kernel, xorg, same nvidia drivers ...... and it doesn't have this
problem I'm thinking that it's going to be hard to find who is
responsible - udev seems like the obvious answer.
Anyway I hope this helps someone,
dlg
Reply to: