Re: 14-current: unable to boot after upgrade (installworld)

2021-12-09 Thread Sergey Dyatko
tiger@dl:~ % gpart show

   |
=>40  3907029088  da4  GPT  (1.8T)
  4010241  freebsd-boot  (512K)
1064 984   - free -  (492K)
2048  39070269442  freebsd-zfs  (1.8T)
  3907028992 136   - free -  (68K)

=>40  3907029088  da5  GPT  (1.8T)
  4010241  freebsd-boot  (512K)
1064 984   - free -  (492K)
2048  39070269442  freebsd-zfs  (1.8T)
  3907028992 136   - free -  (68K)

=>40  3907029088  da6  GPT  (1.8T)
  4010241  freebsd-boot  (512K)
1064 984   - free -  (492K)
2048  39070269442  freebsd-zfs  (1.8T)
  3907028992 136   - free -  (68K)

=>40  3907029088  da7  GPT  (1.8T)
  4010241  freebsd-boot  (512K)
1064 984   - free -  (492K)
2048  39070269442  freebsd-zfs  (1.8T)
  3907028992 136   - free -  (68K)

i'm not sure about video, everything happens faster than I can see :-) but
sometimes the system does not freeze and I can enter commands. Can this
help in some way?

чт, 9 дек. 2021 г. в 18:19, Toomas Soome :

>
>
> > On 9. Dec 2021, at 20:06, Sergey Dyatko  wrote:
> >
> > I was sure the installer did it when I reinstalled the system from
> scratch. I
> > can load 14-current successfully after boot via PXE and installworld with
> > 13-current
> > now I did the following:
> > 1) boot from HDDs FreeBSD 14.0-CURRENT #0 main-n251494-f953785b3df (with
> > 'old' world)
> > 2)run installworld (f953785b3df)
> > 3) run `gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da${D}`
> > command , where D=4..7
> > root@dl:/usr/src # zpool status
> >  pool: zroot
> > state: ONLINE
> > config:
> >
> >NAMESTATE READ WRITE CKSUM
> >zroot   ONLINE   0 0 0
> >  mirror-0  ONLINE   0 0 0
> >da4p2   ONLINE   0 0 0
> >da5p2   ONLINE   0 0 0
> >  mirror-1  ONLINE   0 0 0
> >da6p2   ONLINE   0 0 0
> >da7p2   ONLINE   0 0 0
> > errors: No known data errors
> >
> > after `shutdown -r now` system still doesn't boot  with the same error.
> As
> > far I can see, there is /boot/lua/config.lua present, but when I try to
> run
> > command more /boot/lua/config.lua system hangs with following error:
> > https://imgur.com/5p0xu6W.png
> >
>
> You seem to get 2x BTX panic, could you try to create video from console,
> so we could get register dumps?
>
> can this system do UEFI boot and if so, can you test it? Could you post
> partition tables?
>
> rgds,
> toomas
>
>
> >
> > чт, 9 дек. 2021 г. в 15:56, Warner Losh :
> >
> >> On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI 
> >> wrote:
> >>
> >>> On Thu, 9 Dec 2021 13:36:10 +
> >>> "Sergey V. Dyatko"  wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh
> >>>> 14-current from git,it looked like this:
> >>>> 1) git pull https://git.freebsd.org/src.git /usr/src
> >>>> 2) cd /usr/src ; make buildworld; make kernel
> >>>> 3) shutdown -r now
> >>>> after that I _successfully_ booted into 14-current and continued with
> >>>> etcupdate -p
> >>>> make installworld
> >>>> etcupdate -B
> >>>> shutdown -r now
> >>>>
> >>>> but after that server doesn't come back. After I conneted to this
> >> server
> >>> via
> >>>> IPMI ip-kvm I saw following (sorry for external link):
> >>>> https://i.imgur.com/jH6MHd2.png
> >>>>
> >>>> Well. There was a migration to zol between r368473 and current 'main'
> >>> branch so
> >>>> I decided to install fresh 14-current from snapshot
> >>>> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to
> >> avoid
> >>>> possible problems
> >>>>
> >>>> and again, after make kernel and reboot OS runs, but after
> installworld
> >>> I ended up in the same situation
> >>>>
> >>>> thoughts ?
> >>>>
> >>>> --
> >>>> wbr, Sergey
> >>>>
> >>>>
> >>>
> >>> Bootcode should be updated.
> >>> The procedure you wrote doesn't seem to update it.
> >>>
> >>
> >> The posted error is one you get when you can't read the filesystem,
> which
> >> is why you need to update
> >> boot blocks across the OpenZFS change.
> >>
> >> Warner
> >>
>
>


Re: 14-current: unable to boot after upgrade (installworld)

2021-12-09 Thread Sergey Dyatko
I was sure the installer did it when I reinstalled the system from scratch. I
can load 14-current successfully after boot via PXE and installworld with
13-current
now I did the following:
1) boot from HDDs FreeBSD 14.0-CURRENT #0 main-n251494-f953785b3df (with
'old' world)
2)run installworld (f953785b3df)
3) run `gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da${D}`
command , where D=4..7
root@dl:/usr/src # zpool status
  pool: zroot
 state: ONLINE
config:

NAMESTATE READ WRITE CKSUM
zroot   ONLINE   0 0 0
  mirror-0  ONLINE   0 0 0
da4p2   ONLINE   0 0 0
da5p2   ONLINE   0 0 0
  mirror-1  ONLINE   0 0 0
da6p2   ONLINE   0 0 0
da7p2   ONLINE   0 0 0
errors: No known data errors

after `shutdown -r now` system still doesn't boot  with the same error. As
far I can see, there is /boot/lua/config.lua present, but when I try to run
command more /boot/lua/config.lua system hangs with following error:
https://imgur.com/5p0xu6W.png


чт, 9 дек. 2021 г. в 15:56, Warner Losh :

> On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI 
> wrote:
>
> > On Thu, 9 Dec 2021 13:36:10 +
> > "Sergey V. Dyatko"  wrote:
> >
> > > Hi,
> > >
> > > Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh
> > > 14-current from git,it looked like this:
> > > 1) git pull https://git.freebsd.org/src.git /usr/src
> > > 2) cd /usr/src ; make buildworld; make kernel
> > > 3) shutdown -r now
> > > after that I _successfully_ booted into 14-current and continued with
> > > etcupdate -p
> > > make installworld
> > > etcupdate -B
> > > shutdown -r now
> > >
> > > but after that server doesn't come back. After I conneted to this
> server
> > via
> > > IPMI ip-kvm I saw following (sorry for external link):
> > > https://i.imgur.com/jH6MHd2.png
> > >
> > > Well. There was a migration to zol between r368473 and current 'main'
> > branch so
> > > I decided to install fresh 14-current from snapshot
> > > FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to
> avoid
> > > possible problems
> > >
> > > and again, after make kernel and reboot OS runs, but after installworld
> > I ended up in the same situation
> > >
> > > thoughts ?
> > >
> > > --
> > > wbr, Sergey
> > >
> > >
> >
> > Bootcode should be updated.
> > The procedure you wrote doesn't seem to update it.
> >
>
> The posted error is one you get when you can't read the filesystem, which
> is why you need to update
> boot blocks across the OpenZFS change.
>
> Warner
>


13-current panic

2021-01-04 Thread Sergey Dyatko
Hi,
I  have multiple servers  running 13-CURRENT and after upgrade to r368448
the following panic began to appear on them:

vpan1c() at vpanic.Ox1b2/frame Oxfe019b32ffa0
panic() at panic.0x43/frame Oxfe01933
trap_fatal() at trap_fatal.0x387/frame Oxfe019b330060
trap_pfault() at trap_pfault.0x4f/frame Oxfe019b3300c0
trap() at trap.0x27d/frame Oxfe019b3301d0
calltrap() at calltrap+0x8/frame Oxfe019b3301d0
--- trap 0xc. rip = Ox80c8b3c8. rsp = Oxfe019b3302a0, rbp =
Oxfe
019b330310 ---
m_copydata() at m_copydata+0x58/frame Oxfe019b330310
tcp_output() at tcp_output+0x100b/frame Oxfe019b3304b0
tcp_do_segment() at tcp_do_segment+0x2867/frame Oxfe019b3305a0
tcp_input() at tcp_input.Oxabe/frame Oxfe019b3306d0
ip_input() at ip_input+0x125/frame Oxfe019b330760
netisr_dispatch_src() at netisr_dispatch_src+0xca/frame Oxfe019b3307b0
ether_demux() at ether demux+0x138/frame Oxfe019b3307e0
ether_nh_input() at ether_nh_input+0x351/frame Oxfe019b330840
netisr_dispatch_src() at netisr dispatch_src+0xca/frame Oxfe019b330890
ether_input() at ether_input+0x69/frame Oxfe019b3308f0
tcp_flush_out_le() at tcp_flush_out_le+0x211/frame Oxfe019b330910
tcp_push_and_replace() at tcp_push_and_replace+0x30/frame
Oxfe019b330950
tcp_lro_flush() at tcp_lro_flush+0x4c/frame Oxfe019b330980
tcp_lro_flush_all() at tcp_lro_flush_all+0x13b/frame Oxfe019b3309c0
iflib_rxeof() at iflib_rxeof+Oxc7a/frame Oxfe019b330ac0
_task_fn_rx() at _task_fn_rx+0x72/frame Oxfe019b330b00
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x15d/frame
Oxfe019b330b80
gtaskqueue thread_loop() at gtaskqueue thread loop+0xac/frame
Oxfe019b330bb0
fork_exit() at fork_exit+0x7e/frame Oxfe019b330bf0
fork trampoline() at fork_trampoline+0xe/frame Oxfe019b330bf0
-- trap O. rip = O. rsp = O. rbp = 0 ---

it is fileservers with zfs+nginx, higher is the result of recognizing
picture to text, just in case (there are was many recognision mistakes)
screenshot:
https://gyazo.com/116e9666daf0dac6d09628d1585596fa

I can run commands in the debugger when panic reappears if needed
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: gptzfsboot problem on HP P410i Smart Array

2013-03-18 Thread Sergey Dyatko
2012/8/20 Bjorn Larsson bjw...@gmail.com

 Hi Andrey,

 We are installing freeBSD using ZFS as root filesystem using the GPT
 method as described on the freeBSD ZFS wiki. We are creating a GPT
 boot partition with the gptzfsboot program embedded and then a zroot
 partition with the freeBSD binaries. This works well and boots on
 every system we tested except HP P410i smart array systems. The
 problem is that no disks are identified in gptzfsboot and the
 following error code is displayed:

 gptzfsboot: error 1 lba 32
 gptzfsboot: error 1 lba 1

 It appears that gptzfsboot is not identifying the drives properly.
 However, when we insert a printf() command in main() in zfsboot.c to
 troubleshoot the identification problem, the system boots perfectly
 fine.

 This is a problem that I believe was fixed last year in 9-CURRENT by
 implementing a proper struct for edd rather than using a char array
 for BIOS communication. However, it doesn't seems to have fixed the on
 the p410i smart arrays.


I was faced with same problem on my laptop. Adding printf() into main()
before dsk = malloc(sizeof(struct dsk)); fix boot. Yesterday, avg@ proposed
patch:
Index: /usr/src/sys/boot/i386/zfsboot/zfsboot.c
===
--- /usr/src/sys/boot/i386/zfsboot/zfsboot.c(revision 248421)
+++ /usr/src/sys/boot/i386/zfsboot/zfsboot.c(working copy)
@@ -302,6 +302,7 @@
  * region in the SMAP, use the last 3MB of 'extended' memory as a
  * high heap candidate.
  */
+   high_heap_size = 0;
 if (bios_extmem = HEAP_MIN  high_heap_size  HEAP_MIN) {
high_heap_size = HEAP_MIN;
high_heap_base = bios_extmem + 0x10 - HEAP_MIN;

it works for me, without printf() :) Can you test it ?

 Best regards,

 Björn Larsson


 On Sun, Aug 19, 2012 at 6:41 PM, Andrey V. Elsukov bu7c...@yandex.ru
 wrote:
 
  On 19.08.2012 11:22, Bjorn Larsson wrote:
   We are having problems with gptzfsboot on a HP DL360 G7 using the P410i
   Smart Array Controller.
   I’ve some information on this in the archive on this mailing list that
 this
   has supposedly been fixed with revision 227400, by implementing the edd
   data structure.
   However we still see the same problem and by adding a printf() in
 zfsboot.c
   fixes the problem.
   Please, let me know if anyone have seen this problem and if there is a
 fix
   for it?
 
  Hi,
 
  what exactly do you have?
 
  --
  WBR, Andrey V. Elsukov
 
 ___
 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: ctfmerge core dump

2012-05-24 Thread Sergey Dyatko
2012/5/7 Steve Wills swi...@freebsd.org

  On 2012/5/6 5:08, b. f. wrote:
  On 5/5/12, Steve Willsswi...@freebsd.org  wrote:
  Thanks for the info. I took a look at the dump and see this:
 
  % sudo gdb /usr/bin/ctfmerge ctfmerge.core
  [GDB will not be able to debug user-mode threads: Undefined symbol
  td_thr_getxmmregs]
 
  Hmm, is the thread debugging broken on amd64 now ?  td_thr_getxmmregs
  resides
  in libthread_db and /usr/src/gnu/usr.bin/gdb/libgdb is complaining about
  the missing
  symbol.
 

 Maybe or maybe I have done something wrong on my system. FWIW, I do all my
 builds with debugging enabled.

 BTW, just to confirm, I was able to work around the original issue once I
 updated past r235068. I had to disable DTrace build and build and install
 a new libthr, then was able to re-enable DTrace and everything was fine.

 Thanks,
 Steve



hm.. looks like problem is still here. I'm trying update my r234992 to
r235887
http://pastebin.com/stm7b8hQ
___
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