Hello, I recently reinstalled FreeBSD 8.0 on my computer, after a long hiatus (last version before that was 7-CURRENT before 7.0-RELEASE, on an old computer). I read a lot of documentation to try and make sure I caught up with any important changes before messing too much with the system. I did a similar procedure as I used to on the old system, grabbed a fresh ports.tar.gz, uncompressed it under /usr, installed cvsup and proceeded to updating /usr/src to -STABLE (using the RELENG_8 tag).?So far, so good. I made a custom kernel config file based off of GENERIC, added only a few options (like sound and console customization options), and followed the steps listed on /usr/src/UPDATING: # cd /usr/src # make buildworld # make kernel KERNCONF=MYKERNELNAME <reboot into single> .. Or so I wish. During boot, I got a MOUNT ROOT ERROR (nothing after that). By pressing '?' I could see that it was recognizing my hard drives and slices all differently than the -RELEASE (GENERIC) kernel did. The old one saw my first disk as ad8 (2 NTFS partitions, ad8s1 and ad8s2), then the second disk as ad14 (with a NTFS partition as ad14s1 and then the FreeBSD slices as ad14s[a-f]). The -STABLE kernel sees them as ad10 and ad16 respectively. I then tried to finish the boot process by entering "ufs:/dev/ad16s2a" at the prompt, but it threw me at a single mode shell. I do believe it had shown some error there, but it got pushed off screen by the stream of "interrupt storm (irq21)" messages that have plagued me on this computer (that usually magically stops if I mount a cdrom, but in this case that didn't do it). Trying to fix the issue, I manually mount /usr (now being seen as ad16s2f instead of ad14s2f) and proceed to replacing /etc/fstab's entries with their "new" device numbers. A couple of commands later, the file looks correctly updated with this new scheme. I do an exit on that shell just to get to a kernel panic message and a quick reboot. I tried to unload the -STABLE kernel and boot from the -RELEASE one, but now the system hangs right after it tries to find my disks. I give up and reinstall (that first install had given me quite a headache with incorrect drive geometry [that I had to fix with a lot of research to get to TestDisk and GAG], so I thought it was best to just start fresh). I do the same procedure this time, but paying extra attention to any details I could have overlooked before. One of them was to make a kernel (-STABLE) out of a renamed copy of GENERIC (no options added or removed). I also decided on doing the remaining steps listed on /usr/src/UPDATING before rebooting; I thought the drive numbering difference could be related to something in userland that was missing when booting the -STABLE kernel with -RELEASE userland. And I got the same mount root error message, and again it shows the drives as ad10 and ad16 instead of ad8 and ad14. The difference is that this time I did not try to update /etc/fstab before resorting to this list (I had been browsing it for the past 3 days trying to find any hints on this, as well as reading /usr/src/UPDATING in full again). I can get the system to boot normally if I unload the -STABLE kernel and load the -RELEASE one. But I can't figure out for the life of me why does -STABLE shift my drive numbers around. I also understand how I'm supposed to provide logs and more information, but I'm unsure what to give for this. Just tell me what kind of info/log you need and I'll try to get them. Could anyone please enlighten me? Thank you very much in advance, Fred
On Thu, May 13, 2010 at 11:00:38PM -0300, Fred Souza wrote:> I did a similar procedure as I used to on the old system, grabbed a > fresh ports.tar.gz, uncompressed it under /usr, installed cvsup and > proceeded to updating /usr/src to -STABLE (using the RELENG_8 tag).?So > far, so good.1) We use csup now, not cvsup. csup comes with the base system, so there's no need to install cvsup. 2) I'm not sure why you're downloading ports.tar.gz and extracting it. This means that /var/db/sup/ports-all won't match what's in /usr/ports. You should just use csup to populate /usr/ports. You can do this by doing: csup -h <cvsup-server> -L 2 /usr/share/examples/cvsup/ports-supfile You can also populate /usr/src (and thus /var/db/sup/src-all) by doing: csup -h <cvsup-server> -L 2 /usr/share/example/cvsup/stable-supfile There are also /etc/make.conf variables you can set to make this process easier once you've populated /usr/ports and /usr/src; you can do something like "cd /usr/ports ; make update".> I made a custom kernel config file based off of GENERIC, added only a > few options (like sound and console customization options), and > followed the steps listed on /usr/src/UPDATING: > > # cd /usr/src > # make buildworld > # make kernel KERNCONF=MYKERNELNAME > <reboot into single> > > ... > > Could anyone please enlighten me?Well, if what you're doing is an "in-place" 7.x upgrade to 8.x, I don't know how to do this or if it works. Others can help. Otherwise, the steps you're describing for building a system are not what's in src/Makefile (not src/UPDATING). These are the steps: # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # [steps 3. & 4. can be combined by using the "kernel" target] # 5. `reboot' (in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' (you may wish to use -U or -ai). # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
On Thu, May 13, 2010 at 11:00:38PM -0300, Fred Souza wrote:> I give up and reinstall (that first install had given me quite a > headache with incorrect drive geometry [that I had to fix with a lot > of research to get to TestDisk and GAG], so I thought it was best to > just start fresh). I do the same procedure this time, but paying extra > attention to any details I could have overlooked before. One of them > was to make a kernel (-STABLE) out of a renamed copy of GENERIC (no > options added or removed). I also decided on doing the remaining steps > listed on /usr/src/UPDATING before rebooting; I thought the drive > numbering difference could be related to something in userland that > was missing when booting the -STABLE kernel with -RELEASE userland. > ... > And I got the same mount root error message, and again it shows the > drives as ad10 and ad16 instead of ad8 and ad14. The difference is > that this time I did not try to update /etc/fstab before resorting to > this list (I had been browsing it for the past 3 days trying to find > any hints on this, as well as reading /usr/src/UPDATING in full > again). I can get the system to boot normally if I unload the -STABLE > kernel and load the -RELEASE one. But I can't figure out for the life > of me why does -STABLE shift my drive numbers around.There is probably an ata(4) device layer change which either fixes (yes really), breaks (possibly), or enhances (likely) support for your ATA or SATA controller. This is pretty much how the ata(4) layer has behaved for years upon years -- that's just how it goes. If this is your first time encountering it, congratulations. :-) The device names *should not* change on you once you stick with that kernel; it just indicates something changed between -RELEASE and -STABLE. I'd recommend booting/trying an actual 8.0-STABLE snapshot image from here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201004/ This will allow you to boot and install 8.0-STABLE on your system. You should see devices ad10 and ad16 there as well. It would at least save you the pain of installing the kernel, rebooting, and finding you have to manually deal with /etc/fstab changes and so on. Give this a shot first. It also might help in debugging the "stray IRQ" problem you see (it would be useful to know what's sitting on IRQ 21; it may be an unused device in your BIOS which you can disable there, or try to find a FreeBSD driver for the device which can attach to the IRQ). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |