Some problems:
a) The BIOS "read disk sector/s" function requires a segment (in ES) and an offset (in BX). You aren't providing an offset (not setting BX to anything) so there's no sane way to guess where the BIOS might load the sector (it could be anywhere within the 64 KiB segment requested by ES).
b) Regardless of how sector is created, it can't be a segment (for the mov ax, sector, mov es, ax) and also be an "offset in the current code segment" (for jmp sector), so one of them must be wrong. For "sector = 0x1000" it looks like it was supposed to be an "offset in current code segment" (and that the code to read the sector should set ES to 0x07C0 to match the assumed current code segment and do mov bx,sector to treat sector as an offset in the requested segment).
c) I'd strongly recommend setting segments to zero wherever possible. This helps to avoid confusion and mistakes (especially for beginners) and makes it much easier to switch to/from protected mode (or long mode) later. To do this you would need to use org 0x7C00 (rather than "implied org 0 because it wasn't explicitly set") in addition to changing segment register loads (e.g. mov ax, 07C0h, mov es,ax would become mov ax, 0, mov es,ax). This would include the stack (where I'd recommend using "SS:SP = 0:0x7C00"). Don't forget that the stack segment limit often doesn't actually limit anything - e.g. a push or call when the stack is "full" just causes SP to overflow and wrap around from 0x0000 to 0xFFFE.
d) Resetting the disk system shouldn't be necessary before trying to read sector/s the first time (as you know the BIOS successfully read your boot loader and the disk system is working fine). It should only be used as an attempt to recover from disk errors. Note that (for floppy disks) resetting the disk system typically means recalibrating the drive which involves sending the heads back to "track 0".
e) When there's errors reading from disk, sometimes they're temporary (e.g. due to floppy drive motor speed variations) and sometimes they aren't (e.g. "bad parameters", "floppy disk ejected", etc). Retrying several times (and resetting the disk system occasionally between attempts) is recommended for working around temporary problems (especially for floppy disks). Slamming the disk heads back and forth forever (with "reset/recalibrate, seek/read, reset/recalibrate, seek/read, ...) is an extremely bad way to deal with persistent problems. You need a counter to track how many times you've retried so that you can stop after a limited amount of attempts and display an error message. Don't forget that BIOS returns an error code, and using that error code to determine which error message to display can help you find bugs and also help normal users figure out what to do when there's a problem (e.g. if it's faulty hardware/dodgy floppy disk or a software bug).
f) You have control flow problems. Specifically, you call reset but that code has no ret and falls through into the read_sector code; so call reset won't return unless the BIOS successfully reads the sector, and there's no point doing the call read_sector after the sector was already successfully read.
g) If the read_sector code succeeds it will fall through to the code to print a string. Your code to print a string (the printf routine) will get characters from the memory at the address contained in DS:SI, but SI is never set to anything in the 1st sector (before its executed) so it will probably only ever print a random/undefined mess (most likely case is that the byte at the unknown address happens to be zero and nothing is printed). Also; after reading a byte with lodsb SI will either be incremented or decremented depending on how the "direction flag" was set. Your code doesn't set the direction flag to anything (e.g. no cld instruction anywhere); which means that there's an extremely small chance that your code might print a random string backwards ("!dlroW olleH"). I don't know if you intended to have a ret after the code to read a sector, or if you intended to set DS:SI to the address of a "2nd sector loaded!" string (I assume the former because there's no string in the 1st sector).
h) The contents of the second sector starts with a string ("now there is a different message!"). If there were no other bugs, call sector (in 1st sector) would have caused this string to be executed and not valid code (likely causing a spectacular crash of some sort). You want to either move the string somewhere else (after the code in the second sector) or jump to the code directly (e.g. a jmp sector2_code in the 1st sector and a sector2_code: label before the mov si, message instruction).
i) The BIOS function you're using to read sectors mostly doesn't work for hard disks (modern hard disks are simply too big - there's an "extended disk read" function you'd want to use instead). For floppy disks you can't use the "extended disk read" function (and have to use the BIOS function that you are using). For other cases (booting from USB flash, booting from a CD configured to emulate something) you will need either a "BIOS Parameter Block" (see https://en.wikipedia.org/wiki/BIOS_parameter_block ) for floppy and floppy emulation, or a partition table (for hard disk or hard disk emulation). For actual real floppy disks, the "BIOS Parameter Block" is technically optional (originally part of the FAT file system and nothing to do with the BIOS at all), but it's common for other operating systems (Windows) to complain about the disk not being valid/formatted if there is none (which really confuses normal users).
j) Windows is malware that can/will corrupt 4 bytes in the first sector of a disk (in the middle of your boot sector's code), even though Windows has no right to tamper with competing operating system's disks or boot loaders. Specifically, Microsoft decided that Windows should use a unique disk signature to identify disks, so when Windows first sees a disk it will try to fetch this unique signature and if the value isn't unique it will write a new "unique" value at offset 0x01B8 in the first sector. Note that this behaviour was "retro-actively" included in the UEFI specs in the section relating to (the "protective MBR" part of) the GPT partitioning scheme (where it doesn't apply to unpartitioned disks, MBR partitioned disks or people using BIOS instead of UEFI); and in the UEFI specs it's considered optional (the literal words are "This may be used by the OS...") and there's no clear guidance of which OS (yours or Microsoft's ) gets to decide if the signature is present or not (or how the signature should be generated to allow operating systems to agree on a "unique" value and prevent it from being modified every time a different OS sees the disk). In any case; you want to avoid using the 4 bytes at offset 0x01B8 in your boot sector to defend yourself from Windows.
