tsoome (Toomas Soome)
User

Projects

User Details

User Since
Dec 11 2015, 11:12 PM (76 w, 3 d)

Recent Activity

Sun, May 28

tsoome closed D10981: use the same option list for dhcp discovery and request by committing rS319085: use the same option list for dhcp discovery and request.
Sun, May 28, 9:30 PM
tsoome committed rS319085: use the same option list for dhcp discovery and request.
use the same option list for dhcp discovery and request
Sun, May 28, 9:30 PM
tsoome created D10981: use the same option list for dhcp discovery and request.
Sun, May 28, 9:24 PM
tsoome committed rS319084: Small cleanup in dev_net.c.
Small cleanup in dev_net.c
Sun, May 28, 9:21 PM
tsoome closed D10980: Small cleanup in dev_net.c by committing rS319084: Small cleanup in dev_net.c.
Sun, May 28, 9:21 PM
tsoome created D10980: Small cleanup in dev_net.c.
Sun, May 28, 9:11 PM

Sat, May 27

tsoome accepted D10953: Partially revert 314948.

LGTM.

Sat, May 27, 12:43 PM
tsoome accepted D10952: Always issue the pxe request.
Sat, May 27, 12:31 PM
tsoome added inline comments to D10952: Always issue the pxe request.
Sat, May 27, 12:26 PM
tsoome accepted D10947: Support URI scheme for root-path in netbooting.

LGTM.

Sat, May 27, 12:01 PM
tsoome added inline comments to D10947: Support URI scheme for root-path in netbooting.
Sat, May 27, 11:12 AM
tsoome accepted D10951: Pass a "FREEBSD" user-class in PXE dhcp request.

LGTM.

Sat, May 27, 10:46 AM

Thu, May 25

tsoome accepted D10895: Make the ZFS min_auto_ashift=12 setting persistent.

ok, that explanation does make sense, LGTM.

Thu, May 25, 5:33 PM
tsoome added a comment to D10895: Make the ZFS min_auto_ashift=12 setting persistent.

IMO if it is really supposed to be default, then the correct place is in /boot/defaults/loader.conf - overloading /boot/loader.conf will only confuse people.

Thu, May 25, 1:37 PM

Mon, May 22

tsoome added inline comments to D10854: Add support for protocol prefixes in rootpath.
Mon, May 22, 4:27 PM
tsoome added inline comments to D10854: Add support for protocol prefixes in rootpath.
Mon, May 22, 3:53 PM

Fri, May 19

tsoome accepted D10736: bsdinstall: do not use distextract in scripted mode.

LGTM:)

Fri, May 19, 8:18 AM
tsoome accepted D10738: bsdinstall: mount is not needed for the ZFS install case.
Fri, May 19, 8:14 AM

Thu, May 18

tsoome accepted D10738: bsdinstall: mount is not needed for the ZFS install case.

I do not know much about bsdinstall scripts but as much as it counts, seems ok for me;)

Thu, May 18, 4:08 PM

Wed, May 17

tsoome added a comment to D10603: distinguish NFS versus TFTP boot by rootpath.
In D10603#223350, @bapt wrote:

What I mean is we cannot use the one I listed above because they are interpreted by ipxe. For example if one netboots from qemu it will use ipxe under the hood first, then if you pass rootpath tftp:/ ipxe will say

Next server: 192.168.42.1
Filename: /pxeboot
Root path: tftp:/
Could not open SAN device: Invalid argument (http://ipxe.org/1c126002)
No more network devices

and the boot process fails.

Which is why what I propose is tftpfs:/ because it is not used by ipxe
and by default we remain on over nfs so we don't break existing usage

Wed, May 17, 10:04 PM
tsoome added a comment to D10603: distinguish NFS versus TFTP boot by rootpath.
In D10603#223317, @bapt wrote:

so ipxe will catch and use: iscsi:/ tftp:/ nfs:/ http:/ https:/ etc, maybe we should use tftpfs:/

In this case pxe will give a message saying (ignore unsupported root path) and continue what do you think?

Wed, May 17, 9:50 PM
tsoome added a comment to D10603: distinguish NFS versus TFTP boot by rootpath.
In D10603#223301, @bapt wrote:

We need to find a better mechanism, as this break usage where rootpath /something was before this patch expecting NFS to be located on the same serveur as the tftp server. This is now broken (it is used quite a lot apparently)

Wed, May 17, 8:43 PM
tsoome accepted D10726: Replacing iterating over rootpath by strsep.

LGTM.

Wed, May 17, 6:19 PM

Tue, May 16

tsoome committed rS318356: libstand: increase nfs max read size to 16k.
libstand: increase nfs max read size to 16k
Tue, May 16, 5:35 PM
tsoome closed D10754: libstand: increase nfs max read size to 16k by committing rS318356: libstand: increase nfs max read size to 16k.
Tue, May 16, 5:35 PM
tsoome updated the diff for D5992: Add chain loader support for loader.

menu entry has extra l.

Tue, May 16, 8:50 AM
tsoome updated the summary of D5992: Add chain loader support for loader.
Tue, May 16, 8:27 AM
tsoome updated the diff for D5992: Add chain loader support for loader.

bios chain is missing size, add efi chain.

Tue, May 16, 8:19 AM
tsoome updated the diff for D5992: Add chain loader support for loader.

allow to read boot code from file

Tue, May 16, 8:10 AM
tsoome added a comment to D10754: libstand: increase nfs max read size to 16k.
In D10754#222704, @bcr wrote:

You need to bump the .Dd as you made a content change in the man page.

Tue, May 16, 7:54 AM
tsoome updated the diff for D10754: libstand: increase nfs max read size to 16k.

.Dd update for manual.

Tue, May 16, 7:53 AM
tsoome updated the diff for D5992: Add chain loader support for loader.

Updated to revision 318337.

Tue, May 16, 7:52 AM
tsoome updated the diff for D10754: libstand: increase nfs max read size to 16k.

update pxeboot manual.

Tue, May 16, 7:15 AM
tsoome created D10754: libstand: increase nfs max read size to 16k.
Tue, May 16, 7:11 AM

Mon, May 15

tsoome committed rS318320: loader: add ip layer code into libstand.
loader: add ip layer code into libstand
Mon, May 15, 9:50 PM
tsoome closed D10631: loader: add ip layer code into libstand by committing rS318320: loader: add ip layer code into libstand.
Mon, May 15, 9:50 PM
tsoome updated the diff for D10631: loader: add ip layer code into libstand.

add missing __FBSDID("$FreeBSD$");

Mon, May 15, 8:26 PM
tsoome updated the diff for D10631: loader: add ip layer code into libstand.

add comment to ip.c about the origins.

Mon, May 15, 7:37 PM
tsoome committed rS318297: e1000api: misleading-indentation.
e1000api: misleading-indentation
Mon, May 15, 4:53 PM
tsoome closed D10741: e1000api: misleading-indentation by committing rS318297: e1000api: misleading-indentation.
Mon, May 15, 4:53 PM
tsoome created D10741: e1000api: misleading-indentation.
Mon, May 15, 1:51 PM

Wed, May 10

tsoome committed rS318142: libstand: NULL pointer dereference in rarp.
libstand: NULL pointer dereference in rarp
Wed, May 10, 3:36 PM
tsoome closed D10663: libstand: NULL pointer dereference in rarp by committing rS318142: libstand: NULL pointer dereference in rarp.
Wed, May 10, 3:36 PM
tsoome updated the summary of D10663: libstand: NULL pointer dereference in rarp.
Wed, May 10, 3:33 PM
tsoome added a comment to D10663: libstand: NULL pointer dereference in rarp.
In D10663#221137, @cem wrote:

I'd suggest changing this interface from void ** to more typed pointers to catch this, although I'd expect GCC/Clang to catch passing a void * to void ** parameter. Maybe check WARNS level?

Wed, May 10, 3:33 PM
tsoome added inline comments to D10232: loader: network read rework.
Wed, May 10, 3:22 PM
tsoome created D10663: libstand: NULL pointer dereference in rarp.
Wed, May 10, 3:21 PM

Sat, May 6

tsoome created D10631: loader: add ip layer code into libstand.
Sat, May 6, 9:01 PM
tsoome committed rS317887: loader: network read rework.
loader: network read rework
Sat, May 6, 8:32 PM
tsoome closed D10232: loader: network read rework by committing rS317887: loader: network read rework.
Sat, May 6, 8:32 PM
tsoome updated the diff for D10232: loader: network read rework.

simple fix for NULL...

Sat, May 6, 8:15 PM
tsoome updated the diff for D10232: loader: network read rework.

rebase on top of 317886

Sat, May 6, 8:00 PM
tsoome accepted D10603: distinguish NFS versus TFTP boot by rootpath.
Sat, May 6, 1:54 PM

Thu, May 4

tsoome committed rS317785: zfsboot: drvsize() may be unusable on some systems.
zfsboot: drvsize() may be unusable on some systems
Thu, May 4, 5:27 AM
tsoome closed D10591: zfsboot: drvsize() may be unusable on some systems by committing rS317785: zfsboot: drvsize() may be unusable on some systems.
Thu, May 4, 5:26 AM
tsoome added a comment to D10591: zfsboot: drvsize() may be unusable on some systems.

This fix did remove the first 2 errors, but remaining 2 are still there, however, they appear to be related something else - looks like we are getting wrap over 0 there as the reported lba 4294967288 is 0x00000000fffffff8. I think the remaining ones have to be dealt with separate issues/commits anyhow.

Thu, May 4, 5:15 AM

Wed, May 3

tsoome added a comment to D10485: Replace dhcp option 150 by 66.

well, the root path idea is not bad (IMO;) just I have a bit the same concern that at the end of the day it still may not be enough for whatever reason and then we are still back on the beginning:D

Wed, May 3, 8:50 PM
tsoome created D10591: zfsboot: drvsize() may be unusable on some systems.
Wed, May 3, 8:08 PM
tsoome added a comment to D10485: Replace dhcp option 150 by 66.

@tsoome
I based on the Intel's PXE Specification and there 66 exists.

Nevermind, let's focus on the root-path. If we cannot use prefix tftp, maybe it can be a suffix? iPXE ignores bad root-path like: "192.168.22.19:/:tftp"

Wed, May 3, 10:41 AM
tsoome added a comment to D10485: Replace dhcp option 150 by 66.

btw, I did test with my vmware fusion VM, the pxe boot is sending out:
DHCP: Message type = DHCPDISCOVER
DHCP: Requested Options:
DHCP: 1 (Subnet Mask)
DHCP: 2 (UTC Time Offset)
DHCP: 3 (Router)
DHCP: 5 (IEN 116 Name Servers)
DHCP: 6 (DNS Servers)
DHCP: 11 (RFC 887 Resource Location Servers)
DHCP: 12 (Client Hostname)
DHCP: 13 (Boot File size in 512 byte Blocks)
DHCP: 15 (DNS Domain Name)
DHCP: 16 (SWAP Server)
DHCP: 17 (Client Root Path)
DHCP: 18 (BOOTP options extensions path)
DHCP: 43 (Vendor Specific Options)
DHCP: 54 (DHCP Server Identifier)
DHCP: 60 (Client Class Identifier =)
DHCP: 67 (Simple Mail (SMTP) Servers)
DHCP: 128 (Site Option)
DHCP: 129 (Site Option)
DHCP: 130 (Site Option)
DHCP: 131 (Site Option)
DHCP: 132 (Site Option)
DHCP: 133 (Site Option)
DHCP: 134 (Site Option)
DHCP: 135 (Site Option)
DHCP: Maximum DHCP Message Size = 1260 bytes
DHCP: Unrecognized Option = 97, length = 17 octets
DHCP: Value = 0x00 0x56 0x4D 0xED 0x79 0xDF 0xA9 0x40 0xE1 0x61 0xAC 0x8F 0x85 0x11 0x7B 0xF5 0x59 (unprintable)
DHCP: Unrecognized Option = 93, length = 2 octets
DHCP: Value = 0x00 0x00 (unprintable)
DHCP: Unrecognized Option = 94, length = 3 octets
DHCP: Value = 0x01 0x02 0x01 (unprintable)
DHCP: Client Class Identifier = "PXEClient:Arch:00000:UNDI:002001"

Wed, May 3, 6:53 AM

Tue, May 2

tsoome added a comment to D10485: Replace dhcp option 150 by 66.

@rgrimes
Please try to boot CURRENT over tftp protocol and without any third part software like iPXE.

@tsoome

Note that dhcp servers in real life can offer all the configured data. And well, we can process both 66 and 150 just because that data may be there anyhow.

It's not the server side problem, but the client's side. How we can process option 150 if it not exists? I'm sorry, but I'm not able to do this.

tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 65535 bytes
23:39:38.527420 IP (tos 0x0, ttl 20, id 0, offset 0, flags [none], proto UDP (17), length 576)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 84:8f:69:f1:00:2d, length 548, xid 0x69f1002d, Flags [Broadcast] (0x8000)
	  Client-Ethernet-Address 84:8f:69:f1:00:2d
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    Parameter-Request Option 55, length 36: 
	      Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
	      IEN-Name-Server, Domain-Name-Server, RL, Hostname
	      BS, Domain-Name, SS, RP
	      EP, RSZ, TTL, BR
	      YD, YS, NTP, Vendor-Option
	      Requested-IP, Lease-Time, Server-ID, RN
	      RB, Vendor-Class, TFTP, BF
	      Option 128, Option 129, Option 130, Option 131
	      Option 132, Option 133, Option 134, Option 135
	    MSZ Option 57, length 2: 1260
	    GUID Option 97, length 17: 0.68.69.76.76.67.0.16.50.128.89.185.192.79.87.80.49
	    Client-ID Option 61, length 17: "DELLC^@^P2M-^@YM-9M-@OWP1"
	    ARCH Option 93, length 2: 0
	    NDI Option 94, length 3: 1.2.1
	    Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
	    END Option 255, length 0
	    PAD Option 0, length 0, occurs 181
23:39:39.007131 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 342)
    192.168.22.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 314, xid 0x69f1002d, Flags [Broadcast] (0x8000)
	  Your-IP 192.168.22.56
	  Server-IP 192.168.22.19
	  Client-Ethernet-Address 84:8f:69:f1:00:2d
	  file "pxeboot"
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    Server-ID Option 54, length 4: 192.168.22.1
	    Lease-Time Option 51, length 4: 3600
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 192.168.22.1
	    Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4
	    Hostname Option 12, length 5: "e6220"
	    RP Option 17, length 15: "192.168.22.19:/"
	    BR Option 28, length 4: 192.168.22.255
	    TFTP Option 66, length 4: "test"
	    END Option 255, length 0

If we want to process data from dhcp_try_rfc1048() we have to drop option 150, because it's not exists there.
I like your idea for detecting protocol type.

Tue, May 2, 10:43 PM
tsoome added a comment to D10485: Replace dhcp option 150 by 66.

Until I go forward with your comments about the code I want to highlight it's not possible to support option 150, because we have to ask DHCP server for this option. PXE client (I mean network card firmware) never asks about option 150. I can't see any chance to use this non standard option but revert r314948 and always do DHCP request for everything. The second option is doing DHCP request in #ifdef LOADER_TFTP_SUPPORT directive, what is something bad too, because we want to have one universal loader for both (NFS and TFTP) protocols. The third option is to force DHCP request in ifdef directive when somebody really wants to do this. And the last one option - to leave support for option 150, because it has never appear in the documentation. I can't see any really good solution, now your move to comment.

Tue, May 2, 5:27 AM

Mon, May 1

tsoome committed rS317652: loader.efi: ResetSystem does not use data with EFI_SUCCESS.
loader.efi: ResetSystem does not use data with EFI_SUCCESS
Mon, May 1, 4:56 PM
tsoome closed D10562: loader.efi: ResetSystem does not use data with EFI_SUCCESS by committing rS317652: loader.efi: ResetSystem does not use data with EFI_SUCCESS.
Mon, May 1, 4:56 PM
tsoome created D10562: loader.efi: ResetSystem does not use data with EFI_SUCCESS.
Mon, May 1, 4:42 PM
tsoome added inline comments to D10559: Bug 219000 - Integer underflow in efipart_realstrategy when I/O starts after end of disk.
Mon, May 1, 3:24 PM
tsoome added inline comments to D10559: Bug 219000 - Integer underflow in efipart_realstrategy when I/O starts after end of disk.
Mon, May 1, 3:06 PM
tsoome added inline comments to D10559: Bug 219000 - Integer underflow in efipart_realstrategy when I/O starts after end of disk.
Mon, May 1, 2:52 PM

Apr 26 2017

tsoome added a comment to D10485: Replace dhcp option 150 by 66.

I think we should really keep both 66 and 150. But also definitely we should point out in docs that in case of option 66, the ip address should be used, as in current code, we do not have name resolver. This does add some more complications to the validation and feedback.

Apr 26 2017, 4:25 PM

Apr 19 2017

tsoome updated the diff for D10232: loader: network read rework.

netinet/if_ether.h does already include net/ethernet.h

Apr 19 2017, 5:29 PM
tsoome updated the diff for D10232: loader: network read rework.

use ETHER_ALIGN and proper packet size calculation for efi and ofw.

Apr 19 2017, 5:12 PM
tsoome updated the diff for D10232: loader: network read rework.

Somehow I did lost one semicolon...

Apr 19 2017, 9:22 AM
tsoome added a comment to D10232: loader: network read rework.
In D10232#216150, @ian wrote:

I have tested this on armv6 (beaglebone and wandboard) and it works. It's hard to say if there is any change in performance since on the wandboard it already took about 1.5 seconds to load the kernel, and it seems to be about the same, but it's hard to time something that short "by eye".

Apr 19 2017, 9:19 AM
tsoome updated the diff for D10232: loader: network read rework.

changes suggested by ian.

Apr 19 2017, 9:07 AM
tsoome added a comment to D10232: loader: network read rework.

Can you tell me a bit more about the testing you have done on this, and what remains to be done?

Maybe we can get Andrew Turner to try net booting an ARM64 machine with this.

Apr 19 2017, 9:05 AM

Apr 18 2017

tsoome updated the diff for D10232: loader: network read rework.

Update to revision 317100

Apr 18 2017, 7:54 PM
tsoome committed rS317099: loader: uboot disk ioctl should call disk_ioctl.
loader: uboot disk ioctl should call disk_ioctl
Apr 18 2017, 7:37 PM
tsoome closed D10421: loader: uboot disk ioctl should call disk_ioctl by committing rS317099: loader: uboot disk ioctl should call disk_ioctl.
Apr 18 2017, 7:37 PM
tsoome committed rS317097: loader: F_READ/F_WRITE should be checked against masked flag.
loader: F_READ/F_WRITE should be checked against masked flag
Apr 18 2017, 6:08 PM
tsoome closed D10422: loader: F_READ/F_WRITE should be checked against masked flag by committing rS317097: loader: F_READ/F_WRITE should be checked against masked flag.
Apr 18 2017, 6:08 PM
tsoome created D10422: loader: F_READ/F_WRITE should be checked against masked flag.
Apr 18 2017, 5:26 PM
tsoome created D10421: loader: uboot disk ioctl should call disk_ioctl.
Apr 18 2017, 4:03 PM
tsoome committed rS317092: loader: zfs reader vdev_probe should check for minimum device size.
loader: zfs reader vdev_probe should check for minimum device size
Apr 18 2017, 3:44 PM
tsoome closed D10381: loader: zfs reader vdev_probe should check for minimum device size by committing rS317092: loader: zfs reader vdev_probe should check for minimum device size.
Apr 18 2017, 3:44 PM

Apr 13 2017

tsoome retitled D10381: loader: zfs reader vdev_probe should check for minimum device size from loader: zfs reader vdev_probe should check for minimum pool size to loader: zfs reader vdev_probe should check for minimum device size.
Apr 13 2017, 10:10 PM
tsoome retitled D10381: loader: zfs reader vdev_probe should check for minimum device size from loader: zfs reader vdev_probe should check for minimum pool size The smallest pool we can have is 64MB, since we are trying to walk all four labels to find the most up to date uberblock, this limit will also give us good method to check if we... to loader: zfs reader vdev_probe should check for minimum pool size.
Apr 13 2017, 6:11 AM
tsoome created D10381: loader: zfs reader vdev_probe should check for minimum device size.
Apr 13 2017, 6:07 AM

Apr 11 2017

tsoome committed rS316704: loader.efi: only fetch zfs pool guid for the actual boot device.
loader.efi: only fetch zfs pool guid for the actual boot device
Apr 11 2017, 3:20 PM
tsoome closed D10359: loader.efi: only fetch zfs pool guid for the actual boot device by committing rS316704: loader.efi: only fetch zfs pool guid for the actual boot device.
Apr 11 2017, 3:20 PM
tsoome added inline comments to D10359: loader.efi: only fetch zfs pool guid for the actual boot device.
Apr 11 2017, 1:58 PM
tsoome updated the diff for D10359: loader.efi: only fetch zfs pool guid for the actual boot device.

We do not really need double loop and pointer game.

Apr 11 2017, 1:57 PM
tsoome created D10359: loader.efi: only fetch zfs pool guid for the actual boot device.
Apr 11 2017, 12:19 PM

Apr 10 2017

tsoome updated the test plan for D10232: loader: network read rework.
Apr 10 2017, 7:18 PM
tsoome committed rS316682: loader: r316585 did miss sparc/ofw.
loader: r316585 did miss sparc/ofw
Apr 10 2017, 5:58 PM
tsoome closed D10302: loader: r316585 did miss sparc/ofw and userboot update by committing rS316682: loader: r316585 did miss sparc/ofw.
Apr 10 2017, 5:58 PM

Apr 9 2017

tsoome committed rS316654: loader: r316585 did miss userboot update.
loader: r316585 did miss userboot update
Apr 9 2017, 11:16 AM

Apr 8 2017

tsoome updated the diff for D10302: loader: r316585 did miss sparc/ofw and userboot update.

i is not the loop variable.

Apr 8 2017, 9:13 PM
tsoome added a comment to D10236: Implement the ability for GELIBoot to write encrypted data zfsbootcfg(8) depends on being able to write a valid block of zeros with the correct ZFS checksum to the PAD2 area of the first ZFS vdev label When the disk is encrypted with GELI....

I did not replicate the same comments for all the instances;)

Apr 8 2017, 6:20 PM
tsoome updated the diff for D10302: loader: r316585 did miss sparc/ofw and userboot update.

need to include sys/disk.h

Apr 8 2017, 7:35 AM

Apr 7 2017

tsoome retitled D10302: loader: r316585 did miss sparc/ofw and userboot update from loader: sparc/ofw disk size detection to loader: r316585 did miss sparc/ofw and userboot update.
Apr 7 2017, 4:23 PM