Re: gptboot rewrite, bootonce, etc.

2012-01-31 Thread Pawel Jakub Dawidek
On Tue, Jan 31, 2012 at 06:49:51PM +0300, Andrey Fesenko wrote:
 This work if use ZFS?
 My issues Root on ZFS  GPT and boot to ufs partition
 http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013514.html
 
 I test
 # gpart show
 =   34  625142381  ada0  GPT  (298G)
  34128 1  freebsd-boot  (64k)
 162   26621952 2  freebsd-ufs  [bootonce,bootme]  (12G)
266221148388608 3  freebsd-swap  (4.0G)
35010722  590131693 4  freebsd-zfs  (281G)
 
 system ada0p2 not boot.

This functionality only works with UFS (gptboot).

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl


pgpgkHKPPasLZ.pgp
Description: PGP signature


Re: gptboot rewrite, bootonce, etc.

2012-01-31 Thread Andrey V. Elsukov
On 31.01.2012 19:49, Andrey Fesenko wrote:
 This work if use ZFS?
 My issues Root on ZFS  GPT and boot to ufs partition
 http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013514.html
 
 I test
 # gpart show
 =   34  625142381  ada0  GPT  (298G)
  34128 1  freebsd-boot  (64k)
 162   26621952 2  freebsd-ufs  [bootonce,bootme]  (12G)
266221148388608 3  freebsd-swap  (4.0G)
35010722  590131693 4  freebsd-zfs  (281G)
 
 system ada0p2 not boot.

Hi, Andrey

If you want or plan rewrite boot code, i think it is better to
write EFI loader with simple multiboot functionality.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature


Re: gptboot rewrite, bootonce, etc.

2010-09-20 Thread krad
On 19 September 2010 18:10, Boris Samorodov b...@ipt.ru wrote:

 Hi!

 On Sat, 18 Sep 2010 01:45:42 +0200 Pawel Jakub Dawidek wrote:

  My company was in need for functionality similar to nextboot(8), but on
  boot loader level, so we can have two partitions we boot from where one
  is known to be good and the other is used for upgrades. We upgrade by
  dd(1)ing entire partition image onto unused partition, we mark it as
  try-to-boot-from-it-but-only-once, reboot and if we fail to boot from
  the new partition, we fall back to the old, good partition. If we
  succeed on the other hand, we mark the new partition as our boot
  partition and mark the other one as unused.

  Well, how hard can it be?

  After around two weeks of work, I ended up rewriting gptboot in large
  parts, reorganizing a lot of code, improving and extending gpart a bit
  and implementing desire functionality.

  Here is the patch for review and test:


  http://people.freebsd.org/~pjd/patches/gptboot.patchhttp://people.freebsd.org/%7Epjd/patches/gptboot.patch

 Great! Since I need to have both i386 and amd64 at my box
 here are my test results:
 -
 [~]b...@alya% uname -a
 FreeBSD alya 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r212758M: Sat Sep 18
 16:13:38 MSD 2010
 b...@alya:/space/FreeBSD/base/head/obj/space/FreeBSD/base/head/src/sys/ALYA
 amd64

 [~]b...@alya% glabel status
  Name  Status  Components
 gptid/c6053c9b-abcc-11df-b740-00251124aff4 N/A  ad4p1
 label/9-amd64 N/A  ad4p2
label/swap N/A  ad4p3
   label/space N/A  ad4p4
  label/9-i386 N/A  ad4p5
 [~]b...@alya% mount
 /dev/label/9-amd64 on / (ufs, local)
 devfs on /dev (devfs, local, multilabel)
 /dev/label/space on /space (ufs, local)
 /dev/md0 on /tmp (ufs, local, nosuid, soft-updates)
 procfs on /proc (procfs, local)
 linprocfs on /compat/linux/proc (linprocfs, local)
 linsysfs on /compat/linux/sys (linsysfs, local)
 fdescfs on /dev/fd (fdescfs)

 [~]b...@alya% gpart show
 =   34  490234685  ad4  GPT  (234G)
 341281  freebsd-boot  (64K)
162   419430402  freebsd-ufs  (20G)
   4194320283886083  freebsd-swap  (4.0G)
   50331810  2097152004  freebsd-ufs  (100G)
  260047010   419430405  freebsd-ufs  (20G)
  301990050  188244669   - free -  (90G)

 [~]b...@alya% gpart set -a bootme -i 2 ad4
 bootme set on ad4p2
 [~]b...@alya% gpart set -a bootonce -i 5 ad4
 bootonce set on ad4p5
 [~]b...@alya% gpart show
 =   34  490234685  ad4  GPT  (234G)
 341281  freebsd-boot  (64K)
162   419430402  freebsd-ufs  [bootme]  (20G)
   4194320283886083  freebsd-swap  (4.0G)
   50331810  2097152004  freebsd-ufs  (100G)
  260047010   419430405  freebsd-ufs  [bootonce,bootme]  (20G)
  301990050  188244669   - free -  (90G)
 -

 Install i386 kernel/world to ad4p5, successful reboot, get i386
 system. Next reboot (get amd64 system back):
 -
 [~]b...@alya% gpart show
 =   34  490234685  ad4  GPT  (234G)
 341281  freebsd-boot  (64K)
162   419430402  freebsd-ufs  [bootme]  (20G)
   4194320283886083  freebsd-swap  (4.0G)
   50331810  2097152004  freebsd-ufs  (100G)
  260047010   419430405  freebsd-ufs  (20G)
  301990050  188244669   - free -  (90G)
 -

 All seems to work fine.

  Any comments or suggestions?

 Only one for now. With current default syslog configuration
 logging to local0.warning and local0.info goes nowhere.
 It will be good if those messages have traces at the
 default system.


 Thank you! That's really great.

 --
 WBR, Boris Samorodov (bsam)
 Research Engineer, http://www.ipt.ru Telephone  Internet SP
 FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



does it work for zfs boot as that would be really nice if it did?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gptboot rewrite, bootonce, etc.

2010-09-20 Thread Pawel Jakub Dawidek
On Mon, Sep 20, 2010 at 09:46:56AM +0100, krad wrote:
 does it work for zfs boot as that would be really nice if it did?

No, it doesn't. ZFS works a bit differently. ZFS operate on pools, not
really on partitions. One ZFS file system can span multiple
disks/partitions. I'm not yet sure how to implement it, so it is
intuitive, but I also haven't spend much time thinking about it. We
needed UFS and that is what I implemented. It took me much more time
than I expected anyway:)

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgpOli8wZZAdH.pgp
Description: PGP signature


Re: gptboot rewrite, bootonce, etc.

2010-09-20 Thread Pawel Jakub Dawidek
On Mon, Sep 20, 2010 at 01:17:38AM +0200, Oliver Pinter wrote:
 Hi PJD!
 
 Can you this patcheset release for 7-STABLE?

I've no plans atm to port this work to 7-STABLE. I don't even have 7.x
systems anymore. Not sure how boot code differs, maybe the patch will
apply without modifications? No idea. I'd like to MFC this to 8-STABLE,
though.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgp1EiZmlOSUJ.pgp
Description: PGP signature


Re: gptboot rewrite, bootonce, etc.

2010-09-20 Thread Pawel Jakub Dawidek
On Sun, Sep 19, 2010 at 09:10:52PM +0400, Boris Samorodov wrote:
 Hi!
 
 On Sat, 18 Sep 2010 01:45:42 +0200 Pawel Jakub Dawidek wrote:
 
  My company was in need for functionality similar to nextboot(8), but on
  boot loader level, so we can have two partitions we boot from where one
  is known to be good and the other is used for upgrades. We upgrade by
  dd(1)ing entire partition image onto unused partition, we mark it as
  try-to-boot-from-it-but-only-once, reboot and if we fail to boot from
  the new partition, we fall back to the old, good partition. If we
  succeed on the other hand, we mark the new partition as our boot
  partition and mark the other one as unused.
 
  Well, how hard can it be?
 
  After around two weeks of work, I ended up rewriting gptboot in large
  parts, reorganizing a lot of code, improving and extending gpart a bit
  and implementing desire functionality.
 
  Here is the patch for review and test:
 
  http://people.freebsd.org/~pjd/patches/gptboot.patch
 
 Great! Since I need to have both i386 and amd64 at my box
 here are my test results:
 -
 [~]b...@alya% uname -a
 FreeBSD alya 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r212758M: Sat Sep 18 16:13:38 
 MSD 2010
 b...@alya:/space/FreeBSD/base/head/obj/space/FreeBSD/base/head/src/sys/ALYA 
 amd64
 
 [~]b...@alya% glabel status
   Name  Status  Components
 gptid/c6053c9b-abcc-11df-b740-00251124aff4 N/A  ad4p1
  label/9-amd64 N/A  ad4p2
 label/swap N/A  ad4p3
label/space N/A  ad4p4
   label/9-i386 N/A  ad4p5
 [~]b...@alya% mount
 /dev/label/9-amd64 on / (ufs, local)
 devfs on /dev (devfs, local, multilabel)
 /dev/label/space on /space (ufs, local)
 /dev/md0 on /tmp (ufs, local, nosuid, soft-updates)
 procfs on /proc (procfs, local)
 linprocfs on /compat/linux/proc (linprocfs, local)
 linsysfs on /compat/linux/sys (linsysfs, local)
 fdescfs on /dev/fd (fdescfs)
 
 [~]b...@alya% gpart show
 =   34  490234685  ad4  GPT  (234G)
  341281  freebsd-boot  (64K)
 162   419430402  freebsd-ufs  (20G)
4194320283886083  freebsd-swap  (4.0G)
50331810  2097152004  freebsd-ufs  (100G)
   260047010   419430405  freebsd-ufs  (20G)
   301990050  188244669   - free -  (90G)
 
 [~]b...@alya% gpart set -a bootme -i 2 ad4
 bootme set on ad4p2
 [~]b...@alya% gpart set -a bootonce -i 5 ad4
 bootonce set on ad4p5
 [~]b...@alya% gpart show
 =   34  490234685  ad4  GPT  (234G)
  341281  freebsd-boot  (64K)
 162   419430402  freebsd-ufs  [bootme]  (20G)
4194320283886083  freebsd-swap  (4.0G)
50331810  2097152004  freebsd-ufs  (100G)
   260047010   419430405  freebsd-ufs  [bootonce,bootme]  (20G)
   301990050  188244669   - free -  (90G)
 -
 
 Install i386 kernel/world to ad4p5, successful reboot, get i386
 system. Next reboot (get amd64 system back):
 -
 [~]b...@alya% gpart show
 =   34  490234685  ad4  GPT  (234G)
  341281  freebsd-boot  (64K)
 162   419430402  freebsd-ufs  [bootme]  (20G)
4194320283886083  freebsd-swap  (4.0G)
50331810  2097152004  freebsd-ufs  (100G)
   260047010   419430405  freebsd-ufs  (20G)
   301990050  188244669   - free -  (90G)
 -
 
 All seems to work fine.

Great, thanks for testing!

  Any comments or suggestions?
 
 Only one for now. With current default syslog configuration
 logging to local0.warning and local0.info goes nowhere.
 It will be good if those messages have traces at the
 default system.

Good point. I changed those to local0.notice.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgpK71ho4UC6u.pgp
Description: PGP signature


Re: gptboot rewrite, bootonce, etc.

2010-09-20 Thread Andriy Gapon
on 20/09/2010 15:47 Pawel Jakub Dawidek said the following:
 No, it doesn't. ZFS works a bit differently. ZFS operate on pools, not
 really on partitions. One ZFS file system can span multiple
 disks/partitions. I'm not yet sure how to implement it, so it is
 intuitive, but I also haven't spend much time thinking about it. We
 needed UFS and that is what I implemented. It took me much more time
 than I expected anyway:)

Maybe reserve some area inside zfs boot2 and put relevant information there.
Similarly to how boot0cfg modifies data within boot0.
The information could include nextboot-pool and nextboot-fs.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gptboot rewrite, bootonce, etc.

2010-09-20 Thread John Hay
On Mon, Sep 20, 2010 at 03:59:20PM +0300, Andriy Gapon wrote:
 on 20/09/2010 15:47 Pawel Jakub Dawidek said the following:
  No, it doesn't. ZFS works a bit differently. ZFS operate on pools, not
  really on partitions. One ZFS file system can span multiple
  disks/partitions. I'm not yet sure how to implement it, so it is
  intuitive, but I also haven't spend much time thinking about it. We
  needed UFS and that is what I implemented. It took me much more time
  than I expected anyway:)
 
 Maybe reserve some area inside zfs boot2 and put relevant information there.
 Similarly to how boot0cfg modifies data within boot0.
 The information could include nextboot-pool and nextboot-fs.

nextboot-fs sounds nice. I use the bootfs property of zpool and it would
be nice if one can override it from the boot2 commandline.

John
-- 
John Hay -- j...@meraka.csir.co.za / j...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gptboot rewrite, bootonce, etc.

2010-09-20 Thread Andriy Gapon
on 20/09/2010 16:37 John Hay said the following:
 On Mon, Sep 20, 2010 at 03:59:20PM +0300, Andriy Gapon wrote:
 on 20/09/2010 15:47 Pawel Jakub Dawidek said the following:
 No, it doesn't. ZFS works a bit differently. ZFS operate on pools, not
 really on partitions. One ZFS file system can span multiple
 disks/partitions. I'm not yet sure how to implement it, so it is
 intuitive, but I also haven't spend much time thinking about it. We
 needed UFS and that is what I implemented. It took me much more time
 than I expected anyway:)

 Maybe reserve some area inside zfs boot2 and put relevant information there.
 Similarly to how boot0cfg modifies data within boot0.
 The information could include nextboot-pool and nextboot-fs.
 
 nextboot-fs sounds nice. I use the bootfs property of zpool and it would
 be nice if one can override it from the boot2 commandline.

I have a patch for doing that from loader(8) prompt.
I.e. you can change a filesystem from which to load kernel+modules and you can
still set root filesystem of course.
http://people.freebsd.org/~avg/zfsboot.diff

This can be extended (i think rather easily) to override from where boot2 loads 
loader

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gptboot rewrite, bootonce, etc.

2010-09-20 Thread John Baldwin
On Friday, September 17, 2010 7:45:42 pm Pawel Jakub Dawidek wrote:
 - Split code shared by almost any boot loader into separate files and
   clean up most layering violations:

I like this in general.  I worry that the space constraints for boot2 will 
prevent it from using this though as it depends on inlining almost everything 
to fit into its allotted space.  At least it can use the rbx.h header.

 - Introduce three new GPT attributes:
 
   bootme - this is bootable partition
   bootonce - try to boot from this partition only once
   bootfailed - we failed to boot from this partition

The 'bootme' attribute alone is a boon.  One of the problems with EFI was 
figuring out a sane way to choose the root partition.  EFI on ia64 currently 
uses the 'first partition wins' strategy, and this will be a definite 
improvement.  To that end this should also help with EFI on x86.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gptboot rewrite, bootonce, etc.

2010-09-20 Thread krad
On 20 September 2010 14:37, John Hay j...@meraka.org.za wrote:

 On Mon, Sep 20, 2010 at 03:59:20PM +0300, Andriy Gapon wrote:
  on 20/09/2010 15:47 Pawel Jakub Dawidek said the following:
   No, it doesn't. ZFS works a bit differently. ZFS operate on pools, not
   really on partitions. One ZFS file system can span multiple
   disks/partitions. I'm not yet sure how to implement it, so it is
   intuitive, but I also haven't spend much time thinking about it. We
   needed UFS and that is what I implemented. It took me much more time
   than I expected anyway:)
 
  Maybe reserve some area inside zfs boot2 and put relevant information
 there.
  Similarly to how boot0cfg modifies data within boot0.
  The information could include nextboot-pool and nextboot-fs.

 nextboot-fs sounds nice. I use the bootfs property of zpool and it would
 be nice if one can override it from the boot2 commandline.

 John
 --
 John Hay -- j...@meraka.csir.co.za / j...@freebsd.org


exactly what i was thinking. Its real nice how opensolaris odes its boot
environments.  I have a few custom scripts to replicate that with the
install world, but at yet have no easy way to flip flop the bootfs varible,
other than booting in on live(cd|usb)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gptboot rewrite, bootonce, etc.

2010-09-19 Thread Boris Samorodov
Hi!

On Sat, 18 Sep 2010 01:45:42 +0200 Pawel Jakub Dawidek wrote:

 My company was in need for functionality similar to nextboot(8), but on
 boot loader level, so we can have two partitions we boot from where one
 is known to be good and the other is used for upgrades. We upgrade by
 dd(1)ing entire partition image onto unused partition, we mark it as
 try-to-boot-from-it-but-only-once, reboot and if we fail to boot from
 the new partition, we fall back to the old, good partition. If we
 succeed on the other hand, we mark the new partition as our boot
 partition and mark the other one as unused.

 Well, how hard can it be?

 After around two weeks of work, I ended up rewriting gptboot in large
 parts, reorganizing a lot of code, improving and extending gpart a bit
 and implementing desire functionality.

 Here is the patch for review and test:

   http://people.freebsd.org/~pjd/patches/gptboot.patch

Great! Since I need to have both i386 and amd64 at my box
here are my test results:
-
[~]b...@alya% uname -a
FreeBSD alya 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r212758M: Sat Sep 18 16:13:38 
MSD 2010
b...@alya:/space/FreeBSD/base/head/obj/space/FreeBSD/base/head/src/sys/ALYA 
amd64

[~]b...@alya% glabel status
  Name  Status  Components
gptid/c6053c9b-abcc-11df-b740-00251124aff4 N/A  ad4p1
 label/9-amd64 N/A  ad4p2
label/swap N/A  ad4p3
   label/space N/A  ad4p4
  label/9-i386 N/A  ad4p5
[~]b...@alya% mount
/dev/label/9-amd64 on / (ufs, local)
devfs on /dev (devfs, local, multilabel)
/dev/label/space on /space (ufs, local)
/dev/md0 on /tmp (ufs, local, nosuid, soft-updates)
procfs on /proc (procfs, local)
linprocfs on /compat/linux/proc (linprocfs, local)
linsysfs on /compat/linux/sys (linsysfs, local)
fdescfs on /dev/fd (fdescfs)

[~]b...@alya% gpart show
=   34  490234685  ad4  GPT  (234G)
 341281  freebsd-boot  (64K)
162   419430402  freebsd-ufs  (20G)
   4194320283886083  freebsd-swap  (4.0G)
   50331810  2097152004  freebsd-ufs  (100G)
  260047010   419430405  freebsd-ufs  (20G)
  301990050  188244669   - free -  (90G)

[~]b...@alya% gpart set -a bootme -i 2 ad4
bootme set on ad4p2
[~]b...@alya% gpart set -a bootonce -i 5 ad4
bootonce set on ad4p5
[~]b...@alya% gpart show
=   34  490234685  ad4  GPT  (234G)
 341281  freebsd-boot  (64K)
162   419430402  freebsd-ufs  [bootme]  (20G)
   4194320283886083  freebsd-swap  (4.0G)
   50331810  2097152004  freebsd-ufs  (100G)
  260047010   419430405  freebsd-ufs  [bootonce,bootme]  (20G)
  301990050  188244669   - free -  (90G)
-

Install i386 kernel/world to ad4p5, successful reboot, get i386
system. Next reboot (get amd64 system back):
-
[~]b...@alya% gpart show
=   34  490234685  ad4  GPT  (234G)
 341281  freebsd-boot  (64K)
162   419430402  freebsd-ufs  [bootme]  (20G)
   4194320283886083  freebsd-swap  (4.0G)
   50331810  2097152004  freebsd-ufs  (100G)
  260047010   419430405  freebsd-ufs  (20G)
  301990050  188244669   - free -  (90G)
-

All seems to work fine.

 Any comments or suggestions?

Only one for now. With current default syslog configuration
logging to local0.warning and local0.info goes nowhere.
It will be good if those messages have traces at the
default system.


Thank you! That's really great.

-- 
WBR, Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone  Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gptboot rewrite, bootonce, etc.

2010-09-19 Thread Oliver Pinter
Hi PJD!

Can you this patcheset release for 7-STABLE?

On 9/19/10, Boris Samorodov b...@ipt.ru wrote:
 Hi!

 On Sat, 18 Sep 2010 01:45:42 +0200 Pawel Jakub Dawidek wrote:

 My company was in need for functionality similar to nextboot(8), but on
 boot loader level, so we can have two partitions we boot from where one
 is known to be good and the other is used for upgrades. We upgrade by
 dd(1)ing entire partition image onto unused partition, we mark it as
 try-to-boot-from-it-but-only-once, reboot and if we fail to boot from
 the new partition, we fall back to the old, good partition. If we
 succeed on the other hand, we mark the new partition as our boot
 partition and mark the other one as unused.

 Well, how hard can it be?

 After around two weeks of work, I ended up rewriting gptboot in large
 parts, reorganizing a lot of code, improving and extending gpart a bit
 and implementing desire functionality.

 Here is the patch for review and test:

  http://people.freebsd.org/~pjd/patches/gptboot.patch

 Great! Since I need to have both i386 and amd64 at my box
 here are my test results:
 -
 [~]b...@alya% uname -a
 FreeBSD alya 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r212758M: Sat Sep 18
 16:13:38 MSD 2010
 b...@alya:/space/FreeBSD/base/head/obj/space/FreeBSD/base/head/src/sys/ALYA
 amd64

 [~]b...@alya% glabel status
   Name  Status  Components
 gptid/c6053c9b-abcc-11df-b740-00251124aff4 N/A  ad4p1
  label/9-amd64 N/A  ad4p2
 label/swap N/A  ad4p3
label/space N/A  ad4p4
   label/9-i386 N/A  ad4p5
 [~]b...@alya% mount
 /dev/label/9-amd64 on / (ufs, local)
 devfs on /dev (devfs, local, multilabel)
 /dev/label/space on /space (ufs, local)
 /dev/md0 on /tmp (ufs, local, nosuid, soft-updates)
 procfs on /proc (procfs, local)
 linprocfs on /compat/linux/proc (linprocfs, local)
 linsysfs on /compat/linux/sys (linsysfs, local)
 fdescfs on /dev/fd (fdescfs)

 [~]b...@alya% gpart show
 =   34  490234685  ad4  GPT  (234G)
  341281  freebsd-boot  (64K)
 162   419430402  freebsd-ufs  (20G)
4194320283886083  freebsd-swap  (4.0G)
50331810  2097152004  freebsd-ufs  (100G)
   260047010   419430405  freebsd-ufs  (20G)
   301990050  188244669   - free -  (90G)

 [~]b...@alya% gpart set -a bootme -i 2 ad4
 bootme set on ad4p2
 [~]b...@alya% gpart set -a bootonce -i 5 ad4
 bootonce set on ad4p5
 [~]b...@alya% gpart show
 =   34  490234685  ad4  GPT  (234G)
  341281  freebsd-boot  (64K)
 162   419430402  freebsd-ufs  [bootme]  (20G)
4194320283886083  freebsd-swap  (4.0G)
50331810  2097152004  freebsd-ufs  (100G)
   260047010   419430405  freebsd-ufs  [bootonce,bootme]  (20G)
   301990050  188244669   - free -  (90G)
 -

 Install i386 kernel/world to ad4p5, successful reboot, get i386
 system. Next reboot (get amd64 system back):
 -
 [~]b...@alya% gpart show
 =   34  490234685  ad4  GPT  (234G)
  341281  freebsd-boot  (64K)
 162   419430402  freebsd-ufs  [bootme]  (20G)
4194320283886083  freebsd-swap  (4.0G)
50331810  2097152004  freebsd-ufs  (100G)
   260047010   419430405  freebsd-ufs  (20G)
   301990050  188244669   - free -  (90G)
 -

 All seems to work fine.

 Any comments or suggestions?

 Only one for now. With current default syslog configuration
 logging to local0.warning and local0.info goes nowhere.
 It will be good if those messages have traces at the
 default system.


 Thank you! That's really great.

 --
 WBR, Boris Samorodov (bsam)
 Research Engineer, http://www.ipt.ru Telephone  Internet SP
 FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gptboot rewrite, bootonce, etc.

2010-09-17 Thread Julian Elischer

 On 9/17/10 4:45 PM, Pawel Jakub Dawidek wrote:

Hi.

My company was in need for functionality similar to nextboot(8), but on
boot loader level, so we can have two partitions we boot from where one
is known to be good and the other is used for upgrades. We upgrade by
dd(1)ing entire partition image onto unused partition, we mark it as
try-to-boot-from-it-but-only-once, reboot and if we fail to boot from
the new partition, we fall back to the old, good partition. If we
succeed on the other hand, we mark the new partition as our boot
partition and mark the other one as unused.

Well, how hard can it be?

After around two weeks of work, I ended up rewriting gptboot in large
parts, reorganizing a lot of code, improving and extending gpart a bit
and implementing desire functionality.

Here is the patch for review and test:

http://people.freebsd.org/~pjd/patches/gptboot.patch

The list of changes:

- Split code shared by almost any boot loader into separate files and
   clean up most layering violations:

sys/boot/i386/common/rbx.h:

RBX_* defines
OPT_SET()
OPT_CHECK()

sys/boot/common/util.[ch]:

memcpy()
memset()
memcmp()
bcpy()
bzero()
bcmp()
strcmp()
strncmp() [new]
strcpy()
strcat()
strchr()
strlen()
printf()

sys/boot/i386/common/cons.[ch]:

ioctrl
putc()
xputc()
putchar()
getc()
xgetc()
keyhit() [now takes number of seconds as an argument]
getstr()

sys/boot/i386/common/drv.[ch]:

struct dsk
drvread()
drvwrite() [new]
drvsize() [new]

sys/boot/common/crc32.[ch] [new]

sys/boot/common/gpt.[ch] [new]

- Teach gptboot and gptzfsboot about new files. I haven't touched the
   rest, but there is still a lot of code duplication to be removed.

- Implement full GPT support. Currently we just read primary header and
   partition table and don't care about checksums, etc. With the patch we
   verify checksums of primary header and primary partition table and if
   there is a problem we fall back to backup header and backup partition
   table.

- Clean up most messages to use prefix of boot program, so in case of an
   error we know where the error comes from, eg.:

gptboot: unable to read primary GPT header

- If we can't boot, print boot prompt only once and not every five
   seconds.

- Introduce three new GPT attributes:

bootme - this is bootable partition
bootonce - try to boot from this partition only once
bootfailed - we failed to boot from this partition

- Extend gpart to allow to manipulate new attributes:

gpart set -a bootme -i 3 ada0
gpart set -a bootonce -i 4 ada0
gpart unset -a bootfailed -i 2 ada0

   Note, that setting 'bootonce' attribute automatically sets 'bootme'
   attribute.

- Change boot order of gptboot to the following:

1. Try to boot from all the partitions that have both 'bootme'
   and 'bootonce' attributes one by one.
2. Try to boot from all the partitions that have only 'bootme'
   attribute one by one.
3. If there are no partitions with 'bootme' attribute, boot from
   the first UFS partition.

- The 'bootonce' functionality is implemented in the following way:

1. Walk through all the partitions and when 'bootonce'
   attribute is found without 'bootme' attribute, remove
   'bootonce' attribute and set 'bootfailed' attribute.
   'bootonce' attribute alone means that we tried to boot from
   this partition, but boot failed after leaving gptboot and
   machine was restarted.
2. Find partition with both 'bootme' and 'bootonce' attributes.
3. Remove 'bootme' attribute.
4. Try to execute /boot/loader or /boot/kernel/kernel from that
   partition. If succeeded we stop here.
5. If execution failed, remove 'bootonce' and set 'bootfailed'.
6. Go to 2.

If whole boot succeeded there is new /etc/rc.d/gptboot script that
will log all partitions that we failed to boot from (the ones with
'bootfailed' attribute) and will remove this attribute. It will also
find partition with 'bootonce' attribute - this is the partition we
booted from successfully. The script will log success and remove the
attribute.

All the GPT updates we do here goes to both primary and backup GPT if
they are valid. We don't touch headers or partition tables when
checksum doesn't match.

Any comments or suggestions? Be aware that at this point I'm soo full of
boot loaders and I'm not looking for