Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[arista] Align flash partition at 1M #2104

Merged
merged 1 commit into from
Oct 2, 2018
Merged

Conversation

Staphylo
Copy link
Collaborator

@Staphylo Staphylo commented Oct 1, 2018

Flashes used for the 7050QX-32 and 7050QX-32S have a fw issue.
The best option to solve the problem is to upgrade to a newer firmware.
However this can only be done while in memory and takes 10 seconds.
Adding an upgrade mechanism is possible but would need more
consideration as flashing the firmware and reformatting the flash will
exceed fast-reboot requirements.

A quick mitigation is to align the ext4 partition that we create on
these vfat based system on a 4k boundary.
Here we chose 1M instead but it's the same.
Newer version of sfdisk do this automatically but the one in debian
today doesn't have this behavior.

This workaround will only reduce the pace of the flash health
degradation. The only long term fix is to upgrade the firmware.

Flashes used for the 7050QX-32 and 7050QX-32S have a fw issue.
The best option to solve the problem is to upgrade to a newer firmware.
However this can only be done while in memory and take 10 seconds.
Adding an upgrade mechanism is possible but would need more
consideration as flashing the firmware and reformating the flash will
exceed the fast-reboot requirements.

A quick mitigation is to align the ext4 partition that we create on
these vfat based system on a 4k boundary.
Here we chose 1M instead but it's the same.
Newer version of sfdisk do this automatically but the one in SONiC
today doesn't have this behavior.

This workaround will only reduce the pace of the flash health
degradation. The only long term fix is to flash the firmware.
@lguohan
Copy link
Collaborator

lguohan commented Oct 2, 2018

do we need this one for 201803 branch as well?

@lguohan lguohan merged commit 6ba2f97 into sonic-net:master Oct 2, 2018
@Staphylo
Copy link
Collaborator Author

Staphylo commented Oct 2, 2018

It would need to go in 201807.
If you plan on converting more 7050QX-32 and 7050QX-32S with the 201803 release, then it should also be cherry-picked to that branch.

@Staphylo
Copy link
Collaborator Author

Staphylo commented Oct 4, 2018

@lguohan should I open PR for the 201807 and 201803 branches?

lguohan pushed a commit that referenced this pull request Oct 15, 2018
Flashes used for the 7050QX-32 and 7050QX-32S have a fw issue.
The best option to solve the problem is to upgrade to a newer firmware.
However this can only be done while in memory and take 10 seconds.
Adding an upgrade mechanism is possible but would need more
consideration as flashing the firmware and reformating the flash will
exceed the fast-reboot requirements.

A quick mitigation is to align the ext4 partition that we create on
these vfat based system on a 4k boundary.
Here we chose 1M instead but it's the same.
Newer version of sfdisk do this automatically but the one in SONiC
today doesn't have this behavior.

This workaround will only reduce the pace of the flash health
degradation. The only long term fix is to flash the firmware.
lguohan pushed a commit that referenced this pull request Oct 15, 2018
Flashes used for the 7050QX-32 and 7050QX-32S have a fw issue.
The best option to solve the problem is to upgrade to a newer firmware.
However this can only be done while in memory and take 10 seconds.
Adding an upgrade mechanism is possible but would need more
consideration as flashing the firmware and reformating the flash will
exceed the fast-reboot requirements.

A quick mitigation is to align the ext4 partition that we create on
these vfat based system on a 4k boundary.
Here we chose 1M instead but it's the same.
Newer version of sfdisk do this automatically but the one in SONiC
today doesn't have this behavior.

This workaround will only reduce the pace of the flash health
degradation. The only long term fix is to flash the firmware.
prsunny added a commit that referenced this pull request Jan 27, 2022
Commits:
*6d66079 - 2022-01-26 : [202012] [vnetorch] Add ECMP support for vnet tunnel routes with endpoint health monitoring (#2104) [Shi Su]
taras-keryk pushed a commit to taras-keryk/sonic-buildimage that referenced this pull request Apr 28, 2022
)

What I did
Fix sonic-net#2068

Changes to fields under MIRROR_SESSION using GCU are not reflected and removal will result in orchagent crash unless each key is deleted and added back. This means the fields are create-only.

How I did it
Mark the fields under MIRROR_SESSION as create-only

How to verify it
unit-test
@Staphylo Staphylo deleted the flash-4k branch December 6, 2022 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants