Hi all,
some time ago we discussed where and how we should share
"Tips&Tricks" for YaST users and developers.
IIRC there was no clear conclusion so I decided to start
a wiki [1] to collect all our tricks we know or use.
For now it's just a place for dumping your ideas, links, short
howtos, etc... When we collect enough data we can probably
split it to several categories or move it somewhere else.
We just need the data first.
I have added there some my tricks from my personal "knowledgebase"
file. If you have better tricks or find something wrong simply
change it, it's a wiki ;-)
Ladislav
[1] https://github.com/yast/yast.github.io/wiki/YaST-Tips-and-Tricks
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all!
I'm implementing some new AutoYaST feature and I found out that it's not easy
to test the AutoYaST functionality.
1. Even for testing a trivial scenario you have to write your own XML file.
If you do not have much experience with AutoYaST you have to read the
documentation, search the internet, etc... Cloning your current system helps
a bit but usually the cloned profile contains too many options so you still need
to polish it a bit...
2. When you have your profile ready you have to host it at some HTTP/FTP/NFS/...
server so AutoYaST can use it for installation. I usually run simple
"ruby -run -ehttpd" command to have a web server quickly, but that's quite
tricky for people not familiar with Ruby.
My idea is to have some repository with example XML profiles which would be
publicly available and ready for instant use. We already have some XML files in the
autoyast-profiles-test Git repository but writing something like
autoyast=https://raw.githubusercontent.com/yast/autoyast-profiles-test/mast…
on boot command line is a real pain. We could use some URL shortening service
but I do not like that much. Shortened URLs do not look nice and it's not
obvious where they point to (security). I'd like to have some nice URLs...
So my proposal is to use the GitHub pages for building an AutoYaST profile
repository. Then you could use
autoyast=https://autoyast.github.io/mini/sles15.xml
or
autoyast=https://autoyast.github.io/mini/leap15.xml
for testing a minimal SLES/Leap profile.
Actually these URLs already work! :-) You can give it a try. Most likely you will
need additional "netsetup=dhcp" boot option for configuring network.
The profiles would be well described (what they do) and well commented (so the users
can easily adapt them to their needs).
The profiles could be automatically validated (via Travis) and it would be nice
to use them also in openQA tests to be sure they really work.
We could also link this repository from the official SUSE documentation.
The proof of concept is available at https://autoyast.github.io, please check it.
It is still just a concept for getting early feedback, there is a lot of work to do.
See the README file in https://github.com/autoyast/autoyast.github.io
What do you think about it?
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
users can do funny things with btrfs qgroups leading to problems:
When a subvolume is created a corresponding level 0 qgroup is
also created by btrfs. The subvolume id and thus the qgroup id
are not predictable (see below). The user can also manually
create level 0 qgroups.
So the user can 1) manually create qgroup 0/260 and 2) create a
subvolume that could get id 260 and the corresponding qgroup gets
the id 0/260. A nice qgroup id collision.
If libstorage-ng would commit such a setup the manually creation
of qgroup 0/260 would fail if it happens after the subvolume
creation. Also the user could set different limits for both
qgroups which is obviously impossible to commit correctly.
I do not see any use-case for level 0 qgroups without a
corresponding subvolume. Our btrfs developers also said that
there is none.
So to avoid such problems with libstorage-ng and YaST I propose
to 1) disallow creating level 0 qgroups without an corresponding
subvolume and 2) ignore level 0 qgroups without a corresponding
subvolume during probing.
Item 2) seems like a good idea anyway since btrfs does not delete
qgroups when deleting subvolumes, so a hugh number (like several
thousands) of useless level 0 qgroups may exist in the system.
Comments?
Why is the subvolume id not predictable? For once it is not just
the next free id: E.g. after deleting all subvolume the ids do
not restart at 257. Likely it is possible by further analysis of
the btrfs to know the next id but that is internal to btrfs. And
finally any other program, e.g. snapper, can concurrently create
subvolumes and thus ruin any attempt to predict the ids.
ciao
Arvin
--
Arvin Schnell, <aschnell(a)suse.com>
Senior Software Engineer, Research & Development
SUSE Software Solutions Germany GmbH
Maxfeldstraße 5
90409 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
The latest YaST Team report comes more varied than usual, including news
about Cockpit and about the openSUSE + LibreOffice Virtual Conference.
But, of course, the bulk of the post is still the new features in the
installer and its ecosystem:
- Unit tests for the installation-images Perl libraries.
- New emergency mechanism to ignore storage probing errors.
- Support in linuxrc to send DHCP requests in RFC2132 format.
Check the whole report at
https://yast.opensuse.org/blog/2020-10-30/sprint-111
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
some brain foor for innovation time. This blog post is quite interesting reading worth a time: https://brandur.org/nanoglyphs/015-ruby-typing#ruby-typing
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org