Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 83 replies
  • Subscribers 2 subscribers
  • Views 30343 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Soft-Release v7.402

trollvottel
Today we soft-released v7.402 on our FTP-Servers (ftp.astaro.de for sure). The GA release will follow a few days later, if everything goes well. Use the easter holidays to find out [:D]

Please check intensively, if your NIC sorting stays as expected. We updated Intel e1000 driver and integrated e1000e so there is still a small possibility something may go wrong although we tested that thoroughly.

Update:
We just uploaded a fixed Up2Date package for v7.402 to our FTP-Server (ftp.astaro.de, Mirrors may take a while to sync). This new version should not break your VLANs (and probably other devices) anymore.

Make sure you download the correct new version:
MD5sum: a24570c061234f1ebf0509c1104f9423
Size: 143157552 bytes

It is possible to "repair" a broken v7.402 update by decrementing /etc/version to v7.401, deleting /var/lib/nics, installing the new fixed update and then re-assign the phyiscal hardware devices to your vlan devices via webadmin.

Sorry for inconvenience but thanks to your support, the GA release will not have that problem [H]


This thread was automatically locked due to age.
  • 0 in reply to BrucekConvergent
    Ahhh, yes, I remember that now.  I'll go hit my head against a different wall now.

    Thanks very much Bruce - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    utm_kid, see my last post; manual update of large up2date packages will fail on systems with low memory resources, and it is a known issue.  The automatic up2date process does still work fine, though.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    Bruce, is there a work-around with ACC?  That might be a stimulus for me to get started on that installation.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BrucekConvergent
    utm_kid, see my last post; manual update of large up2date packages will fail on systems with low memory resources, and it is a known issue.  The automatic up2date process does still work fine, though.


    Yes Sir , i tryed that also i stuck with error 512 i follow up2date troubleshooting also even send ticket to astaro also but no luck,some time back i tryed to update 7.4 to 7.401 ,

    Thanks,
  • 0 in reply to BAlfson
    Bruce, is there a work-around with ACC?  That might be a stimulus for me to get started on that installation.


    You know, you could try using the up2date cache on ACC and point the troublesome ASG units at it for up2dates.  However, as I have not used that feature (I have many remote managed customers, and sucking up my bandwidth on our circuits to give them an up2date that is downloaded rather quickly via the automatic process over the public internet is something I opt not to do), I don't know if you can manually upload up2date packages into the cache or not... might be a good question for the ACC forum.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BarryG
    BarryG,

    can you please issue a 'lspci -n' on your affected system? You don't need to update to 7.402 again - running on 7.401 should show same result.

    Thanks,
    Marcel
  • 0 in reply to Marcel_01
    lspci -n

    # lspci -n
    00:00.0 0600: 8086:7190 (rev 03)
    00:01.0 0604: 8086:7191 (rev 03)
    00:07.0 0601: 8086:7110 (rev 02)
    00:07.1 0101: 8086:7111 (rev 01)
    00:07.2 0c03: 8086:7112 (rev 01)
    00:07.3 0680: 8086:7113 (rev 02)
    00:08.0 0300: 5333:88f0
    00:09.0 0200: 8086:1229 (rev 02)
    00:0a.0 0200: 8086:1229 (rev 05)
    00:0b.0 0200: 8086:1229 (rev 02)
    00:0c.0 0200: 8086:1229 (rev 02)


    Thanks,
    Barry
  • 0 in reply to BarryG
    Barry, outta curiosity, what does lspci -nn show?   lspci -nk?

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent 

    # lspci -nn
    00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge [8086:7190] (rev 03)
    00:01.0 PCI bridge [0604]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge [8086:7191] (rev 03)
    00:07.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110] (rev 02)
    00:07.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111] (rev 01)
    00:07.2 USB Controller [0c03]: Intel Corporation 82371AB/EB/MB PIIX4 USB [8086:7112] (rev 01)
    00:07.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 02)
    00:08.0 VGA compatible controller [0300]: S3 Inc. 86c968 [Vision 968 VRAM] rev 0 [5333:88f0]
    00:09.0 Ethernet controller [0200]: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 [8086:1229] (rev 02)
    00:0a.0 Ethernet controller [0200]: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 [8086:1229] (rev 05)
    00:0b.0 Ethernet controller [0200]: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 [8086:1229] (rev 02)
    00:0c.0 Ethernet controller [0200]: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 [8086:1229] (rev 02)


    # lspci -nk
    00:00.0 0600: 8086:7190 (rev 03)
    	Kernel driver in use: agpgart-intel
    00:01.0 0604: 8086:7191 (rev 03)
    00:07.0 0601: 8086:7110 (rev 02)
    00:07.1 0101: 8086:7111 (rev 01)
    	Kernel driver in use: PIIX_IDE
    00:07.2 0c03: 8086:7112 (rev 01)
    	Kernel driver in use: uhci_hcd
    00:07.3 0680: 8086:7113 (rev 02)
    	Kernel modules: i2c-piix4
    00:08.0 0300: 5333:88f0
    00:09.0 0200: 8086:1229 (rev 02)
    	Kernel driver in use: e100
    	Kernel modules: eepro100, e100
    00:0a.0 0200: 8086:1229 (rev 05)
    	Kernel driver in use: e100
    	Kernel modules: eepro100, e100
    00:0b.0 0200: 8086:1229 (rev 02)
    	Kernel driver in use: e100
    	Kernel modules: eepro100, e100
    00:0c.0 0200: 8086:1229 (rev 02)
    	Kernel driver in use: e100
    	Kernel modules: eepro100, e100


    This is from 7.401.

    Thanks,
    Barry
  • 0 in reply to BarryG
    Well, the gigabit driver update (e1000,e1000e) does at least not at first glance cause this, since for the PCI IDs listed the driver/module loading will not be touched. However, it's quite probable that there is a connection - although we did not update the e100 portion.

    Barry, you wrote about errormessages appearing 3 times on bootup. Can you remember the lines from normal bootup where those error messages appeared in-bettween? If I had to guess, I'd assume the following:
    - Errors appeared 3x (basically at same time) after 'Starting NIC initialization'
    - Your interfaces disappeared afterwards ('ifconfig -a' or 'ip addr' did not show them anymore)
    - Rebooting did not help (same procedure every bootup)

    Is that correct?

    cheers
    Marcel
Cookie Information Banner