choose / adjust the booting slice doesn't work with: boot0cfg -s disk on the next boot How-To-Repeat: - divide a disk into two sclices - install FreeBSD 7.2 RELEASE on slice 1 - reboot - install FreeBSD 7.2 RELEASE on the other slice - start FreeBSD (for example slice one; chosen by the FreeBSD bootmanager) - to select from which disk and slice is booted (example boot0cfg -s2 da0) - reboot - u can see that slice two (F2) is selected - BUT FreeBSD starts from slice 1
State Changed From-To: open->feedback Frank, by any chance, have you set '-o noupdate' to boot0? Can you please show us the output of `boot0cfg -v {dev}'?
Responsible Changed From-To: freebsd-bugs->vwe track
First of all, thank you for your efforts! >Frank, >by any chance, have you set '-o noupdate' to boot0? No. >Can you please show us the output of `boot0cfg -v {dev}'? Output: boot0cfg -v /dev/da0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5 1023:254:63 63 61432497 2 0x00 1023:255:63 0xa5 1023:254:63 61432560 64388520 version=1.0 drive=0x80 mask=0xf ticks=182 bell=# (0x23) options=packet,update,nosetdrv default_selection=F1 (Slice 1) Output: fdisk ******* Working on device /dev/da0 ******* parameters extracted from in-core disklabel are: cylinders=7832 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=7832 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 61432497 (29996 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 61432560, size 64388520 (31439 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: <UNUSED> The data for partition 4 is: <UNUSED> Output slice 1: df -h Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 484M 224M 221M 50% / devfs 1.0K 1.0K 0B 100% /dev /dev/da0s1h 12G 4.0K 11G 0% /home /dev/da0s1g 484M 12K 445M 0% /tmp /dev/da0s1f 14G 1.4G 12G 10% /usr /dev/da0s1e 484M 402K 445M 0% /var Output slice 2: df -h Filesystem Size Used Avail Capacity Mounted on /dev/da0s2a 484M 224M 221M 50% / devfs 1.0K 1.0K 0B 100% /dev /dev/da0s2g 14G 4.0K 13G 0% /home /dev/da0s2f 484M 12K 445M 0% /tmp /dev/da0s2e 14G 1.4G 12G 10% /usr /dev/da0s2d 484M 296K 445M 0% /var Output: uname -a FreeBSD 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Hello! > From: Brian Somers <brian@FreeBSD.org> > Date: Tue, 23 Jun 2009 04:16:13 -0700 > I have different boot code here where I store more than just the boot > slice at offset 0x1b9. In my modified boot code, I had to disable the > ORing of $NOUPDATE, otherwise for some reason that still escapes > me, the boot partition that was stored in %al (or was it %cl) was > ending up incorrect. I'm facing with the same problem: after doing 'boot0cfg -s 4 ad0' (from the 7.2-STABLE booted from ad0s3, active slice=ad0s3), both 'boot0cfg -v' and hd confirm that the _OPT's contents set up correctly (I'm using CFLAGS+= -DVOLUME_SERIAL in /sys/boot/i386/boot0, so _OPT offset is 0x1b5 for me).BUT! when I reboot with this setting (*), boot0 correctly shows default=F4 (6.4-RELEASE is on ad0s4), however after timeout boots the 7.2-STABLE from ad0s3.This result changes only when I actually press F4 (not waiting for keypress timeout) - this time system boots from ad0s4, and _after this_ default starts to work (**): next time after keypress timeout system boots actually from ad0s4. So, what's the difference between MBR contents in points (*) and (**)? Only the active partition flag (0x80 vs 0x0) in partition table: at (*) the active partition is still ad0s3, while at (**) it's ad0s4. So it seems that this ORing of $NOUPDATE is actual cause of the problem: boot0 code always updates partition table, so selected partition becomes active, but just doesn't save the result back to HDD in case of keypress timeout. I'm not sure whether this issue depends on BIOS (my MB is Intel D975XBX2) or on the secondary bootstrap code, but it definitely should be fixed. I don't see the point of the 'orb $NOUPDATE' below use_default: movb _OPT(%bp),%al # Load default orb $NOUPDATE,_FLAGS(%bp) # Disable updates but it seems that it's actually causing the problem. Sincerely, Dmitry -- nic-hdl: LYNX-RIPE
After several years of using boot0cfg(8) to flip machines from one bootable slice to another without problems, I started seeing the symptoms cited in this PR at work; a circumvention (in that case) was to "reinforce" the default selection by augmenting it by pressing the function key corresponding to the (allegedly) "default" selection. I has assumed(!) that perhaps this was because of something wonky on the RAID controller on these machines. Then I started seeing the same thing at home, on a recently-obtained, refurbished Dell Optiplex machine, and thought I'd try to find out what's going on -- and found the PR. Following the suggestion to inspect the first sector of the boot drive, here are 3 samples. The first 2 work; the 3rd exhibits the cited symptoms ... and also exhibits what looks to me to be an anomaly in the sector in question: My laptop: g1-199(9.0-C)[1] df / Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s4a 1519502 491996 905946 35% / g1-199(9.0-C)[2] sudo boot0cfg -v /dev/ad0 # flag start chs type end chs offset size 1 0x00 0: 1: 1 0xa5 1023: 3:63 63 10474317 2 0x00 1023:255:63 0xa5 1023: 7:63 10474380 10474380 3 0x00 1023:255:63 0xa5 1023: 11:63 20948760 10474380 4 0x80 1023:255:63 0xa5 1023: 14:63 31423140 203013405 version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) options=packet,update,nosetdrv default_selection=F4 (Slice 4) g1-199(9.0-C)[3] sudo dd if=/dev/ad0 count=1 | hd | sed -ne 1p -e '/01b0/p' Password: 1+0 records in 1+0 records out 512 bytes transferred in 0.025182 secs (20332 bytes/sec) 00000000 fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 bf 00 |.1.........|....| 000001b0 66 bb 44 72 69 76 65 20 00 03 80 8f b6 00 00 01 |f.Drive ........| g1-199(9.0-C)[4] My build machine: freebeast(8.0-S)[1] df / Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/aacd0s3a 1482638 326566 1037462 24% / freebeast(8.0-S)[2] sudo dd if=/dev/aacd0 count=1 | hd | sed -ne 1p -e '/01b0/p' Password: 1+0 records in 1+0 records out 512 bytes transferred in 0.015300 secs (33464 bytes/sec) 00000000 fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 bf 00 |.1.........|....| 000001b0 66 bb 44 72 69 76 65 20 b1 02 80 8f b6 00 00 01 |f.Drive ........| freebeast(8.0-S)[3] sudo boot0cfg -v /dev/aacd0 # flag start chs type end chs offset size 1 0x00 0: 1: 1 0xa5 651:254:63 63 10474317 2 0x00 652: 0: 1 0xa5 1023:254:63 10474380 10474380 3 0x80 1023:255:63 0xa5 1023:254:63 20948760 10474380 4 0x00 1023:255:63 0xa5 1023:254:63 31423140 40194630 version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) options=packet,update,nosetdrv default_selection=F3 (Slice 3) freebeast(8.0-S)[4] The new machine: albert(8.0-S)[1] df / Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad4s2a 1519502 320620 1077322 23% / albert(8.0-S)[2] sudo dd if=/dev/ad4 count=1 | hd | sed -ne 1p -e '/01b0/p' Password: 1+0 records in 1+0 records out 512 bytes transferred in 0.011337 secs (45162 bytes/sec) 00000000 fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 bf 00 |ü1À.À.Ø.м.|.æ¿.| 000001b0 69 76 65 20 00 00 80 8f b1 00 80 83 b6 00 00 01 |ive ....±...¶...| albert(8.0-S)[3] sudo boot0cfg -v /dev/ad4 # flag start chs type end chs offset size 1 0x00 0: 1: 1 0xa5 1023: 15:63 63 10485153 2 0x80 1023:255:63 0xa5 1023: 15:63 10485216 10485216 3 0x00 1023:255:63 0xa5 1023: 15:63 20970432 467426736 version=2.0 drive=0x80 mask=0xf ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID b100-8083 default_selection=F1 (Slice 1) albert(8.0-S)[4] If it would be useful, I can get similar information from the oddball machines aty work Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Hi, I think this problem should be fixed ASAP. Mr. Brian's patch should be applied, to remove inconsistency between boot0's boot slice and active partition; even if "noupdate" option is set, information about active partition shold be updated. Otherwise, we should update it through boot0cfg(8). BTW, I do not know why setting "update" option can avoid this...
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped