Booting 9.1 from 4.11

U

un_x

I am still using FreeBSD 4.11, and decided to try 9.1 on a slave drive on the primary controller. I would like to know how to boot it :) I see some things have changed, and don't even know if it is possible. My 4.11 drive is "ad0" and my 9.1 drive is "ata1". I have tried all possible combinations from the 4.11 boot menu - eg 0:ad(0,a)/kernel type commands, but nothing works. Trying ata(1,a) made the loader hang. I can't even mount the 9.1 drive from 4.11 anymore, nor any of its partitions. I am running:
Code: 
CPU: VIA C3 Nehemiah (666.55-MHz 686-class CPU)
ad0: 57241MB <WDC WD600BB-00CAA1> [116301/16/63] at ata0-master UDMA100
ad1: 38166MB <WDC WD400AB-22CDB0> [77545/16/63] at ata0-slave UDMA100
Is there any way I can change the MBR on the 4.11 drive so it will boot the 9.1 drive?
 
FreeBSD 4.11 is seriously outdated. I'm not surprised the bootloader is unable to boot a recent version. UFS2 was introduced in 5.0 and has been the default filesystem ever since. There is NO support for UFS2 in 4.11.

Just backup your data, wipe the system and install a fresh 9.1.
 
You can boot from a recent (FreeBSD 5 or newer) install DVD/USB drive, go to the loader prompt, and do something along the lines of:
Code: 
unload
set currdev=disk0s1a
set vfs.root.mountfrom=ufs:/dev/ada0s1a
load /boot/kernel/kernel
boot

The kernel will be loaded from currdev, and vfs.root.mountfrom will be used as root filesystem (You don't *need* to specify vfs.root.mountfrom here, FreeBSD will ask for it if the default can't be mounted).

Of course, you should replace disk0s1a and ada0s1a with whatever drives you're using.

There are a few other commands such as lsdev and of course help which may be of use.
 
I would have thought that FreeBSD 5.x would not understand the GPT disk partitioning scheme used by default on 9.1. Would it? Wouldn't it have to?
 
Outdated?

I don't know about 4.11 being "outdated" as I often wonder if "progress" is practical "progress", or just progress in the Ted Kaczynski Ship of Fools sense of the term. I don't do any more with FreeBSD today than I did in 1995, but everything requires 20x more space, memory, and CPU power. But I took the advice to try to set up 9.1. I am in the middle of a suit in court for which I need my computer, and so I really don't (didn't) have time to play around, but somehow my 4.11 primary disklabels got corrupted, and now I lost that drive except for $ cat /dev/ada0 | tr -cd '\040-\176\012' | egrep ... access.

I got few things installed other than Lynx, but note that I cannot access my backed-up files on my MicroSD Card Reader which worked fine with 4.11. So much for being "indated". Off to USB Quirk and Camcontrol hell I guess ...

Not everybody is a current 20-30-40 something hacker. Sometimes we get into other things in life, and are not so interested to upgrade every year or even every 5 years, but we still can never imagine leaving FreeBSD behind for Windows/Macs.
 
Uniballer said:
I would have thought that FreeBSD 5.x would not understand the GPT disk partitioning scheme used by default on 9.1. Would it? Wouldn't it have to?
Click to expand...

Thanks, I hadn't thought of that, since I mostly just stick to MBR since the advantages of GPT are so slim. But a FreeBSD 9 LiveCD/USB would certainly do the trick :)

I got few things installed other than Lynx, but note that I cannot access my backed-up files on my MicroSD Card Reader which worked fine with 4.11.
Click to expand...

You can try kldload-ing the mmc, mmcsd, sdhci modules. It's been so long since I used FreeBSD 4 that I don't quite recall how SD card readers worked there, but this is what my laptop currently needs to get the card reader to work.
 
9.1 Overwriting Boot Blocks?

OK, I have discovered something somewhat interesting. As noted previously:

1. After installing 9.1 on a slave drive, I found I was unable to boot from my 4.11 master drive, as well as being unable to mount the 4.11 drive from the 9.1 drive.

2. After installing 9.1, I found I was unable to access a Targus SD Card Reader/Writer where my backups are located (worked fine with 4.11).

Now, *I know for sure* that I did absolutely nothing to write to the Targus Micro SD drive (32GB card). I never used fdisk or disklabel or anything on it - only mount. But I just did a fdisk /dev/da0 on it, and found that the DOS bootblock reports "sysid 165 (0xa5)" which is a BSD type. So then I get another SD card (256MB) from my camera, and fdisk it, and it reports "sysid 6 (0x06)", which is MSDOS.

I am unsure what is going on. I am not sure if a 32GB card should be reading "6/MSDOS" like the 256MB card, or if the 9.1 install is overwriting bootblocks on attached drives.

The data on the 32GB card is super-critical. I guess that the 32GB card needs a MSDOS bootblock/mbr, but I would very much appreciate any authoritative instruction. Copy the block from the 256MB card to the 32GB card using bsdlabel?

I am unsure if the larger card requires a BSD bootblock, or if the 9.1 install overwrote it for some reason. I can't afford to play guessing games of trial and error with this data.

I wish I would have disconnected all drives before installing 9.1.
 
Additional Info

I should note that I can mount and read the 256MB card fine. Works perfectly (note for others: mount MSDOS cards with /dev/da0s1, not just da0). But no-go for the 32GB card with the BSD bootblock.
I should also note that I was able to boot into 4.11 after installing 9.1 a few times (so the bootblocks didn't corrupt immediately upon installation). I originally wanted to boot 9.1 from 4.11 boot code.
So, I did play with BIOS (disabling drives/boot orders), and unplugging power/data cables to boot into the 9.1 drive, and mounting the 4.11 drive from 9.1; and during those procedures is when I lost the 4.11 bootblocks/disklabels.
But I never never never did anything but mount[CMD] with the SD Drive/Card.
 
Fdisk Output from SD Cards

Code: 
256MB SD Card (small card from a camera)
=============
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=243 heads=64 sectors/track=32 (2048 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=243 heads=64 sectors/track=32 (2048 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 6 (0x06),(Primary DOS, 16 bit FAT (>= 32MB))
    start 101, size 498075 (243 Meg), flag 80 (active)
	beg: cyl 0/ head 3/ sector 6;
	end: cyl 972/ head 15/ sector 32
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
    
32GB SD Card (in the drive when 9.1 was installed)
============
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=3880 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=3880 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 62332137 (30435 Meg), flag 80 (active)
	beg: cyl 0/ head 1/ sector 1;
	end: cyl 807/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
 
Post the output of
# bsdlabel /dev/da0s1
for the 32GB card.
 
SirDice said:
Post the output of
# bsdlabel /dev/da0s1
for the 32GB card.
Click to expand...

Code: 
bsdlabel: /dev/da0: no valid label found.

Other things I know: The 32GB card never worked in the camera, even when brand-new, never-used. So, there is something technically different about it than the 256MB card. But I never formatted it or did anything to it. Only saved files to it as a UMASS device. Also, I never had a /dev/da0s1 file in /dev while the 32GB card was in the drive. It just dynamically appeared after inserting the 256MB card into the device, and dynamically disappears when the 32GB card is inserted.
 
SirDice said:
There's a big difference between da0 and da0s1.
Click to expand...

Yes, but I never had a s1 slice with the 32GB card installed, so it was never a mounting option for me. Devfs and the dynamic creation/deletion of devices is new feature for me with 9.1. Also, I am working with just the raw 9.1 installation at this time. I am unable to look at or use my 4.11 configuration files and scripts (which usually did everything for me after I studied a certain subject).
 
My best guess is that the 9.1 install CD/iso has code that writes to boot blocks previous to any final installation. I can't think of any other way this could have happened. I will try # scan_ffs on my 4.11 hard drive (right now, I am trying a bzip2recover on /dev/ada0 to search out my backup bzip2 blocks, and I am making a copy of the 32GB SD card:

# dd bs=512 count=62332137 if=/dev/da0 of=/dev/stdout | xz -c > da0.xz

Then I plan to buy a new 32GB SD card, and try copying the 1st 512B over to the corrupted card, and see what happens ... ? Then maybe I can fsck_msdosfs(8) it or do something better. Please advise if anyone has better ideas.

For anyone's information, my understanding is that FAT16 filesystems are used on SD cards up to 2GB, and FAT32 is used for cards up to 32GB, and then FAT64/exFAT is for >32GB.

I noticed when looking at the MBR of the 256MB card, it was full of data; but the 1st 512B of the 32GB card was mostly zeroed out, excepting just a few bytes.

I am posting this in case anyone has similar problems in the future, so it can be seen what worked and didn't work, at least for me.
 
To copy a device to a file, the exact count is not necessary. dd(1) stops when it runs out of data at the end of the device. If of= is not given, it defaults to stdout, and bs defaults to 512. So:
# dd if=/dev/da0 | xz -c > da0.xz
 
Conclusion

Well, here is how things worked out for me:
  1. bzip2recover was worthless for me, it just kept spitting out "block found from 4234234 to 7656768" type messages, but never saved any blocks as I thought it should.
  2. scan_ffs worked great, I think. I had overwritten the 4.11 drive disklabel on my own, and it may not have been accurate, and this utility was able to sort out the "real" disklabels from my bad guesses, so I give this utility A+.
  3. But it didn't fix the superblock, and when using newfs to find out my superblock backups (read-only, -N), I accidently forgot the -N option testing out some of the other options, and destroyed my disk. I think newfs should be reading by default, and not writing. It's a mine just waiting for someone to step on it.
  4. So, a little panicked at this point - I cursed a lot in the shower I took thereafter.
  5. Plan B was to buy a new 32GB card with FAT32 MBR (maybe FreeBSD has this, I don't know, but didn't want to waste time finding out), and then copy the MBR off a new SDHC card onto my corrupted SDHC card.
  6. On the way back from the store, the police stopped me and gave me a shakedown under the guise of looking for someone "roaming the neighborhood" that was dressed like me (police state USA).
  7. Anyway, I followed Plan B, and all was well, and I decided not to commit suicide after all! Heheh - I will lose 1 day of work and part of my MP3 collection by not having my 4.11 drive, but life could be worse! Much worse!
Something zeroed my bootblocks, they were all zeroed out, so they were not overwritten with alternative MBRs. I just wanted to conclude this topic in case others have a similar experience.

Thanks to everyone that added informative content to the topic. And thanks to everyone involved with devloping FreeBSD. It has been one of the better things in life, like a fine cigar or other adult pleasure.
 
You must log in or register to reply here.
Back
Top