Bug 134907 - boot0cfg(8): choose / adjust the booting slice doesn't work with boot0cfg -s disk
Summary: boot0cfg(8): choose / adjust the booting slice doesn't work with boot0cfg -s...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-24 14:00 UTC by Frank van den Boom
Modified: 2017-12-31 22:34 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank van den Boom 2009-05-24 14:00:03 UTC
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
Comment 1 Volker Werth freebsd_committer freebsd_triage 2009-06-16 22:50:05 UTC
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}'? 


Comment 2 Volker Werth freebsd_committer freebsd_triage 2009-06-16 22:50:05 UTC
Responsible Changed
From-To: freebsd-bugs->vwe

track
Comment 3 v 2009-06-20 02:23:54 UTC
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
Comment 4 Dmitry Pryanishnikov 2009-09-17 20:20:30 UTC
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
Comment 5 david 2010-05-09 18:09:18 UTC
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.
Comment 6 TsurutaniNaoki 2010-09-07 08:18:31 UTC
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...
Comment 7 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:46 UTC
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