Op woensdag 29 maart 2023 20:36:26 CEST schreef Larry Len Rainey:
> Btrfs is a loser for me too - ext4 forever - btrfs is nothing but trouble. I
> will be leaving as well if btrfs is required. Looks like Mint MATE will be
> my replacement.
> 
> I wonder if Walmart will go btrfs - they like LVM. and ext4 and raw
> filesystems.
> 
> 
> On 3/29/23 13:18, Carlos E. R. wrote:
> 
> On 2023-03-29 17:25, Fritz Hudnut wrote:
> 
> 
> Leap 16.0 Putting high level requirements for Alpha. I think I could
> have something usable by end of this week.
> https://en.opensuse.org/Portal:16.0 So far everything shows that base
> system will have traditional 12 months + overlap support.
> 
> 
> [QUOTE]
> Migration path from the previous releases
> 
> Users will be officially able to upgrade to Leap 16 only from the
> openSUSE Leap 15.5 transactional update server and from Leap Micro
> 5.X. There are experimental tools that can be used to migrate a
> non-transactional-update system, but we highly recommend doing a clean
> installation instead. The migrated system would have to be btrfs
> based.
> 
> [/QUOTE]
> 
> This is good news . . . will this migration path from 15.5 be
> available sometime soon?  Or, the repos will have to be edited to "16"
> to make it to Alpha stage materials??
> 
> 
> I don't see the good news anywhere.
> 
> Only 15.5 transactional update server and Leap Micro 5.X can upgrade, not
> the rest.
> 
> And it has to be btrfs.
> 
> Thus none of my systems can upgrade. What then, Ubuntu, Debian, what?
To be clear:
- There is going to be a Leap 16
- Leap 16 is not going to be just another Leap
- It is going to be ALP based
- Anyone following news.o.o can read about that
So please stop basing your assumptions on your guesses. 
Meetings have been going on for ~1 year, everything was done in public.

-- 
Gertjan Lettink a.k.a. Knurpht
openSUSE Board
openSUSE Forums Team

Am Mi., 29. März 2023 um 20:19 Uhr schrieb Carlos E. R. :

I don't see the good news anywhere.

Only 15.5 transactional update server and Leap Micro 5.X can upgrade, not the rest.

And it has to be btrfs.

And x86_64-v2.

Thus none of my systems can upgrade. What then, Ubuntu, Debian, what?

Seems so. Best Martin

Am Mi., 29. März 2023 um 21:03 Uhr schrieb Dominique Leuenberger :

Let's first finish 15.5, shal we? :)

Yes. And that will be supported till the end of 2024. :-) Whatever became of the option for x86_64-v0? Because that is a hard break for users of old hardware. Best Martin

On 3/30/23 05:33, Dominique Leuenberger wrote:

On Wed, 2023-03-29 at 08:25 -0700, Fritz Hudnut wrote:

...

...

Leap 16.0 Putting high level requirements for Alpha. I think I could have something usable by end of this week. https://en.opensuse.org/Portal:16.0 So far everything shows that base system will have traditional 12 months + overlap support.

[QUOTE] Migration path from the previous releases

Users will be officially able to upgrade to Leap 16 only from the openSUSE Leap 15.5 transactional update server and from Leap Micro 5.X. There are experimental tools that can be used to migrate a non-transactional-update system, but we highly recommend doing a clean installation instead. The migrated system would have to be btrfs based.

[/QUOTE]

This is good news . . . will this migration path from 15.5 be available sometime soon?  Or, the repos will have to be edited to "16" to make it to Alpha stage materials??

F Let's first finish 15.5, shal we? :)

At the moment, Leap 16.0 is merely a draft project. It will be based on SUSE's ALP project (based on current knwoledge, SUSE ALP has had various prototypes)

Essentially, it's heading in the direction of MicroOS Desktop i.e. immutable OS (transactional system).

'Upgrading' from Leap 15.x to Leap 16.x is technically only viable for Leap 15.x that were installed as transactional servers, simply due to the fact that there the partition layout, btrfs config, and the read- only capability are a given. Regular 15.x installs (normal desktop installs) are not installed on a read-only system and thus are 'too different' to migrate

On MicroOS/ALP, the root file system is on a Read-Only partition, upgrades are installed onto a btrfs snapshot and on reboot the new snapshot being used as active one.

Workloads are generally coming in the form of 'containers' (podman for system services, flatpak for actual applications). The clear line where 'base OS' ends and 'application layer' starts is still to be defined. MicroOS Desktop is the perfect example for the direction it is heading.

Distrobox is supposed to be used for anything you are 'playing' with, i.e compiling stuff, installing random stuff; that's isolated from the base OS, and actually allows you as much flexibility as you wish to have, even having different containers running different OSes (think: one container with Tumbleweed for the newest flash, one container where you build up your app based on Leap 16 RPM's to be more stable, one container where you can have Python 3.12... all without risking the actual underlying Base OS).

The separation allows for faster moving parts where they are useful - one thing which was a real pain with Leap 15.5 is the still very old python interpreter for example.

/usr/bin/python3 can't easily be changed to not be python 3.6 anymore, as that would break the backwards compatibility promise: scripts that worked on 15.4 are supposed to be compatible with 15.5; python 3.10 is not 100% backwards compatible. Changing is thus 'bad'. But with 16.0 we can separate those things out - i.e. you build a container with Python 3.6 for you workloads where you need to run scripts compatible with this version and another container where we can offer newer python interpreters (the interpreter is just one example - always look from the leaf application down to what is best for this, and then combine things as they make sense).

Those changes are very positive in my opinion. It allows for Leap 16.x to have a rather 'small-ish' set of base packages, that need to be tightly coupled. The rest comes in form of containers, which can have entirely different release cycles for example.

Help design the new system - don't be scared of the change. Think about what you actualy want to do with the system and design workloads that help you achieve those things. Let's make openSUSE Leap 16.x the OS that 'gets out of your way and allows you to use your applications without you having to take care of the OS'

On the designing a new system, we proved that you could take ALP's sources and build a distro with all the core components not in containers and on a read write filesystem without transactional updates. That should be upgradable from Leap 15.5 as long as tumbleweed still is. We worked with a much more limited set of packages but proved it would be possible for the community to maintain and I plan to work on something like this again after the 15.5 release when more of ALP is more mature But I can only commit to a pretty core set of packages so to get even close to feature parity with Leap it will require a bunch of community involvement to get close to feature parity with Leap. At the same time for things the community doesn't provide as RPM's the ALP containers will work fine. But as I said in the other email i'll have a talk on it at the conference. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Wed, Mar 29, 2023 at 9:03 PM Dominique Leuenberger wrote:

...

Users will be officially able to upgrade to Leap 16 only from the openSUSE Leap 15.5 transactional update server and from Leap Micro 5.X. There are experimental tools that can be used to migrate a non-transactional-update system, but we highly recommend doing a installation instead. The migrated system would have to be btrfs based.

how are the possiblities when having started a fresh install of 15.4 on a new nvme laptop in the default desktop (KDE) install offered? i think i remember some transactional questions but that was hinted as being for servers. will a fresh 15.4 installed as a desktop or notebook simple use case, be able to be used for future leap in the long term? lsblk shows about as follows: (with full disk encrypton, typing passphrase twice situation) NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 1.8T 0 disk ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi └─nvme0n1p2 259:2 0 1.8T 0 part └─cr_nvme-Samsung_SSD_xxxxxxxxxxxxxxxxxxxxxxxxxxx-part2 254:0 0 1.8T 0 crypt ├─system-swap 254:1 0 30.7G 0 lvm [SWAP] └─system-root 254:2 0 1.8T 0 lvm /var /usr/local /tmp /srv /root /opt /home /boot/grub2/x86_64-efi /boot/grub2/i386-pc /.snapshots / any good for long term? thank you lots.

On Thursday 2023-03-30 15:58, Thorsten Kukuk wrote:

You cannot migrate a non-transactional system to a transactional system.

If "Leap 16" will only contain transactional variants, you have to do a fresh installation.

With just enough manual rescue shell commands, any system can be massaged to meet expectations ;) [I vividly remember creating root-on-LUKS configs in 2007/Q1, before yast offered it - much later - to do it for the user.]