Schlomo prepare for 2 8 release #22
Conversation
|
@rear/contributors WDYT? |
|
@schlomo in the fedora version list i don't know if is ok with issue #3343 open. the rest seems ok to me. |
|
@pcahyna |
@jsmeix Fedora Silverblue uses BTRFS methods not (yet) supported by ReaR. Therefore, I would not add it to the supported Linux OSes for our ReaR v2.8 release. |
documentation/release-notes-2-8.md
Outdated
| * `BLOCKCLONE` block device cloning via `dd` | ||
| * `BORG` Borg Backup | ||
| * `CDM` Rubrik Cloud Data Management | ||
| * `DP` HP Data Protector |
There was a problem hiding this comment.
HP does not own DP anymore - see https://www.opentext.com/products/data-protector
I think uses it form fedora 33? We may can say for now: ReaR 2.8 supports Fedora from 28 to 33, but since 33 only if not BTRFS & SwapOnZRAM? |
By careful as 'Fedora' is not the same as 'Fedora Silverblue' as Silverblue is a special desktop version using a layered OSTree system to avoid users make unwanted changes. |
Uooh!! so the only one has problems is OStree (silverblue)? up to F41 are working with BTRFS & SwapOnZRAM? |
|
We can add the info that we only support regular Fedora installs, but not Silverblue. With that constraint, can we claim support for Fedora 41? Since Fedora 39 is already EOL I'd even go so far as to say that we only need to care about F40 and F41 |
Yes - plain Fedora we can support, but not the Silverblue variant. |
|
So is it OK to declare that we support regular Fedora, even with BTRFS? Or only without BTRFS? |
Fedora is OK, but I cannot tell if BTRFS works or not. |
|
I think during |
|
@jsmeix We've been testing that thoroughly this week. Btrfs on Fedora Workstation seems to work fine if and only if the filesystem spans a single disk. If it is used in a RAID setup (RAID 1 btrfs is the default layout for multiple disk systems on Fedora Workstation during install), things break spectacularly during recovery since ReaR has no support for it. Starting with rear/rear#3175 all mounted btrfs subvolumes will be backed-up (so nothing should get lost), but ReaR would recreate the filesystem only on a single disk with the same FS UUID leaving the rest of the disks untouched with a degraded filesystem. So there would be actually two filesystems with the same FS UUID. Moreover, if That said, support for btrfs on Fedora is still quite experimental. edit: RAID 1 is the default, not RAID 0 (thx @pcahyna) |
|
Regarding RAID and btrfs: Traditional Linux kernel software RAID0 and RAID1 I think what is not supported in ReaR is |
@jsmeix Yes, exactly! That's what I meant, sorry for the confusion. |
I believe this is issue rear/rear#2028 and perhaps it should be reopened as the result is quite unexpected. |
|
Thanks for your feedback @rear/contributors - I added a new section to document unsupported features. Can I kindly ask you to update this branch with more stuff that you would like to see mentioned there? I think naming known limitations in the release notes is a nice way @pcahyna maybe as a quick "improvement" we can actually detect such BTRFS multi device scenarios and error out during |
README.md
Outdated
| Example for release notes: | ||
|
|
||
| ```bash | ||
| docker run --rm -it alpine/lynx --dump https://relax-and-recover.org/documentation/release-notes-2-8 > release-notes-2-8.txt |
There was a problem hiding this comment.
This does not ensure in general that
the generated release-notes-2-8.txt is ASCII, cf.
https://github.com/rear/rear/wiki/Coding-Style#character-encoding
E.g. on my openSUSE Leap 15.5 workstation
$ lynx --dump https://relax-and-recover.org/documentation/release-notes-2-8 >release-notes-2-8.txt
$ file release-notes-2-8.txt
release-notes-2-8.txt: UTF-8 Unicode text
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
To ensure the generated release-notes-2-8.txt is ASCII
one must run lynx in POSIX locale:
$ export LC_ALL=POSIX
$ export LANG=POSIX
$ lynx --dump https://relax-and-recover.org/documentation/release-notes-2-8 >release-notes-2-8.txt
$ file release-notes-2-8.txt
release-notes-2-8.txt: ASCII text
There was a problem hiding this comment.
By the way:
Also with lynx the generated release-notes-2-8.txt
has the unwanted header and footer like
[1]Relax-and-Recover
* [2]Home
* [3]Features
* [4]Documentation
* [5]Downloads
* [6]Support
* [7]Development
* [8]Events
and
[20]
If you like Relax-and-Recover please consider sponsorship
with the current online
https://relax-and-recover.org/documentation/release-notes-2-8
(i.e. without the changes in this pull request), cf.
rear/rear#3238 (comment)
... because ReaR does not support this scenario at the moment. Related: rear/rear.github.com#22 (comment) Related: rear#2028
... because ReaR does not support this scenario at the moment. Related: rear/rear.github.com#22 (comment) Related: rear#2028
savelayout: error out on mounted multi-disk BTRFS filesystems because ReaR does not support this scenario at the moment, see rear/rear.github.com#22 (comment) and #2028
The new doc/rear-release-notes.txt was made via export LC_ALL=POSIX export LANG=POSIX lynx --dump https://relax-and-recover.org/documentation/release-notes-2-8 >rear-release-notes.txt see https://github.com/rear/rear/wiki/Release-process and rear/rear.github.com#22
|
@schlomo |
|
gone |
Use proper Markdown with proper links and show how to use Lynx to convert to proper text file without manual processing
consolidate list of backup methods and use everywhere, place also prominently on front page
after we approve and merge this, I'll update the rear README accordingly