Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    No Web Interface on Thu May 29 08:48:37 CDT 2014

    Scheduled Pinned Locked Moved 2.2 Snapshot Feedback and Problems - RETIRED
    54 Posts 12 Posters 14.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      m3usv0x
      last edited by

      @charliem:

      @m3usv0x:

      Is sad.

      No, it's alpha

      Thank you, Captain Obvious.

      We're all aware it's Alpha.

      1 Reply Last reply Reply Quote 0
      • pttP
        ptt Rebel Alliance
        last edited by

        Is the same on "amd64-20140529-1554" snapshot (no webconfigurator, boot stuck at starting Cron…), but i was able to login via SSH and perform a "upgrade" ;)

        
        login as: root
        Using keyboard-interactive authentication.
        Password for root@pfsense.d510:
        *** Welcome to pfSense 2.2-ALPHA-pfSense (amd64) on pfsense ***
        
         WAN (wan)       -> pppoe0     -> v4/PPPoE: 1.1.1.1/32
         LAN (lan)       -> re1        -> v4: 192.168.1.254/24
         GEST (opt1)     -> re0        -> v4: 172.20.254.6/29
         W311U (opt2)    -> run0_wlan1 -> v4: 192.168.0.1/24
        
         0) Logout (SSH only)                  8) Shell
         1) Assign Interfaces                  9) pfTop
         2) Set interface(s) IP address       10) Filter Logs
         3) Reset webConfigurator password    11) Restart webConfigurator
         4) Reset to factory defaults         12) pfSense Developer Shell
         5) Reboot system                     13) Upgrade from console
         6) Halt system                       14) Disable Secure Shell (sshd)
         7) Ping host                         15) Restore recent configuration
        
        Enter an option: 13
        
        Starting the pfSense console firmware update system..
        
        1) Update from a URL
        2) Update from a local file
        Q) Quit
        
        Please select an option to continue: 1
        
        Enter the URL to the .tgz or .img.gz update file.
        Type 'auto' to use http://snapshots.pfsense.org/FreeBSD_stable/10/amd64/pfSense_HEAD/.updaters//latest.tgz
        > http://snapshots.pfsense.org/FreeBSD_stable/10/amd64/pfSense_HEAD/updates/pfSense-Full-Update-2.2-DEVELOPMENT-amd64-20140526-1601.tgz
        
        Fetching file size...
        
        File size: 80085938
        
        Fetching file...
        looking up snapshots.pfsense.org
        connecting to snapshots.pfsense.org:80
        requesting http://snapshots.pfsense.org/FreeBSD_stable/10/amd64/pfSense_HEAD/updates/pfSense-Full-Update-2.2-DEVELOPMENT-amd64-20140526-1601.tgz
        remote size / mtime: 80085938 / 1401202722
        /root/firmware.tgz                              6% of   76 MB  106 kBps 11m34s
        
        

        edit: fix code tag ;)

        1 Reply Last reply Reply Quote 0
        • Raul RamosR
          Raul Ramos
          last edited by

          You can update through console or ssh (this one have ssh)

          Option 13 -> 1 -> "auto"

          pfSense:
          ASRock -> Wolfdale1333-D667 (2GB TeamElite Ram)
          Marvell 88SA8040 Sata to CF(Sandisk 4GB) Controller
          NIC's: RTL8100E (Internal ) and Intel® PRO/1000 PT Dual (Intel 82571GB)

          1 Reply Last reply Reply Quote 0
          • M
            m3usv0x
            last edited by

            @mais_um:

            You can update through console or ssh (this one have ssh)

            Option 13 -> 1 -> "auto"

            I've already done this, but for the sake of knowing…
            If I get stuck at the loader where it get stuck at cron, how do I access the console?

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              As Charlie said, hit ^C (Control-C).

              Steve

              1 Reply Last reply Reply Quote 0
              • C
                charliem
                last edited by

                @m3usv0x:

                @charliem:

                @m3usv0x:

                Is sad.

                No, it's alpha

                Thank you, Captain Obvious.

                We're all aware it's Alpha.

                Yes, but it sounded (to me) like you were expecting more from alpha.

                To keep this post somewhat on-topic, I noticed an option in the installation menu to "rescue config.xml":

                < quick/easy install >
                < custom install >
                < rescue config.xml >
                < reboot >
                < exit >
                

                I haven't tried to use it, but perhaps it would be easier for some rather than using the other methods described in this thread.

                1 Reply Last reply Reply Quote 0
                • M
                  m3usv0x
                  last edited by

                  Has anyone downloaded the last snapshot from today at 23:36?

                  1 Reply Last reply Reply Quote 0
                  • I
                    ingmthompson
                    last edited by

                    I updated to amd64-20140529-1755, issue is still present. Tried updating again from SSH, didn't fix it. Restarting webConfigurator from SSH doesn't fix it. Routing and firewall functionality seems to be unaffected.

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      Mmm, the most recent update file is still far too small, <1MB for the Nano 1G update.

                      Steve

                      1 Reply Last reply Reply Quote 0
                      • C
                        charliem
                        last edited by

                        Playing with this mornings amd-64 snapshot, as a fresh install in a VM.  As noted earlier, the boot hangs after 'Starting CRON'.  Seems that the guilty line is in /etc/rc:

                         /usr/local/sbin/fcgicli -f /etc/rc.start_packages
                        

                        If you comment out only that line in /etc/rc, then the boot completes and goes to the console menu.

                        Run that line at a console prompt in a recent snapshot, it hangs until you ^C out of it.  But run that line in an earlier, working snapshot, and it completes and returns to the shell.  Note that I'm testing without any packages installed, so the command should not actually do anything for me.

                        This explains the hanging boot, and may be related to the missing webgui, but I haven't dug that far yet.

                        As a side note, if you do a fresh install, you can run /etc/sshd by hand to generate the keys.  sshd won't start up until keys are present.

                        [edit: noted as amd-64 arch]

                        1 Reply Last reply Reply Quote 0
                        • C
                          charliem
                          last edited by

                          The following cases all show a missing webgui and boot hang symptoms described above:

                          • amd-64, fresh install, 30-May image
                          • i386, fresh install, 30-May image
                          • amd-64, fresh install 23-May image (confirmed working and completed the wizard) and then confirmed failing when auto-upgraded to 30-May update
                          1 Reply Last reply Reply Quote 0
                          • I
                            ingmthompson
                            last edited by

                            Still no go for web interface on amd64-20140530-1557.

                            EDIT: I can get the bootup to complete by running:

                            
                            ps aux | grep -i rc
                            
                            

                            Then finding the PID of /usr/local/sbin/fcgicli -f /etc/rc.start_packages and running:

                            
                            kill -9 xxxxx
                            
                            

                            Where xxxxx is the PID of the process. This doesn't bring up the web interface though.

                            1 Reply Last reply Reply Quote 0
                            • A
                              adam65535
                              last edited by

                              I am running the 30th snapshot on i386 and sshd works for me after running it manually the last time I booted to create the sshd keys.  The GUI doesn't work for me though.

                              I noticed the same  /usr/local/sbin/fcgicli -f /etc/rc.start_packages command in the process list apparently stuck.  I killed it and then a few more with different rc scripts specified as arguments were launched by minicron I think.  Those are stuck now too.

                              I ran the tracing command truss manually on one of the command lines and it appears to lock up around the time of writting to /var/run/php-fpm.socket.  php-fpm is running.

                              truss /usr/local/sbin/fcgicli -f /etc/rc.update_alias_url_data

                              connect(3,{ AF_UNIX "/var/run/php-fpm.socket" },106) = 0 (0x0)
                              __sysctl(0xbfbfe6c4,0x2,0xbfbfe708,0xbfbfe6c0,0x0,0x0) = 0 (0x0)
                              __sysctl(0xbfbfe6c4,0x2,0xbfbfe808,0xbfbfe6c0,0x0,0x0) = 0 (0x0)
                              __sysctl(0xbfbfe6c4,0x2,0xbfbfe908,0xbfbfe6c0,0x0,0x0) = 0 (0x0)
                              __sysctl(0xbfbfe6c4,0x2,0xbfbfea08,0xbfbfe6c0,0x0,0x0) = 0 (0x0)
                              __sysctl(0xbfbfe6c4,0x2,0xbfbfeb08,0xbfbfe6c0,0x0,0x0) = 0 (0x0)
                              madvise(0x28804000,0x1000,0x5,0x281c15f8,0xbfbfe4f4,0x28120ccf) = 0 (0x0)
                              madvise(0x28816000,0x1000,0x5,0x281c15f8,0xbfbfe4f4,0x28120ccf) = 0 (0x0)
                              madvise(0x28818000,0x1000,0x5,0x281c15f8,0xbfbfe56c,0x28120ccf) = 0 (0x0)
                              madvise(0x28803000,0x3000,0x5,0x281c15f8,0xbfbfe57c,0x28120ccf) = 0 (0x0)
                              write(3,"\^A\^A\0\^A\0\b\0\0\0\^A\0\0\0\0"...,263) = 263 (0x107)
                              

                              It just sits there forever.  Any /usr/local/sbin/fcgicli command executed even by hand gets stuck there.

                              1 Reply Last reply Reply Quote 0
                              • A
                                adam65535
                                last edited by

                                I got the GUI working.  I killed php-fpm and restarted it.  So this is related to php-fpm somehow not starting up properly or something hanging it up.

                                killall php-fpm

                                /usr/local/sbin/php-fpm -c /usr/local/lib/php.ini -y /usr/local/lib/php-fpm.conf -RD 2>&1 >/dev/null

                                1 Reply Last reply Reply Quote 0
                                • A
                                  adam65535
                                  last edited by

                                  As soon as I ran

                                  /usr/local/sbin/fcgicli -f /etc/rc.start_packages

                                  The webgui doesn't work anymore.  Any attempts to use php-fpm locks up the process writting to the fpm socket again.

                                  It appears something in the command above locks up php-fpm.  If I restart php-fpm it works again.  I am going to comment out the command above from /etc/rc and see if the firewalls starts up properly.  I have a feeling it will.  I will just need to start the packages manually after a reboot.  This is at home so it isn't a big deal :).

                                  1 Reply Last reply Reply Quote 0
                                  • A
                                    adam65535
                                    last edited by

                                    Well… It is not specifically startpackages which kills it.  It seems to lock up with other fcgicli commands during boot.  If I restart php-fpm and then execute the few fcgicli commands in order from /etc/rc one will eventually cause php-fpm to block on writing to it's socket.  I will just manually kill php-fpm and restart it after every boot for now.  It appears the GUI doesn't lock it up (I didn't test everything though... only viewing some of the pages).

                                    1 Reply Last reply Reply Quote 0
                                    • A
                                      adam65535
                                      last edited by

                                      I just updated to the 31st snapshot and the problem is still there.  I just manually kill php-fpm and restart it per how it is started in /etc/rc

                                      2.2-ALPHA (i386)
                                      built on Sat May 31 10:32:02 CDT 2014
                                      FreeBSD 10.0-STABLE

                                      1 Reply Last reply Reply Quote 0
                                      • A
                                        adam65535
                                        last edited by

                                        The web interface stopped working again when I uninstalled the Patches package.  I killed and restarted php-fpm and it started working again.

                                        1 Reply Last reply Reply Quote 0
                                        • C
                                          charliem
                                          last edited by

                                          Great work!  I know that commenting out the start_packages line from /etc/rc is not enough to get the webgui working, as you found out.  There are a few minicron entries after that line in /etc/rc that use fcgicli as well, one hourly account expire and one daily alias url updater.  If I understand the problem correctly, they should be commented out as well, right?

                                          In the old days, I'd look through the recent commits to the pfSense-tools tree, but I haven't taken the steps to regain access to that yet.

                                          Hopefully the devs can find a fix, now that you've narrowed down the problem even more.

                                          1 Reply Last reply Reply Quote 0
                                          • A
                                            adam65535
                                            last edited by

                                            I am still getting the 100% CPU by check_reload_status too.  I killed that and restarted it and the CPU went back to normal again.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.