So Leap is transitioning to a 16 variation?
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
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? -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
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
On 3/30/23 05:23, Knurpht-openSUSE wrote: > 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. > It is still possible to make something very much like Leap 15 from the ALP sources if there is enough community interest in helping to support packages. It in many cases may even be migratable from Leap 15, A couple of us worked on a proof of concept during SUSE's last hackweek look forward to a talk on it at this years 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
Am Mi., 29. März 2023 um 20:19 Uhr schrieb Carlos E. R. <robin.listas@telefonica.net>:
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
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' Cheers, Dominique
Am Mi., 29. März 2023 um 21:03 Uhr schrieb Dominique Leuenberger <dimstar@opensuse.org>:
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 Wed, 2023-03-29 at 21:13 +0200, Martin Schröder wrote:
Am Mi., 29. März 2023 um 21:03 Uhr schrieb Dominique Leuenberger <dimstar@opensuse.org>:
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.
SUSE's ALP is x86-64-v2; Leap 16.x will take the binaries from there. The sources are made available and anybody is free to resping RPMs rebuilt as -v0 and spin up a medium based on this (similar to the Factory ports - OBS is there to be used) And then there is Tumbleweed that went the route of v0 + hwcaps which is an option for those machines too (I know, bandwidth, too many updates, …) Cheers, Dominique
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 <dimstar@opensuse.org> wrote:
Distrobox is supposed to be used for anything you are 'playing' with, i.e compiling stuff, installing random stuff; that's isolated from the
Perhaps the word 'playing' is not well chosen. For many, the OS install is the 'work' environment. Not a variation on something. Having the ability to set up a variation is good. I already do this for openSUSE via kiwi's ability to make a simple archive of, say, Leap 15.4 that can be unpacked into a directory and chrooted into. No need to make some draconian OS install. I do this to compile and test different openSUSE releases on my Tumbleweed OS. Each one independent of each other and the host OS. -- Roger Oberholtzer
On Wed, Mar 29, 2023 at 9:03 PM Dominique Leuenberger <dimstar@opensuse.org> 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 Thu, Mar 30, cagsm wrote:
On Wed, Mar 29, 2023 at 9:03 PM Dominique Leuenberger <dimstar@opensuse.org> 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?
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. If "Leap 16" contains "traditional", non-transactional variants, it should be possible to migrate to this variants. But since "Leap 16" does not exist yet: this is like looking into a crystal ball. Everybody can only tell you the plans, but not if they become reality. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
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.]
On 2023-03-30 21:11, Jan Engelhardt wrote:
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.]
Jan, Leap users want reliable, supportable systems. If you are volunteering to personally support all the issues that such an approach would cause, and commit to fixing all such issues in a timely manner, and we have sufficient clones of you, then maybe we can consider whether it’s a viable option. Else, Thorstens statement is practically correct even if not technically absolutely correct. -- Richard Brown Linux Distribution Engineer - Early Adopters Team SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
participants (12)
-
cagsm -
Carlos E. R. -
Dominique Leuenberger -
Fritz Hudnut -
Jan Engelhardt -
Knurpht-openSUSE -
Larry Len Rainey -
Martin Schröder -
Richard Brown -
Roger Oberholtzer -
Simon Lees -
Thorsten Kukuk