Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
2016-12-16 23:56 GMT+01:00 Warner Losh : > On Fri, Dec 16, 2016 at 11:00 AM, Dimitry Andric wrote: > > On 16 Dec 2016, at 18:53, Antony Uspensky wrote: > >> > >> On Fri, 16 Dec 2016, Eric van Gyzen wrote: > >>> On 12/16/2016 11:39, Slawa Olhovchenkov wrote: > On Fri, Dec 16, 2016 at 06:08:34PM +0100, Fernando Herrero Carr?n > wrote: > > Hi everyone, > > > > A few months ago I got myself a new box and I have been happily > running > > FreeBSD on it ever since. I noticed that the boot was not as fast as > I had > > expected and I've realized that, while my disk is GPT partitioned, > the boot > > process is still BIOS based: > > > > % gpart show > > => 34 976773101 ada0 GPT (466G) > > 34 6- free - (3.0K) > > 40 1024 1 freebsd-boot (512K) > > 1064984- free - (492K) > > 2048 67108864 2 freebsd-swap (32G) > > 67110912 909662208 3 freebsd-zfs (434G) > > 976773120 15- free - (7.5K) > > ... > >> I would shrink ada0p1 down to 128K (size of gptzfsboot = 88K now) and > place efi partition (~800K) on free space between new p1 and p2. No need to > touch swap partition. > > > > Yes, this is almost exactly what I have done on a machine that was > > originally installed with gptzfsboot on the first partition, which was > > 512K. Since all the partitions on this SSD were aligned to 1M, I > > reduced the size of the first partition to 224K, freeing up a hole of > > exactly 800K for an EFI partition: > > > > => 40 976773088 ada0 GPT (466G) > > 40 2008- free - (1.0M) > >2048448 1 freebsd-boot (224K) > >2496 1600 4 efi (800K) > >4096 33554432 2 freebsd-swap (16G) > >33558528 943214592 3 freebsd-zfs (450G) > > 976773120 8- free - (4.0K) > > > > Then I wrote the preformatted boot1.efifat image to it, using: gpart > > bootcode -p /boot/boot1.efifat -i 4 ada0. You can also use dd of > > course, but I prefer using gpart for these kinds of manipulations. > > > > This way, you can choose between booting in old school BIOS mode, or > > UEFI mode. If the UEFI mode works flawlessly, you can always decide > > later to dump the freebsd-boot partition, and use only an EFI partition. > > > > -Dimitry > > > > P.S.: The only thing that triggers my OCD here is that the EFI partition > > has index 4, but is physically the second. But I can live with that, > > until I finally delete the freebsd-boot partition. :) > > > You likely want to carve out more like 50MB instead of 800k for UEFI > partition. 800k is the minimum, but it also precludes many things you > may need to do with UEFI applications down the line. > > Warner > Thanks guys for all the answers, I think I will just nuke freebsd-boot and create a smallish efi where I can place boot1.efifat as suggested by Dimitry. If this works, I can always shrink swap if I really need to later on. Just out of curiosity, what other functionality will UEFI provide that takes up 50M? Best regards, Fernando ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
2016-12-17 7:12 GMT+01:00 Ian Smith : > On Fri, 16 Dec 2016 18:08:34 +0100, Fernando Herrero Carrón wrote: > > Hi everyone, > > Hi, > > you've had plenty of helpful responses, but nobody has commented on: > > > My only reason for wanting to boot with UEFI is faster boot, > > everything is working fine otherwise. > > I'm skeptical that UEFI boot would be any or noticeably faster than via > BIOS, but am interested in hearing of any experiences regarding that. > > cheers, Ian > My understanding is that BIOSes still boot through kind of a legacy 32-bit path and UEFI boots straight 64-bit with all the bells and whistles. In fact: % file /boot/loader /boot/loader: FreeBSD/i386 demand paged executable # Slow 32bit? % file /boot/loader.efi /boot/loader.efi: PE32+ executable (EFI application) x86-64, for MS Windows # Fast 64bit? Whether this amounts to faster boot, we'll see. Cheers, Fernando ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
2016-12-17 9:21 GMT+01:00 Fernando Herrero Carrón : > > > 2016-12-16 23:56 GMT+01:00 Warner Losh : > >> On Fri, Dec 16, 2016 at 11:00 AM, Dimitry Andric wrote: >> > On 16 Dec 2016, at 18:53, Antony Uspensky wrote: >> >> >> >> On Fri, 16 Dec 2016, Eric van Gyzen wrote: >> >>> On 12/16/2016 11:39, Slawa Olhovchenkov wrote: >> On Fri, Dec 16, 2016 at 06:08:34PM +0100, Fernando Herrero Carr?n >> wrote: >> > Hi everyone, >> > >> > A few months ago I got myself a new box and I have been happily >> running >> > FreeBSD on it ever since. I noticed that the boot was not as fast >> as I had >> > expected and I've realized that, while my disk is GPT partitioned, >> the boot >> > process is still BIOS based: >> > >> > % gpart show >> > => 34 976773101 <976%2077%2031%2001> ada0 GPT (466G) >> > 34 6- free - (3.0K) >> > 40 1024 1 freebsd-boot (512K) >> > 1064984- free - (492K) >> > 2048 67108864 2 freebsd-swap (32G) >> > 67110912 909662208 3 freebsd-zfs (434G) >> > 976773120 <976%2077%2031%2020> 15- free - (7.5K) >> > ... >> >> I would shrink ada0p1 down to 128K (size of gptzfsboot = 88K now) and >> place efi partition (~800K) on free space between new p1 and p2. No need to >> touch swap partition. >> > >> > Yes, this is almost exactly what I have done on a machine that was >> > originally installed with gptzfsboot on the first partition, which was >> > 512K. Since all the partitions on this SSD were aligned to 1M, I >> > reduced the size of the first partition to 224K, freeing up a hole of >> > exactly 800K for an EFI partition: >> > >> > => 40 976773088 ada0 GPT (466G) >> > 40 2008- free - (1.0M) >> >2048448 1 freebsd-boot (224K) >> >2496 1600 4 efi (800K) >> >4096 33554432 2 freebsd-swap (16G) >> >33558528 943214592 <943%2021%2045%2092> 3 freebsd-zfs (450G) >> > 976773120 <976%2077%2031%2020> 8- free - (4.0K) >> > >> > Then I wrote the preformatted boot1.efifat image to it, using: gpart >> > bootcode -p /boot/boot1.efifat -i 4 ada0. You can also use dd of >> > course, but I prefer using gpart for these kinds of manipulations. >> > >> > This way, you can choose between booting in old school BIOS mode, or >> > UEFI mode. If the UEFI mode works flawlessly, you can always decide >> > later to dump the freebsd-boot partition, and use only an EFI partition. >> > >> > -Dimitry >> > >> > P.S.: The only thing that triggers my OCD here is that the EFI partition >> > has index 4, but is physically the second. But I can live with that, >> > until I finally delete the freebsd-boot partition. :) >> >> >> You likely want to carve out more like 50MB instead of 800k for UEFI >> partition. 800k is the minimum, but it also precludes many things you >> may need to do with UEFI applications down the line. >> >> Warner >> > > Thanks guys for all the answers, I think I will just nuke freebsd-boot > and create a smallish efi where I can place boot1.efifat as suggested by > Dimitry. If this works, I can always shrink swap if I really need to later > on. > > So, it worked! I took a spare USB stick with a bootonly image and changed partitions there first. Once I had it working I modified my hard drive's partitions, installed efifat image with gpart, rebooted, and here I am. Some conclusions: * While getting to FreeBSD's loader seems a bit faster (or maybe that's just confirmation bias), bringing up the system does not seem much faster. * If anything, I have a slightly higher resolution console now. * uefi(8) hints at gpart: /boot/boot1.efifat msdosfs(5) FAT file system image containing boot1.efi for use by bsdinstall(8) and the bootcode argument to gpart(8). maybe a little example would help (gpart bootcode -p /boot/boot1.efifat -i 1 ada0) * Despite gpart(8)'s excellent BOOTSTRAPPING section, no mention is made to booting from an efi partition there. Best, Fernando ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
> Am 17.12.2016 um 07:12 schrieb Ian Smith : > > On Fri, 16 Dec 2016 18:08:34 +0100, Fernando Herrero Carrón wrote: >> My only reason for wanting to boot with UEFI is faster boot, >> everything is working fine otherwise. > > I'm skeptical that UEFI boot would be any or noticeably faster than via > BIOS, but am interested in hearing of any experiences regarding that. In a very quick test with VirtualBox with 10.3-Release, ZFS, booting with BIOS and autoboot_delay=0, it takes 15 seconds to display „Booting…“. With 11.0-R and BIOS it takes about 12. With 11.0-R and EFI enabled, it takes less than 3 seconds. On real hardware other factors will likely diminish the difference. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
On Sat, Dec 17, 2016 at 05:12:13PM +1100, Ian Smith wrote: > On Fri, 16 Dec 2016 18:08:34 +0100, Fernando Herrero Carrón wrote: > > Hi everyone, > > Hi, > > you've had plenty of helpful responses, but nobody has commented on: > > > My only reason for wanting to boot with UEFI is faster boot, > > everything is working fine otherwise. > > I'm skeptical that UEFI boot would be any or noticeably faster than via > BIOS, but am interested in hearing of any experiences regarding that. Some BIOS start with very long try UEFI boot atempt and try legacy boot only all of that fails. I.e. this is not speedup FreeBSD boot, this is speedup _start_ of FreeBSD boot for some BIOS. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
On Sat, 17 Dec 2016 10:49:48 +0100, Stefan Bethke wrote: > > Am 17.12.2016 um 07:12 schrieb Ian Smith : > > > > On Fri, 16 Dec 2016 18:08:34 +0100, Fernando Herrero Carrón wrote: > >> My only reason for wanting to boot with UEFI is faster boot, > >> everything is working fine otherwise. > > > > I'm skeptical that UEFI boot would be any or noticeably faster than via > > BIOS, but am interested in hearing of any experiences regarding that. > > In a very quick test with VirtualBox with 10.3-Release, ZFS, booting > with BIOS and autoboot_delay=0, it takes 15 seconds to display > ÿÿBooting. > > With 11.0-R and BIOS it takes about 12. > > With 11.0-R and EFI enabled, it takes less than 3 seconds. > > On real hardware other factors will likely diminish the difference. Thanks for that, Stefan. I only have older kit here, so was curious. And Slawa Olhovchenkov wrote: > Some BIOS start with very long try UEFI boot atempt and try legacy > boot only all of that fails. > > I.e. this is not speedup FreeBSD boot, this is speedup _start_ of > FreeBSD boot for some BIOS. That makes good sense to me. cheers, Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume on Skylake (Lenovo T460s) with FreeBSD11 stable
On Wed, Dec 14, 2016 at 05:15:12PM +0100, Chris Ernst wrote: > > i have been hardly trying to get my Lenovo T460s to suspend *and to resume > again*. > > Eventually the system suspends when i close the lid. > The power LED is slowly blinking on and off. > > That is it! I am not able to resume my system anymore. > When I push the power button once the power LED *keeps* slowly blinking on > and off. :( What was the last revision where suspend/resume worked on your T460s? Approximately two months ago, I tried the then HEAD of drm-next-4.7 of the FreeBSDDesktop repo [1] and had no success. -- Christian [1] https://github.com/FreeBSDDesktop/freebsd-base-graphics ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
On 16 Dec 2016, at 23:56, Warner Losh wrote: > > On Fri, Dec 16, 2016 at 11:00 AM, Dimitry Andric wrote: ... >> Yes, this is almost exactly what I have done on a machine that was >> originally installed with gptzfsboot on the first partition, which was >> 512K. Since all the partitions on this SSD were aligned to 1M, I >> reduced the size of the first partition to 224K, freeing up a hole of >> exactly 800K for an EFI partition: ... > You likely want to carve out more like 50MB instead of 800k for UEFI > partition. 800k is the minimum, but it also precludes many things you > may need to do with UEFI applications down the line. Well, this is the default boot1.efifat size. If you think 50MB is more reasonable, the boot1.efifat size should have a corresponding size. That said, as long as there are almost no such UEFI applications, I'm not bothering. Besides, even if there were, I don't have any interest in the UEFI "ecosphere" as-is. I see it as an ugly-but-necessary pre-bootloader environment only. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
On Sat, Dec 17, 2016 at 8:25 AM, Fernando Herrero Carrón wrote: > > My understanding is that BIOSes still boot through kind of a legacy 32-bit > path and UEFI boots straight 64-bit with all the bells and whistles. In > fact: Actually, they boot through a legacy 16 bit path, with access to only the first 1MB of RAM until they can initialize native mode. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
On Sat, Dec 17, 2016 at 8:21 AM, Fernando Herrero Carrón wrote: > Just out of curiosity, what other functionality will UEFI provide that > takes up 50M? > Multiple UEFI programs for diagnostics and such, possibly including standalone repair images. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
On Sat, Dec 17, 2016 at 9:29 AM, Fernando Herrero Carrón wrote: > * While getting to FreeBSD's loader seems a bit faster (or maybe that's > just confirmation bias), bringing up the system does not seem much faster. > Aside from working around some buggy boot BIOSes, the main speedup would be not having to do a staged load in 16 bit mode with only 1MB RAM accessible. I don't think this will be that noticeable. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[ZFS] files in a weird situtation
[I had first posted onto the Forum about this issue]
Two months ago,
- next to a call to |`||delete-old-libs`| or `install world`, I don't
really know -
my box that is following FreeBSD-11 Stable ran into a weird situation.
A set of files, especially `/lib/libjail.so.1` are in both states
`existing` and `not existing`:
I means:
david:~>cp ~david/libjail.so.1 /lib
cp: /lib/libjail.so.1: File exists
But:
david:~>ls /lib/libjail.so.1
ls: /lib/libjail.so.1: No such file or directory
david:~>find /lib -name "libjail.so.1" -print
/lib/libjail.so.1
david:~>find /lib -name "libjail.so.1" -ls
find: /lib/libjail.so.1: No such file or directory
With deeper investigation, the file is in fact mapped to an `inode`:
root@dmarec:~ # ls -di /lib
13 /lib
root@dmarec:~ # zdb - zroot/ 13 | grep libjail.so.1
libjail.so.1 = 10552574 (type: Regular File)
Which fails with `zdb` on:
root@dmarec:~ # zdb - zroot/ 10552574
Dataset zroot [ZPL], ID 21, cr_txg 1, 114G, 2570002 objects,
rootbp
DVA[0]=<0:b97d6ea00:200> DVA[1]=<0:1c212b0400:200> [L0 DMU objset]
fletcher4 lz4 LE contiguous unique double size=800L/200P
birth=3852240L/3852240P fill=2570002
cksum=17b78fb7e4:7c87a526a07:16251edfaae60:2ce0c5734ccf2f
Object lvl iblk dblk dsize lsize %full type
zdb: dmu_bonus_hold(10552574) failed, errno 2
`stat (2)` returns ENOENT when checking for the file:
david:~>truss stat -L /lib/libjail.so.1
...
stat("/lib/libjail.so.1",0x7fffe7e8) ERR#2 'No such
file or
directory'david:~>truss stat -L /lib/libjail.so.1
A pass with `zfs scrub` didn't help.
Any clue is welcome. What's that `dmu_bonus_hold` stands for ?
--
David Marec
https://lapinbilly.eu
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [ZFS] files in a weird situtation
On Sat, Dec 17, 2016 at 9:01 PM, David Marec wrote: > > david:~>ls /lib/libjail.so.1 > ls: /lib/libjail.so.1: No such file or directory > david:~>find /lib -name "libjail.so.1" -print > /lib/libjail.so.1 > david:~>find /lib -name "libjail.so.1" -ls > find: /lib/libjail.so.1: No such file or directory > You have a directory entry pointing at a freed inode (or zfs equivalent). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [ZFS] files in a weird situtation
On 17.12.2016 22:15, Brandon Allbery wrote: You have a directory entry pointing at a freed inode (or zfs equivalent). ZFS may have mapped this inode that points to nowhere. That makes sense. In this case, what should be the best solution to clean this up ? As I said, as far scrubbing the pool didn't show any error, it didn't solve the issue. -- David Marec https:lapinbilly.eu ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [ZFS] files in a weird situtation
On Sat, Dec 17, 2016 at 10:25 PM, David Marec wrote: > In this case, what should be the best solution to clean this up ? > > As I said, as far scrubbing the pool didn't show any error, it didn't > solve the issue. > That I don't know. With a nore Unix-like filesystem I'd run fsck; if scrubbing the zpool didn't fix it, you may need a zfs expert :/ -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [ZFS] files in a weird situtation
On Sat, Dec 17, 2016 at 3:01 PM, David Marec
wrote:
> [I had first posted onto the Forum about this issue]
>
> Two months ago,
>
> - next to a call to |`||delete-old-libs`| or `install world`, I don't
> really know -
>
> my box that is following FreeBSD-11 Stable ran into a weird situation.
>
> A set of files, especially `/lib/libjail.so.1` are in both states
> `existing` and `not existing`:
>
> I means:
>
> david:~>cp ~david/libjail.so.1 /lib
> cp: /lib/libjail.so.1: File exists
>
> But:
>
> david:~>ls /lib/libjail.so.1
> ls: /lib/libjail.so.1: No such file or directory
> david:~>find /lib -name "libjail.so.1" -print
> /lib/libjail.so.1
> david:~>find /lib -name "libjail.so.1" -ls
> find: /lib/libjail.so.1: No such file or directory
>
> With deeper investigation, the file is in fact mapped to an `inode`:
>
> root@dmarec:~ # ls -di /lib
> 13 /lib
> root@dmarec:~ # zdb - zroot/ 13 | grep libjail.so.1
> libjail.so.1 = 10552574 (type: Regular File)
>
> Which fails with `zdb` on:
>
> root@dmarec:~ # zdb - zroot/ 10552574
> Dataset zroot [ZPL], ID 21, cr_txg 1, 114G, 2570002 objects, rootbp
> DVA[0]=<0:b97d6ea00:200> DVA[1]=<0:1c212b0400:200> [L0 DMU objset]
> fletcher4 lz4 LE contiguous unique double size=800L/200P
> birth=3852240L/3852240P fill=2570002
> cksum=17b78fb7e4:7c87a526a07:16251edfaae60:2ce0c5734ccf2f
>
> Object lvl iblk dblk dsize lsize %full type
> zdb: dmu_bonus_hold(10552574) failed, errno 2
>
>
> `stat (2)` returns ENOENT when checking for the file:
> david:~>truss stat -L /lib/libjail.so.1
> ...
> stat("/lib/libjail.so.1",0x7fffe7e8) ERR#2 'No such
> file or
> directory'david:~>truss stat -L /lib/libjail.so.1
>
> A pass with `zfs scrub` didn't help.
>
> Any clue is welcome. What's that `dmu_bonus_hold` stands for ?
>
I am unable to understand what your intent is here. If you wish to delete
it, you can do:
find . -inum 10552574 -exec rm {} \;
--
Adam
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
On Sat, Dec 17, 2016 at 6:38 AM, Dimitry Andric wrote: > On 16 Dec 2016, at 23:56, Warner Losh wrote: >> >> On Fri, Dec 16, 2016 at 11:00 AM, Dimitry Andric wrote: > ... >>> Yes, this is almost exactly what I have done on a machine that was >>> originally installed with gptzfsboot on the first partition, which was >>> 512K. Since all the partitions on this SSD were aligned to 1M, I >>> reduced the size of the first partition to 224K, freeing up a hole of >>> exactly 800K for an EFI partition: > ... >> You likely want to carve out more like 50MB instead of 800k for UEFI >> partition. 800k is the minimum, but it also precludes many things you >> may need to do with UEFI applications down the line. > > Well, this is the default boot1.efifat size. If you think 50MB is more > reasonable, the boot1.efifat size should have a corresponding size. We shouldn't have a boot1.efifat at all. We should make the fat based on what the size of the partition is. boot1.efifat is an ugly hack to make the installers happy when we should have fixed the installers. The standard suggests an even larger 200MB. On most modern drives, the delta this usage is tiny, though on SD card-based systems 200MB takes up too large a percentage. > That said, as long as there are almost no such UEFI applications, I'm > not bothering. Besides, even if there were, I don't have any interest > in the UEFI "ecosphere" as-is. I see it as an ugly-but-necessary > pre-bootloader environment only. At work we get programs to run from time to time that upgrade BIOS that's in different cards in our system, or to dump diagnostics. It's helpful to have the space space when you need it, because when you need it, you really need it. It's also used to deploy "capsules" that have the upgrades for the BIOS (there's a standard now, but we don't implement it all yet). There are secure boot things you need space for as well. If you judge from today's, barely enough to boot a single partition w/o the other features of our traditional pre-/boot/loader environment, I can see how you might think there's nothing but 'waste' here. However, as we flesh out things, I think we'd be doing our users a disservice from doing anything less than ~50MB by default. Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
On Fri, 16 Dec 2016, Eric van Gyzen wrote: On 12/16/2016 11:08, Fernando Herrero Carrón wrote: Hi everyone, A few months ago I got myself a new box and I have been happily running FreeBSD on it ever since. I noticed that the boot was not as fast as I had expected and I've realized that, while my disk is GPT partitioned, the boot process is still BIOS based: % gpart show => 34 976773101 ada0 GPT (466G) 34 6- free - (3.0K) 40 1024 1 freebsd-boot (512K) 1064984- free - (492K) 2048 67108864 2 freebsd-swap (32G) 67110912 909662208 3 freebsd-zfs (434G) 976773120 15- free - (7.5K) I am reading uefi(8) and it looks like FreeBSD 11 should be able to boot using UEFI straight into ZFS, so I am thinking of converting that freebsd-boot partition to an EFI partition, creating a FAT filesystem and copying /boot/boot.efi there. How good of an idea is that? Would it really be that simple or am I missing something? My only reason for wanting to boot with UEFI is faster boot, everything is working fine otherwise. I would recommend creating another partition for EFI instead of replacing your freebsd-boot partition, in order to have a working fallback in case EFI boot doesn't work. You would need to steal some space from your swap partition. Be aware that some newer Dells really don't like to have both and will refuse to boot in either mode with such a setup. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)
On Fri, 16 Dec 2016, Eric van Gyzen wrote: On 12/16/2016 11:39, Slawa Olhovchenkov wrote: On Fri, Dec 16, 2016 at 06:08:34PM +0100, Fernando Herrero Carrón wrote: Hi everyone, A few months ago I got myself a new box and I have been happily running FreeBSD on it ever since. I noticed that the boot was not as fast as I had expected and I've realized that, while my disk is GPT partitioned, the boot process is still BIOS based: % gpart show => 34 976773101 ada0 GPT (466G) 34 6- free - (3.0K) 40 1024 1 freebsd-boot (512K) 1064984- free - (492K) 2048 67108864 2 freebsd-swap (32G) 67110912 909662208 3 freebsd-zfs (434G) 976773120 15- free - (7.5K) I am reading uefi(8) and it looks like FreeBSD 11 should be able to boot using UEFI straight into ZFS, so I am thinking of converting that freebsd-boot partition to an EFI partition, creating a FAT filesystem and copying /boot/boot.efi there. How good of an idea is that? Would it really be that simple or am I missing something? My only reason for wanting to boot with UEFI is faster boot, everything is working fine otherwise. Thanks in advance for your help. I am also interesting by this case. I think expand freebsd-boot to about 1M (size of /boot/boot1.efifat), dding /boot/boot1.efifat and set to type to 'efi' may be enough. I am never tried this. I expect that would work. It's slightly risky, though, since it doesn't let you fall back to BIOS boot if EFI doesn't work. The fallback in that case would just be changing that partition back to freebsd-boot and rewriting the bootcode to it. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
