On 2017-04-19 21:20, L A Walsh wrote:

Carlos E. R. wrote:

...

On 2017-04-19 03:38, L A Walsh wrote:

...

Issue#2: where / how do I change network settings?

I can configure it manually w/ip(link,addr) and can ping my host system, but don't know where to add changes to make that permanent.

YaST?

Will have to try that again ... don't remember seeing an option there, but ....

Yes, YaST does create the network config for you. Since ever. :-) You can say there that you want to use network manager instead, and then you configure the network with the network manager applet in the desktop of your choice.

...

Modules load instantly here, as soon as needed. If they are not loaded, there is some other problem.

---- Well, none of them load -- maybe because it's trying to load them from the initrd and and not the HD? I know they are on the initHD from last time -- but don't know that they are on the initrd.

...

...

I'm running low on energy ...

Are you trying to use your own customizations, or are you leaving everything to designed defaults?

---- I haven't gotten to a point where I could load them, if that was my intention, but I was trying to go "stock" -- with about as successful results as last time I tried this...

Well, the modules should be in initrd if YaST knows at install time that you are using them. Or in this case, LVM.

...

...

This is supposed to be the stable release?

No. It is Tumbleweed, aka Factory. Considerable effort is done at automated testing, but it is not human tested by the community till people install each release, and it changes weekly or even daily, so no, I don't consider it stable.

---- The opensuse.org page says "Fast, integrated, stabilized, & tested.

vs. leap -- the latest regular-release version.

Well, yes. Stabilized it the used word. What it means is that many automated tests are run against the snapshot before release. The effort is big indeed. However, it does not cover all cases, and the release can not have been tested by humans, because after all you get about a release per week.

Factory?! So I should really be directing these questions to the factory list? :-( ???!?

Well, IMHO, yes. Some do not like me saying "Tumbleweed aka Factory", but IMHO it is true. It is not the same as the old Factory, of course. There are differences. But the repos still fave "factory" in directory names. About writing in the factory mail list, some people there do not like user's question there, but on the other hand, Tumbleweed has issues and differences that are not present in Leap.

...

Leap is stable.

--- For a VM, might be ok, but considering how incompatible the regular releases are with priors, I wouldn't call that stable for a machine that needs to just "be up"....

??? I use Leap on my home server. I get uptimes of two months; could be more, but there are several updates that require a reboot. That is worse in Tumbleweed, it is a rolling and bleeding edge release. You really should go with defaults there. Too much fighting against if you don't. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

L A Walsh wrote:

Carlos E. R. wrote:

...

On 2017-04-19 21:20, L A Walsh wrote:

...

Issue#2: where / how do I change network settings? YaST?

They were not saved over a boot.

You're 100% sure? Can't say that has ever happened to me. With a system in that state, I would say start over.

...

...

...

Modules load instantly here, as soon as needed. If they are not loaded, there is some other problem.

There's no way to specify modules needed at boot. They may load instantly if you can specify them...

You can manually add modules to the initrd if dracut doesn't include them automagically. Otherwise add them to /etc/modules-load.d/

...

Well, the modules should be in initrd if YaST knows at install time that you are using them. Or in this case, LVM.

---- I configured it through the LVM settings on the YAST menu, [ how could it not know about them?

Those are not really related - dracut will determine if it needs LVM at boot-up and include the necessary modules. If they're not included, dracut doesn't think they're needed at boot time. -- Per Jessen, Zürich (0.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-20 07:09, L A Walsh wrote:

Carlos E. R. wrote:

...

On 2017-04-19 21:20, L A Walsh wrote:

...

Issue#2: where / how do I change network settings? YaST?

They were not saved over a boot.

Very strange. Never seen that.

...

...

--- For a VM, might be ok, but considering how incompatible the regular releases are with priors, I wouldn't call that stable for a machine that needs to just "be up"....

???

I use Leap on my home server. I get uptimes of two months; could be more, but there are several updates that require a reboot.

---- I count downtime caused by upgrades as down time.

Well, with tumbleweed you get an order of magnitude more updates, at least. Expect to reboot every week, or even more. Daily, perhaps.

...

You really should go with defaults there. Too much fighting against if you don't.

---- So it's an unconfigurable installation process. That's not very useful.

You can configure whatever, but what I know you "configure" from other mails (like not using initrd) is way too much. Specially for tumbleweed, because next update might destroy something. Specially when they design a new paradigm. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Anton Aylward wrote:

If you are "going stock", Linda, then you should be using Dracut to build the initrd.

---- Where is the dracut option in the setup menu?? Is that something setup-users are expected to know? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

"set-up users" being what? Someone running the opensuse install DVD and trying to install an unfamiliar distro for the first time.

People who build and configure kernels are usually system administrator grade or functionaries.

---- Do you need to know how to build or configure a kernel to install opensuse from the installation DVD. Someone who might be looking to replace MS Windows on their computer .... Someone who may have little knowledge about the command line -- or at least one where most things don't work. How much knowledge do people have to have in order to install (setup) open suse from the DVD? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 12:07 PM, Per Jessen wrote:

L A Walsh wrote:

...

Someone who may have little knowledge about the command line -- or at least one where most things don't work.

How much knowledge do people have to have in order to install (setup) open suse from the DVD?

With appropriate hints, I think my 13-year old could do it.

I'm damn sure that Marcus Ranum's cat can do it. After all, he's pointed out that his can can configure a firewall. I don't think installing a vanilla Linux installation is going to be much more difficult. My cat takes no interest in computers. That's the breaks, eh? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-21 15:20, L A Walsh wrote:

Anton Aylward wrote:

...

If you are "going stock", Linda, then you should be using Dracut to build the initrd.

---- Where is the dracut option in the setup menu??

It is the default. If you are doing a standard install from the DVD, you don't have a choice.

Is that something setup-users are expected to know?

No. Assuming you are doing a fresh install from DVD, using YaST, you have no reason to configure dracut; YaST should do all the needed configuration for you. If you are telling the partitioner to do an LVM setup, thin or whatever, YaST should know if dracut has to be told about it. If the system doesn't boot because it lacks some modules in the initrd, then it is a bug and you should report that in Bugzilla, with info enough to reproduce the problem. The procedure for repair would be to boot a rescue system, mount your new system on it (bind mount /proc, /sys, /dev), chroot, edit the modules in /etc/modules-load.d/ as Per mentioned, and then simply run "mkinitrd". That should be all. Then reboot to try. But as I don't use LVM I can't be 100% certain. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 04/21/2017 11:24 AM, Felix Miata wrote:

Why is mkinitrd even installed since the default initrd builder became dracut in 13.2? I wouldn't even be trying mkinitrd absent some instruction for a particular circumstance.

Why? Probably because mkinitrd comes in the dracut package. Maybe that is just to put a neutered mkinitrd in the way, idk. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 02:13 PM, Carlos E. R. wrote:

The procedure for repair would be to boot a rescue system, mount your new system on it (bind mount /proc, /sys, /dev), chroot, edit the modules in /etc/modules-load.d/ as Per mentioned, and then simply run "mkinitrd". That should be all. Then reboot to try.

But as I don't use LVM I can't be 100% certain.

I can and I'd rather you didn't use /etc/modules-load.d/ If you want the booting kernel to activate the LVM LVs then do it in the bootin kernel. That directory above is for after booting As you say, Carlos, dracut is the default of the vanilla install was done from DVD with no buqqering around. If there was a LVM in the initrd (use lsinitrd to look-see) then it will propogate. If not set "lvm" as one of the dracut modules in /etc/dracut.conf under add_dracutmodules+ That's dracut module, NOT a /lib/modules module it is, as I said above, "lvm, so you have add_dracutmodules+="lvm" You may need others too but that takes care of LVM. You may also want to enable dracut logging. q.v. DRACUT.CONF(5) ========================================== All that being said, there is of course /etc/modprobe.d and its contents, which *is* included n the initrd. If you want to tweak /etc/modprobe.d/99-local.conf then you can, but I'd *not* recommend using that to try and activate LVM. The above method using dracut modules not only brings in the .so modules needed, but also brings in the LVM binaries and set's up the udev rules and takes care of the activation that Linda currently has to do manually. Believe me, that works, it works well. I was designed that way. Forget buqqqering around with Yast. Like the Nike people say "Just Do It". I set it up that way back when and it's definitely a 'fire and forget'. No problems with LVM startup in any ways, shape or form since. I'd recommend the same for RAID, Crypto and a lot more. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 19/04/17 03:20 PM, L A Walsh wrote:

Yeah, like none of the lvm modules loading. just booted again .. same thing. no lvm modules are loaded.

I'm not a LVM expert but I've been using them with no problem for .... many years. On my system only /boot and SWAP are on regular parttions. /lib is on a LVM LV, so the basic booted system has to have LVM capability to be able to read and load any more modules. So my initrd *has* to have that module. I forget how I used to do it in years gone by, but these days Dracut makes it easy: I jsut tell it to include "lvm". Now when I run 'lsinitrd' it tells me Version: dracut-037-80.1 Arguments: --logfile --force dracut modules: bash warpclock i18n convertfs ifcfg drm plymouth dm kernel-modules lvm resume rootfs-block terminfo udev-rules biosdevname haveged systemd usrmount base fs-lib shutdown suse and later on -rw-r--r-- 1 root root 58166 Apr 20 08:11 etc/lvm/lvm.conf and -r-xr-xr-x 1 root root 10520 Apr 20 08:12 lib64/device-mapper/libdevmapper-event-lvm2mirror.so -r-xr-xr-x 1 root root 10496 Apr 20 08:12 lib64/device-mapper/libdevmapper-event-lvm2raid.so -r-xr-xr-x 1 root root 10608 Apr 20 08:12 lib64/device-mapper/libdevmapper-event-lvm2snapshot.so -r-xr-xr-x 1 root root 14728 Apr 20 08:12 lib64/device-mapper/libdevmapper-event-lvm2thin.so And I'm sure there's other good stuff in there too. But you don't use the initrd method, do you, Linda. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

L A Walsh wrote:

Example -- the names of the ethernet devices. First it's new names, then it's old names supported again, now it's only new names again.

Yes, the default has changed, but you have always been able to set an option to have the network names you want. Or use YaST to create udev rules for renaming the network devices. The "predictable names" were made the default at some point (13.1 ?), then we reverted to kernel enumeration in Leap (as that was the preference of the SLES customers). I guess in TW it was back to "predictable names" (I don't know), but it's easy to enable plain kernel enumeration here too.

...

and so probably not tested either. Standard volume types do not require extra modules beyond dm-mod and dm-mod is loaded (although my guess is that it is loaded due to /dev/mapper/control device alias).---

None beyond dm-mod?? No one uses snapshots, RAID or disk encryption? Those are all dm-modules in the 'md' directory. Seems a bit odd to say most of the dm functions wouldn't be supported.

There used to be a file in /etc/sysconfig where I could tell it to load modules, seems that's gone too. Wonderful...

/etc/modules-load.d/ -- Per Jessen, Zürich (0.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov wrote:

On Thu, Apr 20, 2017 at 8:04 AM, L A Walsh wrote:

...

Andrei Borzenkov wrote:

...

19.04.2017 04:38, L A Walsh пишет: Why do you expect them to autoload? Most needed modules autoload as I use them on my sysV system that boots from the hard disk.

I almost hit DEL ... yet again you start blaming systemd for every dead kitten.

Woe woe woe... 1) When have I ever blamed anything on sysd? I've never run it, so how can I ever have blamed anything on it? 2) I didn't mention sysd. I only said that most modules autoload as needed on my sysv system that boots from the hard disk.

To make myself clear - your question sounded like you *know* that there is mechanism to autoload DM modules and this mechanism stopped working.

But its true that most of my modules are loaded automatically. I just rebooted my main system. By the time I was able to log in and run "lsmod", 43 modules had loaded -- including a module for dm-thin.

I myself am not aware of this from kernel side, so I do not see why you expect *autoload*.

It very likely isn't the kernel but something in the way the system is started and/or the fact that all of the modules are available to load as soon as the root file system is mounted. I.e. I don't have to worry about whether or not something was on an initrd or not.

That something loaded it in the past for you (or that you probably used your own monolithic kernel that did not need modules) does not mean it was *autoloaded*.

---- You must be thinking of someone else. I don't have a monolithic kernel, to the contrary, the suse kernel is about 50% larger than mine (9M vs. 6M). As far as modules go, I have 539 dynamic modules that are loadable as the system comes up and later, as needed. So far, you've confused me with someone who's run sysd, and someone who has a monolithic kernel, when neither are even remotely true. ---- The real problem, so far has been my using thinpools, which *are* supported in YaST, but are broken. FWIW, if I mod-probe the dm-thinpool module, the 'vgchange -a y' installs all of the devices needed for thinpool device.

Yeah, I must have been confused or did not look there carefully for a long time. Sorry. Indeed, YaST offers thin pool - which makes this issue topic of bug report. I am not sure what component though - it is not exactly kernel bug as far as I can tell (it could be considered missing feature) so options are to either load modules from DM library or statically configure them for loading by YaST when thin pool is created. Given that currently even simple "lvcreate -T" fails, I'd vote for the former.

lvcreate -T fails? Worked for me (w/the modules loaded). I don't like sysd because it leaves me with a non-bootable system. You can't claim that's unfair when its the truth. As for your other remarks, you have to be thinking of someone else, as neither of your comments _could_ apply to me. I still am not sure how to keep my VM "up", since I'm not sure how to pre-load the needed modules for LVM, (putting modules in /etc/modules-load.d/ as some suggest doesn't work). I did figure out howto mount my main system's root disk, so as a last resort, I can always download a working boot from it, but I really wanted to setup a server VM without my own custom solutions.... *cheers*, and don't start hitting 'DELETE' until you are sure you've got the right person.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov wrote:

...

I still am not sure how to keep my VM "up", since I'm not sure how to pre-load the needed modules for LVM, (putting modules in /etc/modules-load.d/ as some suggest doesn't work).

It does. I just tested it.

Are we talking about the same thing? I copied the needed dm-xxx.ko modules out of /lib/modules/<subdir>. into the already-existing /etc/modules-load.d/ dir. It really did not work. None of those modules were loaded. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

man modules-load.d

not found -- at the place it died, there are no manpages available.

systemd-modules-load.service(8) reads files from the above directories which contain kernel modules to load during boot in a static list. Each configuration file is named in the style of /etc/modules-load.d/program.conf.

The configuration files should simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is # or ; are ignored

I see...maybe I'll try that next. Sorry, but that wasn't clear. Thanks for clearing that up. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 12:25 PM, Per Jessen wrote:

L A Walsh wrote:

...

Per Jessen wrote:

...

man modules-load.d

---

not found -- at the place it died, there are no manpages available.

...

systemd-modules-load.service(8) reads files from the above directories which contain kernel modules to load during boot in a static list. Each configuration file is named in the style of /etc/modules-load.d/program.conf.

The configuration files should simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is # or ; are ignored

I see...maybe I'll try that next. Sorry, but that wasn't clear. Thanks for clearing that up.

No problem - when you didn't know about modules-load.d, it's an honest mistake to make.

Let's clarify this: It loads a kernel module. It *ONLY* loads a kernel modules. In the case of LVM it does not * load any of the LVM config files * any of the user level LVM libraries or binaries * any of the UDEV rules pertaining to LVM or LVM initialization * any of the scripts that are needed to support any of the above * does not start lvmetad * does not run 'pvscan -a' It is NOT, repeat NOT a solution to the issue that Linda was raising. Using a properly configured Dracut to build the custom kernel/initrd after a successful vanilla installation is the way to go. Get a baseline system running first. The after you've proven a baseline system is runnable, bootable, start modifying it .... .... one thing at a time ... Why "one thing at a time"? Its about entropy: its about reversibility. Keep the previous kernel, make one change, one step. If the step fails, you can go back to something that works. Keep records of the changes you make, along with why you made them, what objectives you were trying to achieve. It's this all obvious? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 03:18 PM, Andrei Borzenkov wrote:

21.04.2017 22:03, Anton Aylward пишет:

...

On 21/04/17 12:25 PM, Per Jessen wrote:

...

L A Walsh wrote:

...

Per Jessen wrote:

...

man modules-load.d

---

not found -- at the place it died, there are no manpages available.

...

systemd-modules-load.service(8) reads files from the above directories which contain kernel modules to load during boot in a static list. Each configuration file is named in the style of /etc/modules-load.d/program.conf.

The configuration files should simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is # or ; are ignored

I see...maybe I'll try that next. Sorry, but that wasn't clear. Thanks for clearing that up.

No problem - when you didn't know about modules-load.d, it's an honest mistake to make.

Let's clarify this: It loads a kernel module. It *ONLY* loads a kernel modules.

In the case of LVM it does not

* load any of the LVM config files * any of the user level LVM libraries or binaries * any of the UDEV rules pertaining to LVM or LVM initialization * any of the scripts that are needed to support any of the above * does not start lvmetad * does not run 'pvscan -a'

It is NOT, repeat NOT a solution to the issue that Linda was raising.

It is exactly the solution to this issue.

I presume that you had not read my drill down where I determined that Linda was correct in that she saw it to be a bug in YaST. it has nothing whatsoever to do with /etc/modules-load.d. Nothing whatsoever. YaST, the isntaller, does know about LVM. If Linda did a plain install with LVM, nothing fancy, no thin pool at install, just as many of us have done, she would have to a basic working system. YaST knows about LVM. The basic install sets up systemd modules that take care of the modules. As I pointed out, dracut build with the LVM dracut module brings in the relevant parts of /sbin and /lib65 and /usr/lib/modules/ for the specific kernel and puts them in the initrd so that the LVM can start up. There is no need for any entry in /etc/load-modules And, as I pointed out in the above bullet list, merely putting an entry in there does not do the other things necessary to have a functioning LVM. However putting the dracut LVM module, which is a completely different thing altogether, q.v. the man pages, does ensure all the other parts are there in the initrd and that they get executed; all the items on my above bullet list are satisfied. Other people have also pointed out that they have a functioning LVM system without an entry in /etc/load-modules. The only way you'll need that is if you did not set up your initrd and systemd to initialise LVM. Even so, the items on my bullet list still need to be satisfied. Some of them will be if you install the relevant RPMs, but not all. Some need to be executed at run-time to set up a *PROPERLY* functioning LVM environment, and merely having an entry in /etc/load-modules does not do that. There is a bug in the installer, in YaST. As I pointed out in separate post, the code for generating a thin pool has a bug in it. This bug is active even in a properly installed LVM, one that boots an otherwise fully functional, robust LVM based system. Having or not having an entry in /etc/load-modules makes no difference. Linda was correct, the bug is in YaST. She just didbn't drill down the way I did to determine what it was, inspect the logs, where it is reported quite celarly. Here, once again, is the bug: **************** LVM_LV_CREATE_FAILED System error code was: -4014 /sbin/lvcreate --zero=y --yes -V 2097512k --name 'vpool1' --thin 'VGMain/LVPool': --zero is supported only with thin pool creation Run 'lvcreate --help' for more information ***************** Please note that this is a YaST bug. When I try creating the 'thin' LVM to use the pool by hand, at the CLI, omitting that "--zero=y", it works just fine. Here's the irony. Its done in the low-level cod in /usr/lib64/libstorage.o If you look in https://github.com/openSUSE/libstorage specifically in https://github.com/openSUSE/libstorage/blob/master/package/libstorage.change... you'll see this bug has been fixed: ======================================================================= Mon Feb 13 11:39:52 CET 2017 - aschnell@suse.com - omit option --zero for lvcreate when creating thin provisioned volumes (bsc#968346) - 2.26.12 ========================================================================= That notice of document for the changes in Tumbleweed for February, if anybody bothered to read it: http://mirror.datto.com/opensuse/tumbleweed/iso/Changes.20170216.txt -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 05:43 PM, Carlos E. R. wrote:

On 2017-04-21 21:03, Anton Aylward wrote:

...

On 21/04/17 12:25 PM, Per Jessen wrote:

...

L A Walsh wrote:

...

...

...

I see...maybe I'll try that next. Sorry, but that wasn't clear. Thanks for clearing that up.

No problem - when you didn't know about modules-load.d, it's an honest mistake to make.

Let's clarify this: It loads a kernel module. It *ONLY* loads a kernel modules.

In the case of LVM it does not

* load any of the LVM config files * any of the user level LVM libraries or binaries * any of the UDEV rules pertaining to LVM or LVM initialization * any of the scripts that are needed to support any of the above * does not start lvmetad * does not run 'pvscan -a'

It is NOT, repeat NOT a solution to the issue that Linda was raising. Using a properly configured Dracut to build the custom kernel/initrd after a successful vanilla installation is the way to go. Get a baseline system running first. The after you've proven a baseline system is runnable, bootable, start modifying it ....

No no.

On a freshly installed system, using YaST to do the installation, where YaST knows that it is installed on LVM and how exactly, the user can not configure dracut at all before it boots once. And configuring dracut is incorrect. YaST must provide a system that boots the first time after installation, it must do the correct dracut configuration itself.

If the dracut configuration is incorrect, that is a bug of the installation system.

We're talking at cross purposes. I agree, you cannot tweak dracut when doing the initial install. i'm not asking you to. I'm also not asking you to get exactly what you want at the "Omega Point" during the install. I *am* saying that you should do a basic install. A basic install lets you use the disk configurator, in expert mode, create a basic LVM setup. Yes, it helps if before you start the DVD install you used a LiveCD to run a fdisk to create the LVM partition. I've done that, along with a SWAP and /boot partition, as I'm sure I've mentioned a number of times before. The the expert mode configurator for a LVM RootFS, /home, /var/ and anything else you want. Keep it "real" at this point. That all works. It worked for a number of releases now. I did it a few weeks ago for 42.1; I see no reason why it won't work with 42.2. I'm sure if it doesn't we'd have seen more mention. AT THIS POINT FORGET ABOUT THIN & POOL. If that basic install without any buqqqering around doesn't work then you have deeper problems. If you're not willing to establish that a very basic install like that works then you have an existential problem that has little to do with any shortcomings that the installer may or may not have. Having done a basic install you should be able to a basic boot. Maybe you chose not to install the X system and a DM/GUI. But either way, you can still alt-F-key and get a text mode login as toot. At this point there are many How-To pages (I like the ones for Arc) on how to set up Thin Provisioning using LVM from the comand line. If you can't get a basic not fancy stuff system installed using the expert mode disk partition configuration for LVM, ignoring anything about "Thin", then say so. Right now I'm confused because there seem to be contradictory messages. I'm confused, for example, when you say "Yast to do the installation". You are saying that Yast === the installer? As far as I can tell the installed "dracut" config has no overrides. As far as I can tell all the 'options' in /etc/dracut.conf are commented out. They were when I first installed and they still are, because I have, as suggested by the notes therein, made my modification by adding to /etc/dracut.config.d/ As far as I can tell the installer make use of a kernel that is overloaded but has smarts enough to some runtime detection. Heck we have the same thing when X starts, don't we. There's nothing to stop you doing customization. I know because the customization I've done in /etc/dracut.conf.d/ not only gives me logs but has also shrunk the size of my initrd by somewhere between 20% and 30%. I've also disable the "os-probe" part so that all my old RootFS, experiments with BtrFS for example, don't get menu entries in grub when mkinitrd calls grub2-mkconfig. So if all the entries in a vanilla install /etc/dracut.conf are still commented out and there's nothing in a vanilla /etc/dracut.conf/d, then what the <*-BLEEP-*> are you talking about when you say that the 'installer === yast" is configuring dracut? As far as I can tell one of two things must be happening. Scenario A) When the installer sets up LVM it makes a note to activate the systemd modules that are pertinent. It makes note to add the string "lvm" to the command line it is generating when it runs dracut. <sidebar>If you're not clear about that please read the man page for dracut. Please be aware that a lot of what the installer does is fork of shells that do various bits of the work for it when you finally commit to the install. </sidebar> Scenario B) The kernel as supplied on the DVD is like the Windows kernel and has a code path and load library that is a 'database' of all the various options. That is why it is so large. Personally I favour "A". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 08:13 PM, Carlos E. R. wrote:

...

I *am* saying that you should do a basic install. A basic install lets you use the disk configurator, in expert mode, create a basic LVM setup. Well, but YaST does allow you to do that kind of complex setup during initial installation. If it does not work and you have to do a basic LVM install, then there is a bug in YaST

(YaST is the program that does the initial install, I believe)

I'm not sure that YaST === Installer (I am using '===' in the JavaScript sense of "Two objects are strictly equal if they refer to the same Object") More to the point, there is a log generated and I'm pretty sure that in that log one can find the commands that the installer generates, the scripts it runs and more, and so determine better what is actually going on "under the hood". If there is a bug then it should be visible there one way or another. Now, if I were in this situation I would carry out an A-B test. I would, as I say, do a basic LVM install on a system, and then with logging turned all the way up try on a clean baseline install each time: A) configure a Thin Provisioned LVM partition in addition to the existing LVM partitions using the CLI. Test same. B) configure a Thin Provisioned LVM partition in addition to the existing LVM partitions using YaST. Test same. At the very least, (B) will determine if there is capability in YaST to do this. I've never tried it. When I've experimented on a just-to-see-if-it-works basis I used the CLI so I could see what was going on. ============================ Well that's interesting. I just tried (B) albeit on a "mature" LVM system. I created the pool "master" LV OK, but the "thin" errored. **************** LVM_LV_CREATE_FAILED System error code was: -4014 /sbin/lvcreate --zero=y --yes -V 2097512k --name 'vpool1' --thin 'VGMain/LVPool': --zero is supported only with thin pool creation Run 'lvcreate --help' for more information ***************** Well that's an interesting error. "--zero is only supported with thin pool creation" but this is creating one. Neither the man page nor the "--help" discusses that restriction. All the CLI example web pages I see never mention it. When I experimented at the CLI level I never used it. I can imagine creating a LVPool with --zero=y but not each of the thin vpoolN So I don't think the error is in YaST, per se but in the GUI programmer of YaST who put a particular interpretation of the "lvcreate" command. Or possibly the bug is in the 'lvcreate' or the 'lvcreate' documentation that fails to adequately explain the usage of "--zero" in terms of what context it should be and not be used. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 10:55 AM, Per Jessen wrote:

man modules-load.d

systemd-modules-load.service(8) reads files from the above directories which contain kernel modules to load during boot in a static list. Each configuration file is named in the style of /etc/modules-load.d/program.conf.

The configuration files should simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is # or ; are ignored

I should mention that I've always run LVM without any of this. On all my systems that have ever run systemd that directory has been empty. Except for /boot and SWAP, all my file systems are under LVM. Yes, I have had a setup with /boot as part of RootFS and RootFS on the LVM. I've also had a setup with a separate /boot that on the LVM. The issue is to have LVM capability in the initrd. That includes the part that does the "lvscan -a" -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/04/17 04:06 PM, L A Walsh wrote:

FWIW, if I mod-probe the dm-thinpool module, the 'vgchange -a y' installs all of the devices needed for thinpool device.

Well, what a coincidence! I don't use thin pools but I use exactly that command to set up the device mapper 'mappings' in /dev for the LVM facilities that I do make use of. Only I don't do it from the command line. Such things are taken care of by scripts. I'm sure that in the SysVInit days there was a /etc/init.d script that did it. These days there's a 'Start=' in lvm2-monitor.service that does it You may also find that there are udev rules that are pertinent to dm-mod LVM setup included in the initrd. Or need to be there. Look for usr/lib/udev/rules.d/*dm-* when you run lsinitrd -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 20/04/17 04:06 PM, L A Walsh wrote:

...

I don't like sysd because it leaves me with a non-bootable system. You can't claim that's unfair when its the truth.

It may be the truth but then again it may be an emergent property from other decisions you have made that have painted you into this cul-de-sac.

--- Yes... I attempted to install only using the provided setup options on the DVD. No custom options. Silly me -- relying on the standard install DVD to setup a system.

...

As for your other remarks, you have to be thinking of someone else, as neither of your comments _could_ apply to me.

It seems that non of our suggestions, (putting modules in /etc/modules-load.d/ is one example) don't work for the context you have set yourself up in.

---- Yeah, the context of trying to

What it boils down to, Linda, is that the context you have set yourself up in is far enough removed form the one9s) the rest of us are running that what works for the rest of us, works well for us, works quite easily for the rest of of us, don't work for you.

--- What it boils down to is that there is a bug in yast. There is no single context for "the rest of us"... You are deluded if you think everyone is just like you.

Many of us work to shrink out initrd and make systems load faster and all that.

--- I did that too on my main system. Shrunk it to size=0. It boots in about 10-15 seconds (not an SSD).

I look at the output of my 'lsinitrd' and I'm sure I could strip more out, male sysd do more in parallel.

Ah... you are stripping your male sysd? Anton, I'm not sure I want to know about this. As for doing an lsinitrd -- normally mine is empty, but was trying to use a more standard setup supported by yast, but it has a bug that prevents it from working.

Perhaps I could defer mounting some partitions until services or user login needed them? Hmm that probably wouldn't speed things up much, the criticality is establishing a network connection.

But that plymouth, that splashy stuff? How to get rid of it? Is adding it as an "omit" in /etc/dracut.conf the right way?

--- ??? on a text mode console?

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/21/2017 1:18 PM, Anton Aylward wrote:

The gulf isn't 'just like me', the gulf is between Linda and 'the rest of us'.

But the majority are wrong and Linda is right, like, 99 44/100ths of the time. Every time she mentions some system config choice that she has set up differently, it's always for a perfectly and demonstrably sensible reason. It's always something that no one has any right to suggest to someone else they should not do or that it's wrong, even by the weak standard of popularity. But, as she just said, in this case, she tried to use the bog standard official install dvd. I think people just don't like hearing that all isn't well. Too bad. All is not well. What's especially not well is that it's self-inflicted (you know, that property you presumably don't approve of, since you just accused her of it as the source of her problems and therefore not your problem). When things are simply technically difficult and the sensible approaches haven't been figured out yet, those are honest problems that we all just plug away at and make better. But we now have problems that are the result of ignoring/forgetting/disacrding things that have been figured out a long time ago. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/24/2017 8:29 AM, Anton Aylward wrote:

I rarely use YaST. Things like this do not encourage me to use YaST.

You mean, you use the system in some non-standard way? So, your deviant choices are ok, but hers are not? -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/24/2017 11:26 AM, Wols Lists wrote:

On 24/04/17 16:07, Brian K. White wrote:

...

On 4/24/2017 8:29 AM, Anton Aylward wrote:

...

I rarely use YaST. Things like this do not encourage me to use YaST.

You mean, you use the system in some non-standard way?

You mean, like, a simple linux dual boot?

...

So, your deviant choices are ok, but hers are not?

The problem is, Yast (and so many other automagic tools) are optimised/tested for the simple, basic case. As soon as you try to do anything beyond that, you end up fighting the tool.

Correct. That is precisely her (and mine for that matter) perpetual observation of the entire distro since the mid 11.x days. Or even 10.x days. But when a problem is pointed out, all we get are dismissive jokes about "dead kittens", instead of actually addressing the problem that was pointed out, if the cause of the problem is one of the darling new hotness projects everyone must love or else be spit on as stupid old dummies who clearly are just befuddled by all this new fangled stuff and just can't figure it out and just don't like change. One wonders how they ever found themselves in sysadmin and developer and CTO positions. Must be nepotism or something. Only possible explaination why anyone could possibly say anything bad about systemd, plymouth, graphical grub, kernel drm, dracut, huge initrds with X in them, dbus, pulseaudio... None of them have any invalid core precepts, merely ordinary technical blemishes to be ironed out by *helpful* *constructive* people who don't go around saying awful things like "Uh, this is fundamentally a bad idea. There is no right way to do a bad idea..." ;) -- bkw -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-24 17:07, Brian K. White wrote:

On 4/24/2017 8:29 AM, Anton Aylward wrote:

...

I rarely use YaST. Things like this do not encourage me to use YaST.

You mean, you use the system in some non-standard way?

So, your deviant choices are ok, but hers are not?

You can have a standard suse style system without using yast :-) What she does on her main system is drastic. No initrd, for starters; she loads at boot time from "/" instead. This takes a lot of effort, imho, but has advantages she wants. We simply have to be aware when she report a problem of the differences, to know if they could affect. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Carlos E. R. wrote:

We simply have to be aware when she report a problem of the differences, to know if they could affect.

--- Baka! Why would I be having a problem running the standard install DVD if it had anything to do w/my main system? I even mentioned I had no network and that I was setting up the HD from scratch. I was trying to setup a VM... as I said -- using "low touch" (on my part)... So your argument is specious at best, FUD, more likely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

The thinpool bug that Linda encountered when installing using YaST is a bug that persisted for along time, it existed all the way back to 10.something when libstorage was first written.

Thin pool was not in anything before 13.2, so the fact that it doesn't load dm-thinpool can't have been a problem before that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 25/04/17 03:13 PM, L A Walsh wrote:

Anton Aylward wrote:

...

The thinpool bug that Linda encountered when installing using YaST is a bug that persisted for along time, it existed all the way back to 10.something when libstorage was first written.

Thin pool was not in anything before 13.2, so the fact that it doesn't load dm-thinpool can't have been a problem before that.

That may be a reason why you are suffering !FAIL! dm-thinpool is used, as far as I can determine, by the dmsetup to creating and managing thin pools under mapper managed devices, created by, of course, dmsetup. This is part of the device-mapper package, low level logical volume management. Think of it as the "assembly code" of LVM. How often do you use assembly code when you have BASH, Perl, Ruby (and of course YaST). let's face it. even when you need low-level byte tweaking you probably use C and a compiler. I'm not saying that you can't set up and manage thin pools using dmsetup but given the higher level LVM commands that do so much more in one command or the patched libstorage6 that lets you do it all from YaST, why would you want to do the low level stuff? It requires a lot and leaves you open to errors of typos or errors of lack of understanding. Read LVMTHIN(7) for a specific How-To. You should not need to load 'dm_thinpool' manually or set it explicitly in /etc/load-modules unless you are doing this all by low-level means. The same goes for the basic 'dm-mod' that is required for device-mapper 'mapping' in the first place. On my system this is all set up with lvmetad started by systemd using the UDEV rules. q.v. /usr/lib/udev/rules.d/10-dm.rules /usr/lib/udev/rules.d/95-dm-notify.rules /usr/lib/udev/rules.d/11-dm-lvm.rules As for 'not anything before 13.2' - I'll leave that canard for others. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 25/04/17 04:25 AM, L A Walsh wrote:

Anton Aylward wrote:

...

There a lot of customization options if you are willing to explore and experiment.

More to the point, if you do a 'standard' install from the DVD you'll have a system on which you have a non-zero initrd, can run lsinitrd, can customise the dracut config for when you rebuild the kernel ...

---- I didn't want to customize things. I just wanted a working system to come up and go from there.

I've admitted that I find many of your posts confusing, and I'll admit maybe I'm confused here too, but this isn't what I'm concluding. You want to use YaST to configure system but you also wan to do thin pool stuff. I don't call that 'standard. As far as I'm concerned a 'basic working system' is minimalist. Once you have that working you add, using other SPECIFIC tools for that purpose - not necessary YaST, the features and facilities you want. Doing this, as I have done, at the command line, rather than the "hidden mechanism" of YaST, does require more understanding but then offers a higher degree of confidence. Perhaps, Linda, you're so used to building a highly customized system under other circumstances that you are, in this case, unwittingly complicating this basic install. I don't know. I'm not looking over your shoulder, noting your every keystroke and mouse gesture. I can only hypothesise based on what you report and what you're reporting is that it doesn't work for you. It, being a basic install, works for others. I don't know what you're doing wrong. Maybe you doing it right and there's something else, some precursor, something extra that makes it different in your case. I don't now: perhaps you have a psychic DVD that 'knows' you hate "sysd" and hence refuses to work for you. I'm sad to say that I know people who might actually believe that a possibility :-(

That 10-15s includes mounting of LVM-based volumes of about about 20-30TB of storage. All of it is 'rotating rust' as you phrase it, w/99% of it being 7.2K SATA's.

Unless it's a single FS that is being FSCK'd and square-law applies then the issue is the number of (sequential) FSCKs being done. If those are RAID/stripe LVs/FSs then that's just going to speed FSCKs up. Mounting without FSCK is going to be a LOT faster. I've set up my systemd mounts to be pedantic about FSCK and settling on every boot. Since my booting is done in parallel with my getting a cup of coffee (see joke about the fighter jock and the transport pilot) I'm not concerned bout shaving seconds. Perhaps if I was bringing up a Google-sized farm it would be different...

I've never tweaked or built an initrd. It's not something I've ever really needed.

Yes, I understand that. You've never used the initrd method. But if you're doing a regular install from the DVD then you're ending up with a initrd method system. I think the problem you're having is that somewhere along the line you're fighting it, or doing things that are "common sense" to you in the context of the initrd-lessles system that you are familiar with but are not in this different context. Just a guess. As I say, I'm not looking over your shoulder watching every keystroke and mouse gesture. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 05:37 PM, Carlos E. R. wrote:

On 2017-04-21 16:27, Anton Aylward wrote:

...

What it boils down to, Linda, is that the context you have set yourself up in is far enough removed from the ones the rest of us are running that what works for the rest of us, works well for us, works quite easily for the rest of of us, don't work for you.

No, Anton, this time she is not using those customizations. It is a standard install, and doesn't work.

I'm puzzled. She's still talking of her initrd that is zero in size. She's also clearly not doing a standard vanilla installation since she's complaining that yast isn't allowing her to install in the custom fashion she wants. So what *IS* going on? Or is she doing two things and confusing the reporting of them, somehow conflating the reporting? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 07:07 PM, Carlos E. R. wrote:

No. You confuse when she talks of the main install, her traditional method, and the new install, of tumbleweed, made the standard way. With initrd and all.

Yes. Its so inter-twined I'm not clear what is which and what she has actually done. Maybe I'm a old mathematical fogie but I like to see things clearly laid out stepwise. I realise that it asking too much for it to be colour-coded ... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 21/04/17 05:39 PM, Carlos E. R. wrote:

On 2017-04-21 16:27, Anton Aylward wrote:

...

But that plymouth, that splashy stuff? How to get rid of it? Is adding it as an "omit" in /etc/dracut.conf the right way?

Just remove its rpm and run mkinitrd

One or all? # rpm -qa | grep splash splashy-branding-openSUSE-0.3.13-51.3.x86_64 ksplash-qml-branding-openSUSE-42.1-6.1.noarch splashy-0.3.13-51.3.x86_64 libply-splash-graphics2-0.9.0-8.1.x86_64 splashy-mkinitrd-0.3.13-51.3.x86_64 ksplashx-branding-openSUSE-42.1-6.1.noarch libply-splash-core2-0.9.0-8.1.x86_64 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-22 01:10, Felix Miata wrote:

Anton Aylward composed on 2017-04-21 18:54 (UTC-0400):

...

Carlos E. R. wrote:

...

...

Just remove its rpm and run mkinitrd

...

One or all?

...

# rpm -qa | grep splash splashy-branding-openSUSE-0.3.13-51.3.x86_64 ksplash-qml-branding-openSUSE-42.1-6.1.noarch splashy-0.3.13-51.3.x86_64 libply-splash-graphics2-0.9.0-8.1.x86_64 splashy-mkinitrd-0.3.13-51.3.x86_64 ksplashx-branding-openSUSE-42.1-6.1.noarch libply-splash-core2-0.9.0-8.1.x86_64

All my openSUSE installations are like so:

# rpm -qa | egrep 'plash|mouth' #

cer@Telcontar:~> rpm -qa | egrep 'plash|mouth' ksplash-qml-branding-openSUSE-42.1-8.1.noarch xfce4-splash-branding-openSUSE-42.1-8.4.noarch splashy-mkinitrd-0.3.13-52.4.x86_64 splashy-0.3.13-52.4.x86_64 libloudmouth-1-0-1.4.3-25.4.x86_64 ksplashx-branding-openSUSE-42.1-8.1.noarch splashy-branding-openSUSE-0.3.13-52.4.x86_64 cer@Telcontar:~> But simply removing plymouth is enough to stop it. And run mkinird afterwards, of course. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-04-22 01:31, Felix Miata wrote:

Carlos E. R. composed on 2017-04-22 01:20 (UTC+0200):

...

Felix Miata wrote:

...

...

All my openSUSE installations are like so:

# rpm -qa | egrep 'plash|mouth' #

...

cer@Telcontar:~> rpm -qa | egrep 'plash|mouth' ksplash-qml-branding-openSUSE-42.1-8.1.noarch xfce4-splash-branding-openSUSE-42.1-8.4.noarch splashy-mkinitrd-0.3.13-52.4.x86_64 splashy-0.3.13-52.4.x86_64 libloudmouth-1-0-1.4.3-25.4.x86_64 ksplashx-branding-openSUSE-42.1-8.1.noarch splashy-branding-openSUSE-0.3.13-52.4.x86_64 cer@Telcontar:~>

...

But simply removing plymouth is enough to stop it. And run mkinird afterwards, of course.

And continue consuming space and updates bandwidth for what benefit?

Somethings can not be removed easily, because of dependencies. I have not studied what the implications of those "splash" things are. The only one that is bad, as far as I know, is plymouth. About bandwidth, I no longer care :-p -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-04-22 06:35, Felix Miata wrote:

Carlos E. R. composed on 2017-04-22 01:42 (UTC+0200):

...

Felix Miata wrote:

...

...

Carlos E. R. composed on 2017-04-22 01:20 (UTC+0200):

...

...

...

But simply removing plymouth is enough to stop it. And run mkinird afterwards, of course.

...

...

And continue consuming space and updates bandwidth for what benefit?

...

Somethings can not be removed easily, because of dependencies.

Not all dependencies are legitimate:

# grep RETT /etc/os-release PRETTY_NAME="openSUSE Leap 42.2" # rpm -qa | grep release-notes # zypper in release-notes-openSUSE Loading repository data... Reading installed packages... Resolving package dependencies...

Problem: release-notes-openSUSE-42.2.20161212-3.1.noarch requires google-opensans-fonts, but this requirement cannot be provided uninstallable providers: google-opensans-fonts-1.0-12.2.noarch[OSS] Solution 1: remove lock to allow installation of google-opensans-fonts-1.0-12.2.noarch[OSS] Solution 2: do not install release-notes-openSUSE-42.2.20161212-3.1.noarch Solution 3: break release-notes-openSUSE-42.2.20161212-3.1.noarch by ignoring some of its dependencies

release-notes-openSUSE works just fine (does not "break") using the many other installed-by-default fonts: adobe-source*pro.fonts, dejavu-fonts, google-droid-fonts, google-noto-fonts, google-roboto-fonts, noto-sans-fonts, stix-fonts, liberation-fonts and others.

I remember reading an explanation about this one, but I don't remember the reason. I'll try a grep in mail list. Yes, found: Date: Mon, 8 Aug 2016 11:06:39 +0200 (CEST) From: Johannes Meixner To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] testing leap422a3 - minimum text-only - fonts being installed? Hello, On Aug 8 09:34 Per Jessen wrote (excerpt):

dejavu-fonts, cantarell-fonts and google-opensans-fonts seem to required by release-notes-openSUSE.

Cf. https://lists.opensuse.org/opensuse-packaging/2015-04/msg00070.html FYI: regarding "rpm -q --whatrequires" versus "rpm -e --test" see https://lists.opensuse.org/opensuse-de/2011-11/msg00076.html Kind Regards Johannes Meixner And the reason in that link was:

The use of Open Sans Fonts would be consistent with the openSUSE branding guidelines... http://opensuse.github.io/branding-guidelines/

Maybe the html version of the release notes is going in that direction?

Right, the HTML version needs the font. BTW, all openSUSE documentations needs this font. So removing it is a bad Idea. ;)

...

I have not studied what the implications of those "splash" things are. The only one that is bad, as far as I know, is plymouth.

...

About bandwidth, I no longer care :-p

Somebody has to pay for the servers that provide them to you at no charge. Wasting is wasting no matter who pays or the size of the waste.

-- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-04-22 21:30, Felix Miata wrote:

Carlos E. R. composed on 2017-04-22 19:11 (UTC+0200):

...

or entirely the CSS suggestions. Any portion of any kind of branding flowing through CSS cannot be guaranteed, including that through images loaded via CSS rather than JS or HTML. Thus, google-opensans-fonts cannot be a legitimate hard requirement, and should be suggested or recommended only.

I understand.

In https://lists.opensuse.org/opensuse-packaging/2015-04/msg00076.html I was asked to file a bug about this by Rick Salevsky, which I did: https://bugzilla.opensuse.org/show_bug.cgi?id=926792 It remains IN_PROGRESS with no discussion or action other than Rick taking the bug's assignment.

Oops. I did not read the thread to the end. Ping the bugzilla? And that thread?

I find google-opensans inferior to the other installed by default fonts, and do not ever want to see it on my own systems. It's much easier to remove the package than it is to figure out the fontconfig configuration rat's nest to substitute something else whenever CSS calls it. I install release-notes-openSUSE "broken" and it works peachy with Noto or Roboto or Liberation or whatever the installed by default CSS fallback suggestion is.

Unfortunately, doing so makes YaST nags the admin every time about brokenness :-( There are too many fonts installed. I would like to see only a few in Libre Office, those that I may use. But I can not remove them, breaks deps. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-04-23 05:51, Felix Miata wrote:

Carlos E. R. composed on 2017-04-23 00:09 (UTC+0200):

...

Felix Miata wrote:

...

...

In https://lists.opensuse.org/opensuse-packaging/2015-04/msg00076.html I was asked to file a bug about this by Rick Salevsky, which I did: https://bugzilla.opensuse.org/show_bug.cgi?id=926792 It remains IN_PROGRESS with no discussion or action other than Rick taking the bug's assignment.

...

Oops. I did not read the thread to the end.

...

Ping the bugzilla? For me to do that would be pointless. Interest must show from other than the reporter for anything to happen.

No, it is not pointless. The asignee may have forgotten. And the explanation you posted here in this thread is much better than the brief one you posted on the bugzilla. I understood the issue in this thread, better than in the other thread or the bugzilla.

...

And that thread?

Two years old?

Why not? Anyway, you forgot to post a link to the bugzilla. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 22/04/2017 21:30, Felix Miata wrote:

It remains IN_PROGRESS with no discussion or action other than Rick taking the bug's assignment.

Reset the bug to NEW a two weekly reminder is sent to the assignee for a NEW bug. If it's IN_PROGRESS the reminder doesn't get sent. Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-22 01:43, Anton Aylward wrote:

On 21/04/17 07:10 PM, Felix Miata wrote:

...

All my openSUSE installations are like so:

# rpm -qa | egrep 'plash|mouth' #

Good for you. Bad for me :-(

# zypper rm $(rpm -qa | egrep 'plash|mouth') Loading repository data... Reading installed packages... Resolving package dependencies...

The following 17 packages are going to be REMOVED: amarok amarok-lang kdebase4-workspace-branding-openSUSE ksplash-qml-branding-openSUSE ksplashx-branding-openSUSE kwin libloudmouth-1-0 libply-splash-core2 libply-splash-graphics2 plymouth plymouth-branding-openSUSE plymouth-dracut plymouth-plugin-script plymouth-scripts splashy splashy-branding-openSUSE splashy-mkinitrd

Please note the dependencies: amarok amarok-lang kwin libloudmouth-1-0

Well, that's what I meant, there are dependencies. To disable the booting splash, you only need to remove plymouth; the rest can not work with it missing, and they fulfil the dependencies. The list of "splash" packages above includes other splash things, that run on other occasions, I do not know which. So I will not try to remove them till knowing what they are. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 21/04/17 08:39 PM, John Andersen wrote:

On 04/21/2017 04:43 PM, Anton Aylward wrote:

...

# zypper rm $(rpm -qa | egrep 'plash|mouth')

Seems a little too loose of a selection to me.

Oh yes!! I went though the RPMs one by one and determined those that had nothing to do with the booting. I left them alone. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-22 00:54, Anton Aylward wrote:

On 21/04/17 05:39 PM, Carlos E. R. wrote:

...

On 2017-04-21 16:27, Anton Aylward wrote:

...

But that plymouth, that splashy stuff? How to get rid of it? Is adding it as an "omit" in /etc/dracut.conf the right way?

Just remove its rpm and run mkinitrd

One or all?

Just "plymouth", by looking at my "zypper ll". -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Andrei Borzenkov wrote:

Please test proposed fix (works for me): zypper ar obs://home:arvidjaar:boo:983221/openSUSE_Tumbleweed boo983221 zypper refresh boo983221 zypper dup -r boo983221

---- 1) Where do I run that? (remember, I don't even have networking running at the point it puts me into 'fix-it mode'). 2) my VBox SW isn't working after my latest kernel update. Have yet to figure out why.

Revert whatever you did to fix it to have clean environment.

??? I didn't fix it. I left it as it was. Are you saying I should reformat and reinstall all the packages? I can't seem to get it to do it automatically w/o it pulling in a bunch of things I know I don't need or want.

The bug was (IMNSHO) caused by modprobe being no more installed by default.

---- That's just evil! ... but a bunch of modules *were* installed. How did they get installed? Anyway... need to figure out why vmbox isn't working. Might have something to do with it deleting all it's run-config scripts... Nah... why would it do that? :-( -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Wols Lists wrote:

On 25/04/17 20:32, L A Walsh wrote:

...

Anyway... need to figure out why vmbox isn't working. Might have something to do with it deleting all it's run-config scripts... Nah... why would it do that?

Because, on Tumbleweed, it isn't supported?

VirtualBox isn't supported? ACK!

VBox *WILL* *BREAK* on any kernel upgrade, unless it is itself updated at the same time (closed kernel modules, don' cha no).

Already did that, and BTW, terminology detail: Open-source, out-of-tree modules != closed kernel module. (like Nvidia driver).

On any rolling release, VBox is a pain.

--- Depends on how often you update or whether dkms is provided.

It's forever breaking on my gentoo (except that I haven't updated it in ages because I'm expecting loads of grief when I do :-)

That's what dkms was invented for. It's on many distros, but not opensuse, because opensuse doesn't support users recompiling or updating their kernel. Suse _could_ facilitate this with a util similar to wicked, that toggles needed modules in a kernel-config file 'on' (instead of included as modules), rebuilding and reinstalling a local-HW specific version of the SuSE kernel that would boot without the need for an initrd. It might not be for everyone, but many unix vendors provided a script to do that: memory was less plentiful and disks were slower, so the less you transfered the faster your boot. Then, instead of people using 20-30MB per kernel(+initrd) in /boot, they could use as little as 6-7MB/kernel (which is why I lean toward smaller boot partitions) FWIW, in my current kernel I have 590 modules config'd with 48 built-in and 542 left for dynamic loading. Since boot, an additional 38 have loaded leaving 510 still on disk. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 26/04/17 11:53 PM, L A Walsh wrote:

they could use as little as 6-7MB/kernel (which is why I lean toward smaller boot partitions)

"small" is relative. The /boot partition will look, relatively, smaller as I upgrade 2T, 2T, 4T, even if its the same number of megabytes. Even so, its already down there is the 'rounding error'. And my kernel, you mean the vmlinuz-4.10.12, is under 7G And its not as if I am doing any aggressive tweaking.

FWIW, in my current kernel I have 590 modules config'd with 48 built-in and 542 left for dynamic loading. Since boot, an additional 38 have loaded leaving 510 still on disk.

Where do those numbers come from. In the interests of full disclosure, this is what i would show. # lsmod | wc -l 68 Take 1 off that for the header line. Those are all demand loaded. There is nothing in my /etc/modules-load* What is in /etc/modprobe.d/* was put there by the installer, I've edited nothing. # find /lib/modules/$(uname -r)/kernel -type f -print | wc -l 3845 I suspect we're not talking about the same thing here. Try again # for DIR in /lib/modules/$(uname -r)/kernel/*

do echo ${DIR}":" find ${DIR} -type f -print | wc -l done /lib/modules/4.10.12-2.g11b3f7c-default/kernel/arch: 39 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/crypto: 70 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/drivers: 2881 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/fs: 125 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/kernel: 3 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/lib: 22 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/mm: 2 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/net: 505 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/security: 1 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/sound: 196 /lib/modules/4.10.12-2.g11b3f7c-default/kernel/virt: 1

Betcha that for hardware specific I can go though all that, the drivers in particular, and PURGE! PURGE! PURGE! I'm sure that could make my initrd smaller as well :-) Its just that the very next 'zypper up' of kernel_stable will bring them all back. Being obsessive about such tweaking, such minimization, is time consuming and frustrating. There's a good reason most of us don't bother, that most of us just go with the initrd method that is packaged and delivered. We've got better thing to be frustrated over, to have consume our valuable and limited time that shaving seconds of the, perhaps once or twice a day that we do system loads, time that could be better spent, for example, refilling the coffee cup, which is what I think I'll do tight now. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 27/04/17 08:05 AM, Carlos E. R. wrote:

Yes, exactly.

That machine above boots quite fast. The slowness comes from entering the disk password, manually.

The usual hog is starting many services, or fsck.

Well, yes, mostly. I don't need a disk password and to be honest most services come up PDQ. Except ... Networking always involves delays and any service that depends on networking being up such as Postfix, spamd, the DNS service, fetchmail, are delayed. They may not take much time each, but they are blocked. But yes, FSCK is a killer. My basic strategy of having 5M partitions so I can back them up onto DVD cuts in here. Many of those 5M LVs are underpopulated. "MyDocuments" is one. I split "MyMusic" into genres and not all genres come anywhere near the 5G. Certainly the O(n)^2 of FSCK applies and having these smaller LVs works to my advantage and parallelism is possible, though not as helpful as you might think. But all those FSCK startups, even if they do nothing, still queue and block the disk. Turn off FSCK? NO WAY! https://www.reddit.com/r/Jokes/comments/156t9a/fighter_jock_and_the_cargo_pi... https://www.strategypage.com/humor/articles/pilots.asp -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

And my kernel, you mean the vmlinuz-4.10.12, is under 7G

7G eh? With almost 50 mods-builtin, my latest is 6.4MB. :-|

And its not as if I am doing any aggressive tweaking.

--- Neither am I. I just copy my config from the previous kernel and do a "make oldconfig". Occasionally I'll review things when I'm interested/have time.

Where do those numbers come from. In the interests of full disclosure, this is what i would show.

--- In the interest of not being overly technical, I only gave the numbers, but see below.... Carlos E. R. wrote:

I have 6 MB kernel + 13 MB initrd. Not 30. You get 30 when you also include the boot splash in plymouth.

---- Someone else said ~20+ for both when I talked about making my /boot 64MB. As for numbers higher than that, I was including all of the disk space for my modules ~ 22MB/kernel. Where I get my figures:

ls -1 /sys/module|wc -l 80 (all modules currently loaded) lsmod |wc -l 32

# of unloaded modules, I got via 'modprobe' and hitting <complete> in bash -- it fills in all the unloaded module names if you have the write bash-autocomplete stuff loaded. I use the one I wrote, but they have an equivalent one in the bash-autocomplete project. I pasted that into an array in bash (the paste takes up multple lines): a=(<paste>) Then printed out #of entries in array: echo ${#a[@]} An alternate way to find them (gives same number): Ishtar:/lib/modules/4.10.8-Isht-Van> find . -name \*.ko|wc -l 542 --- Which agrees *EXACTLY* with my earlier totals. I always love it when my figures add up. Of course the kernel modules in my /lib/modules<kernver> dirs are limited to loadable kernel options that are, mostly, not hardware based. As long as my kernel is built with the basic HW & file system that my OS uses to boot, all the rest of the modules can be autoloaded during the OS-bring-up. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org