[opensuse] ?Stable? Tumbleweed inst cont.: Getting into arcana... thin lvm volumes.... no devices loaded...etc...
For some reason, I'm seeing no lvm devices, though when I do an "lvs", I see them: (have to type them right now, as setup didn't ask me for network settings). LV VG Attr LSize Pool Home Data Vwi---tz-- 512.00g HomePool HomePool Data twi---tz-- 750.00g Any ideas how to turn them on? (partly solved -- on for now, but kernel mods didn't autoload, so not sure if things are fixed). --- 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. --- Issue#3 -- I don't seem to be able to see any packages to install from the CD. I can enter yast and it gave errors trying to refresh the online packages, but no packages from the DVD. On boot, I see [FAILED] Failed to start LVM2 PV scan on device 8:4. See 'systemctl status lvm2-pvscan@8:4.service' for details. ... [..] A start job is running for dev-Data-Home.device (90 secs...) ----- How do I terminate a wait? Stupid timeout... a local device should never take 90 seconds. *sigh*... Oh.. the info shows that none of the modules are loaded. ... fixed that... hmmm...(this is one reason why I generally use my own kernel ended up having to recreate the LVM stuff... (or maybe I didn't, but couldn't get the volumes recognized until I did that and started 'udevd' (as udevd --daemon --debug -resolve-names=early), using the --debug option probably should have gone to a disk, way too much output to track when I did things... (like lvm operations & mkfs stuff). I'm running low on energy ... This is supposed to be the stable release? Oi! Also noticed -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
L A Walsh wrote:
For some reason, I'm seeing no lvm devices, though when I do an "lvs", I see them: (have to type them right now, as setup didn't ask me for network settings). LV VG Attr LSize Pool Home Data Vwi---tz-- 512.00g HomePool HomePool Data twi---tz-- 750.00g
Any ideas how to turn them on? (partly solved -- on for now, but kernel mods didn't autoload, so not sure if things are fixed).
vgchange -ay ?
--- 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 lan ? or edit /etc/sysconfig/network/ifcfg-device Did something significant change in TW in this respect?
This is supposed to be the stable release?
Bleeding edge, methinks. -- Per Jessen, Zürich (2.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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?
--- Issue#3 -- I don't seem to be able to see any packages to install from the CD.
If you installed from CD, there are none. On the DVD, yes.
I can enter yast and it gave errors trying to refresh the online packages, but no packages from the DVD.
Is it CD or is it DVD what you used for the installation?
On boot, I see [FAILED] Failed to start LVM2 PV scan on device 8:4. See 'systemctl status lvm2-pvscan@8:4.service' for details. ... [..] A start job is running for dev-Data-Home.device (90 secs...)
----- How do I terminate a wait?
Stupid timeout... a local device should never take 90 seconds.
*sigh*...
It indicates that there is some other basic problem.
Oh.. the info shows that none of the modules are loaded.
... fixed that... hmmm...(this is one reason why I generally use my own kernel
Modules load instantly here, as soon as needed. If they are not loaded, there is some other problem.
I'm running low on energy ...
Are you trying to use your own customizations, or are you leaving everything to designed defaults?
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. Leap is stable. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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 ....
--- Issue#3 -- I don't seem to be able to see any packages to install from the CD.
If you installed from CD, there are none. On the DVD, yes.
**sorry**, meant DVD...
Stupid timeout... a local device should never take 90 seconds.
*sigh*...
It indicates that there is some other basic problem.
---- Yeah, like none of the lvm modules loading. just booted again .. same thing. no lvm modules are loaded.
Oh.. the info shows that none of the modules are loaded.
... fixed that... hmmm...(this is one reason why I generally use my own kernel
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...
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. Factory?! So I should really be directing these questions to the factory list? :-( ???!?
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".... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
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.
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...
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?
--- 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.
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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
Per Jessen composed on 2017-04-20 08:29 (UTC+0200):
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.
Pretty sure it never happened to me either. If you are going to "start over", consider starting using "my" HTTP (linuxrc) installation method, by configuring network on the cmdline of the installation kernel: net.ifnames=0 hostname=myhost hostip=###.###.###.###/24 gateway=###.###.###.### nameserver=###.###.###.### IIRC, this has always survived into first and subsequent boots for me, as components of /etc/sysconfig/network/ifcfg-eth0, /etc/udev/rules.d/70-persistent-net.rules and /etc/resolv.conf, even since distro incorporation of systemd and wicked. https://en.opensuse.org/SDB:Linuxrc -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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)
On 19/04/17 03:46 PM, Carlos E. R. wrote:
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.
Well, I don't know about yast. I rarely use yast. It isn't Yast that determines the initrd and what goes in there, its the settings for Dracut and mkinitrd. If you are "going stock", Linda, then you should be using Dracut to build the initrd. One of its config files can set the required module packages. You can simply specify "lvm" and that will tell dracut to include all the stuff necessary. See my other post where I give example of what I find in my initrd using 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:
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
On 21/04/17 09:20 AM, 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??
Is that something setup-users are expected to know?
"set-up users" being what? People who build and configure kernels are usually system administrator grade or functionaries. "Set-up" is just to vague a term. Set up what? Drinks on the bar? I'll have a double, thank you. Double what? you ask? Dunno, let's see what's on this supposed menu. -- 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:
"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
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. -- Per Jessen, Zürich (14.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 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 21/04/17 11:26 AM, L A Walsh wrote:
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 ....
Well, you've just described two different types of people. There MIGHT be an overlap, but then again the often isn't. Anyone _motivated_ to move from Windows to Linux, motivated enough to do an install, as opposed to the 'just curious' who are trying out Linux on a LiveCD (possibly copied to USB for speed) isn't going to be an ignorant newbie. It is someone who is motivated, that kind of person won't be approaching things blind. he, or she, will have done some reading, some research, and have a clue as to differences and such like. They are likely to have tried to configure Windows and suffered frustrations. They expect, quite probably hope, that Linux will be different, be more visible, more mutable. Certainly the vast amount of How-To and Q&A out there on the 'net (admittedly its a lot better for Ubuntu and Arch than it is for openSuse) would lead them to believe that.
Someone who may have little knowledge about the command line -- or at least one where most things don't work.
Since so much of the documentation, the How-to, the Q&A on Linux is CLI-oriented, the better to explain And illustrated the set-up of what's going on and the options you have, in a way that is usually hidden by GUI, I'd expect the people I've just described above to see that if you want to work under the hood with Linux then CLI is the way to go. Of course there's the gulf as described here: http://www.zdnet.com/blog/murphy/why-many-mcses-wont-learn-linux/1137 But lets face it, that's about entrenchment. Any so obsessed with GUI that he, or she, doesn't see that all those How-to, Q&A and more spend so much time describing CLI ways of doing things that they don't get the message is, of course, going to be frustrated. Other people, people with more tolerance, people with more curiosity, are going to do things like work their way through the menu options to see what they do, what is available to them. They are going to experiment. In doing so they will learn.
How much knowledge do people have to have in order to install (setup) open suse from the DVD?
How vanilla an install (set-up) do you want. Your issue, Linda, is that you don't want a vanilla install (set-up), you want to customise in many ways, but you don't want to do a vanilla install and then later iterate (using the CLI, drakut etc). You want a custom install. You want it with the GUI, not with hot keying to another VT where you can do CLI things in parallel. Not build a LVM system first and then set up a thin partition the way that I and others have done, people who do make use of LVM extensively, people who reliably boot into a LVM based system. So please stop asking trick question. Please stop doing this "yes but" play. -- 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)
Carlos E. R. composed on 2017-04-21 20:13 (UTC+0200):
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.
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. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
John Andersen composed on 2017-04-21 11:47 (UTC-0700):
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.
My mistake, with interesting consequence. Before posting I ran mkinitrd --help and saw no reference to dracut. Now I ran man mkinitrd, and it's clearly become a compat wrapper to call dracut. It's 12306 bytes in 42.1, down from 15715 in 13.1, more surprises, as I expected both would be binaries, not scripts. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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 04/21/2017 01:51 PM, Anton Aylward wrote:
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.
And for a good generic reference for LVM setup, it's always worth checking the Arch wiki for low-level config info, e.g. https://wiki.archlinux.org/index.php/LVM (aside from arch using a slightly different config, it gives you all the nuts-and-bolts of LVM config) This isn't a knock on suse, just a recognition that the archwiki usually has good low-level config info given its minimalist approach to setup tools (and the extraordinary amount of work that Arch puts into its wiki -- on all subjects) -- David C. Rankin, J.D.,P.E. -- 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:
On boot, I see [FAILED] Failed to start LVM2 PV scan on device 8:4. See 'systemctl status lvm2-pvscan@8:4.service' for details. ... [..] A start job is running for dev-Data-Home.device (90 secs...)
----- How do I terminate a wait?
Stupid timeout... a local device should never take 90 seconds.
*sigh*...
Semi-OT, but this f*****g 'Feature' of systemd drives me mad, too. Just had it again at reboot - there was still a user login on another virtual console. So the reboot hang with a timeout waiting for that one. Of course all accesss and services are already turned off, you have no chance at all to log out of that session. so systemd just waits. And waits. And waits even longer.... This is ridiculous. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
L A Walsh composed on 2017-04-18 18:38 (UTC-0700):
Issue#2: where / how do I change network settings?
For fixed IP here it is as it has been since before adoption of "predictable network interface names": #/etc/sysconfig/network/eth0 BOOTPROTO='static' STARTMODE='auto' IPADDR='###.###.###.###/24' I also have /etc/udev/rules.d/70-persistent-net.rules (containing mac address for eth0), and /etc/udev/rules.d/80-net-setup-link.rules (empty) and I boot with net.ifnames=0 on cmdline. I have no installations with wan or more than one NIC. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata wrote:
L A Walsh composed on 2017-04-18 18:38 (UTC-0700):
Issue#2: where / how do I change network settings?
For fixed IP here it is as it has been since before adoption of "predictable network interface names":
The latter were given up again in Leap.
#/etc/sysconfig/network/eth0
/etc/sysconfig/network/ifcfg-eth0
I also have /etc/udev/rules.d/70-persistent-net.rules (containing mac address for eth0),
YaST creates that one for you too. -- Per Jessen, Zürich (5.9°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
19.04.2017 04:38, L A Walsh пишет:
For some reason, I'm seeing no lvm devices, though when I do an "lvs", I see them: (have to type them right now, as setup didn't ask me for network settings). LV VG Attr LSize Pool Home Data Vwi---tz-- 512.00g HomePool HomePool Data twi---tz-- 750.00g
Any ideas how to turn them on? (partly solved -- on for now, but kernel mods didn't autoload,
Why do you expect them to autoload?
so not sure if things are fixed).
You use thin provisioning pool which is not supported by YaST 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). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 thought
Andrei Borzenkov wrote: that depmod was run so when accessing a device, the related modules could be autoloaded? Also, the setup tool knew all about thin volumes -- I didn't have to do the setup manually -- and it also knew if I deleted the thin pool, that /home would be disabled. That indicates the setup process knew what thin volumes were and what they were used for. A third reason would be that there was no error or warning that the system was configured in a non-bootable state like there is if you have no root or when there are other config problems. A fourth reason would be that sysd seems to know that the reason there are problems is that the modules are not loaded. One might wonder why it didn't load any modules needed by LVM -- not for raid, or any device-manager functions. When my system boots a fair number (~15-20) modules get loaded automatically during hardware probing. As I use the system, more get loaded automatically -- though sometimes I need to load some manually. What has happened here, is I choose an option from a menu during setup -- and it's role of the dice as to whether or not I bring up a supported configuration. Worse, was that what was supported at one point in time, became "no longer supported", often, seemingly at random. I don't want to have to reconfigure my system to go with the latest fad with each release. 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. I could watch the kernel come up and set my devices the way I originally wanted them (eth0..), then the sysd version of udev would load, change them to junk, then I see them switched back. It was never the kernel that changed, but some user mode prog (looks like udevd, though I've never isolated it to be sure.
You use thin provisioning pool which is not supported by YaST
---- Not supported? Sure looked supported to me. It knew that a thin provisioned lv needed a pool, and when I was trying to figure the problem by deleting the extended volume -- it warned me that the pool was needed for the thin volume to function. There was no indication that it wasn't supported, and no indication of how to have it load the needed modules.
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... Even now, I can't continue to boot or switch to an alternate console -- the only thing sysd will let me do is reboot which is completely unhelpful, since as soon as I boot, anything I did to make things work will be unloaded. How do I get it to let me continue to boot (only /home is missing) so I can login and fix things? This was a major fear of mine concerning sysd -- that a problem would come up and sysd would lock me out of my system. Case in point. :-( -- 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
On Thu, Apr 20, 2017 at 8:04 AM, L A Walsh <suse@tlinx.org> 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. To make myself clear - your question sounded like you *know* that there is mechanism to autoload DM modules and this mechanism stopped working. I myself am not aware of this from kernel side, so I do not see why you expect *autoload*. 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 use thin provisioning pool which is not supported by YaST
---- Not supported? Sure looked supported to me. It knew that a thin provisioned lv needed a pool, and when I was trying to figure the problem by deleting the extended volume -- it warned me that the pool was needed for the thin volume to function.
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. -- 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 <suse@tlinx.org> 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
20.04.2017 23:06, L A Walsh пишет:
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).
Of course it works when module is loaded. What I mean - it fails if module is *not* loaded which confirms that there is no autoload.
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.
Here we are again. ...
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. Anyway, there is bug report about it: https://bugzilla.opensuse.org/show_bug.cgi?id=983221 -- 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
L A Walsh wrote:
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.
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 -- Per Jessen, Zürich (13.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- 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
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. -- Per Jessen, Zürich (14.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- 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
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. -- 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 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. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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 2017-04-22 01:53, Anton Aylward wrote:
On 21/04/17 05:43 PM, Carlos E. R. wrote:
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.
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 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?
No. What I said is that /IF/ dracut has to be configured so that a complex(?) LVM setup boots after the initial system install is done, then the installer has to configure dracut, not the user aka admin. And the installer is a YaST module, I believe. If configuring dracut means run it with certain options, so be it. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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
Carlos E. R. wrote:
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.
Might not be pertinent to this discussion, but you can actually build the initrd the way you want, before the first boot. Stop the process at the end, swap to a console and do what you need to do.
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.
99 out 100 times it probably does, but occasionally it doesn't quite work. -- Per Jessen, Zürich (14.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- 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
Anton Aylward wrote:
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.
Same here, possibly with one or two exceptions. I think I have system under test right now, where I had to blacklist 'bnx2' and add 'bnx2i' to be loaded via modules-auto.d/. -- Per Jessen, Zürich (14.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- 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
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.
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. 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. So we're play a game of "There's a hole in my bucket" with you. Yes, but ... yes, but ... yes, but ... I'm sure you find it frustrating. I can sympathise. I don't want to, as I have better things to do, but I've been in this situation. One time was with an IBM AIX and it took my two weeks to escalate the situation to get through to developers in Texas where they replicated _exactly_ my configuration and another week before they admitted there was a problem and another month before they offered a patch. Many of us work to shrink out initrd and make systems load faster and all that. I look at the output of my 'lsinitrd' and I'm sure I could strip more out, male systemd do more in parallel. 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? -- 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 21/04/17 11:41 AM, L A Walsh wrote:
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.
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 ...
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.
The gulf isn't 'just like me', the gulf is between Linda and 'the rest of us'. I just happen to be the one calling you out at this point in the thread.
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).
My system boots in a little less, then spends about 20 seconds setting up KDE with Thunderbird, Firefox, a few Konsoles and Dolphin. Of the 20 or so seconds, nearly 8 seconds is taken by LVM initialization and "settling". I'm sure if I was using SSD instead of rotating rust many of the figures such as that, the initial FSCK of the partitions would be reduced. What I'm saying, Linda, is that starting from a plain DVD install, tweaking the build of the initrd using dracut.conf, I can do as well or almost as well as your times when I boot my desktop every morning, without the pain sweat and anguish you are going though. More to the point, when I ask advice of the forum, or look to the How-To, even when they pertain to Arch or Redhat, about kernel modes, systemd modes, tuning and more, I can make use of the advice, because I've stuck with a 'mainstream' installation.
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?
My what? Oh, typo time: "... make systemd ..."
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.
Dunno.I don't use Yast much, just for doing things that I want a bit more comparative visibility than I get using zypper. Or maybe for advice about adding optional repository. I'm not sure if CL:I has the bug of which you speak, but the fall-back with CLI is always VIM. its a lot more powerful than Yast, but it relies on a different knowledge base, one in a handwritten book I keep rather than what a programmer decided to encode.
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?
Yes, that's my point. I boot text mode, so why TF is it in there? -- 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 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 23/04/17 12:01 PM, Brian K. White wrote:
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.
Perhaps you hadn't got to the latter parts of this thread. Along the way Carlos pointed out to me my confusion. The way Linda had interspersed her comments about this installation with her regular comments about a "zero sized initrd' and her regular comments about "sysd" had me confused. There are times I like bullet lists of points for clarification. You might have noticed that in my other posts. Once that was made clear to me by Carlos I drilled down on her issue with "thin pool" creation, since I am, as regular reader will recall, a proponent of LVM and had successfully built thin pool systems in the past and wondered what the gap was. I determined that yes, she was correct, there was a bug in YaST, well actually in one of the libraries used by YaST, and further that this bug had been reported and fixed back in February. If you think about that, it means the fix can't be in the installation DVD. Tumbleweed is another matter, though. Yes, as Linda pointed out, the bug was in (the use of) YaST. if you use the CLI to build the thin pool system, as I had done in the past, and thank you the guys at Arch for a very nice page about this, you would never have met this problem. I rarely use YaST. Things like this do not encourage me to use YaST. Please do read to the end of the thread. -- 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 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 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. My laptop is Windows, SuSE and gentoo. That was a nightmare to get booting properly. I set up a test machine with SuSE on raid. That was a nightmare to configure the disk. I tried to get SuSE to start my WiFi network at boot. That's STILL broken. That's one of the reasons my preferred distro is gentoo. At least if it breaks, it's my fault and not some damnable Artificial Stupidity tool double-guessing me and screwing up :-) Cheers, Wol -- 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 24/04/17 06:34 PM, Brian K. White wrote:
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..."
;)
Brian, this is unhelpful. Yes there is a bug in YaST. Yes, the path involving creation of thinpool wasn't tested. Until, possibly, the bug *was* found:, as I've pointed out a couple of times now: 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 found and 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 ========================================================================= Rather than 'rail against the darkness' I lit a candle, drilled down and determined what the bug was, found the bug had been reported, found the bug had been fixed. Yes I actually addressed the problem when others were railing. I'm often called an old dinosaur because I quote history and tradition. When I'm 'befuddled' I explore variants, read the documentation, seek advice from people who have made it work and follow as exactly as I can what they (claim) they were doing. I don't know the specifics of why Linda has so much problem with "sysd" as she calls it. I'm not looking over her shoulder as she tries an install and I get confused by the way she communicates her complaints. I don't claim to be a a genius. I admit that people like Leonard are a lot smarter than me and have the humility to try and persist and carefully document what I do and persist and first assume I'm doing something wrong until I have overwhelming and verified evidence to the contrary. As, in this case, the bug in YaST use to make a thin pool system being traceable to libstorage6.so and the use of "--zero=y" that was corrected back in February. Is the fact that such updates aren't on the distribution (and therefore installation) DVD "a bad thing"? I've suggested a number of times doing a basic install and then making the thin pool from the CLI -- where you can use 'lvcreate' directly and omit the un-needed "--zero=y" and omit using libstorage6.so. I've suggested using DVD-based or USB-based tools to set up the disk, set up the LVM and the LVs before starting the installation. Lets face it, I'm not alone in this; I'm just echoing what other people have suggested I do, what other people who deal with multiple drives, multiple installations, lots-a-lots-a partitions do. There's nothing new or innovative about this approach. I've pointed out that there are LVM tools to populate the /dev/for the LVM LVs. Like so much about Linux "there's more than one way to do it" depending on other factors. There's a lot I don't know about. Multiple boot comes into that category. I always seem to have enough problems with MBR, I can't dream of how people manage to boot multiple distributions! I realise that systemd is, like many things in Linux, an 'ongoing project' that has a few ragged, incomplete ends. I stay away from those bits of it. But I do know the core works. Perhaps its a bit like religion: if you are believer the miracles work for you, if you're not a believer then they don't. Perhaps the reason my boot is slower than Linda's is that I run a FSCK on *every* LV. Even if each one says "nothing to do here" there's still a cost. Lots-a-lots LVs. Every time I have an issue I create a new LV. They're dirt cheap. Load up with Reiser, find out the number of inodes I need, create another one with ext4 carefully provisioned. But I never seen to throw away they first one :-) :-) And of course os-prober wastes time looking at them as well, even if it finds nothing there. Systemd works for me. Thin pools work for me. I've explained how. -- 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-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)
On 24/04/17 02:49 PM, Carlos E. R. wrote:
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 :-)
I never said that I absolutely NEVER UNDER ANY CIRCUMSTANCES use YaST. let me repeat what I did say: ---------------- Dunno.I don't use Yast much, just for doing things that I want a bit more comparative visibility than I get using zypper. Or maybe for advice about adding optional repository. -------------------- I also mentioned that I set up my disk BEFORE installation to be the way I want it using tools dedicated to disk setup, rather than using the YaST partitioner. The example I keep quoting is that the YaST partitioner makes use of libstorage6.so whereas the CLI creation of thin pools (as described by a number of HOW-To pages) just uses the LVM commands directly. Using the CLI I can see what is going on. In my DatabaseOfDotSigQuotes this is this: That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible. -- John William Chambless What it boils down to is that if you use a GUI you are surrendering control to what the GUI designer thought you should be doing and how you should do it. Yes, you do that to some degree using any program, but GUI and GUI designers add another layer to this. In this case, Linda trying to use YaST to set up thin pools, it was an error on the part of the GUI designer to use libstoage6.so rather than directly control the commands. Boo-Hoo! This error had existed a long time, way back to 10.something. But it had been reported and it had been fixed. I've reported that too. Of course, since I'd *always* done LVM things from the CLI, it being one of the cases where I'd not bothered with YaST since I wanted to learn how this worked, and once done it with the CLI, kept doing it that way, I never met Linda's problem until I specifically had to drill down and trace the bug. Which I reported in detail elsewhere in this thread. -- 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
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
On 23/04/17 12:01 PM, Brian K. White wrote:
But we now have problems that are the result of ignoring/forgetting/disacrding things that have been figured out a long time ago.
It depends. 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. It was fixed just recently, this February. Let me quote once again: 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 ========================================================================= What was "figured out long ago", the use of "--zero=y" WAS WRONG! -- 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:
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 4/25/2017 3: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.
Just shut up with your confusing annoying logic! We don't understand it, therefore, it doesn't matter! -- bkw -- 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
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.
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).
My system boots in a little less, then spends about 20 seconds setting up KDE with Thunderbird, Firefox, a few Konsoles and Dolphin.
---- Um, I'm talking booting to login w/all services started.
Of the 20 or so seconds, nearly 8 seconds is taken by LVM initialization and "settling". I'm sure if I was using SSD instead of rotating rust many of the figures such as that, the initial FSCK of the partitions would be reduced.
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.
What I'm saying, Linda, is that starting from a plain DVD install, tweaking the build of the initrd using dracut.conf, I can do as well or almost as well as your times when I boot my desktop every morning, without the pain sweat and anguish you are going though.
---- I've never tweaked or built an initrd. It's not something I've ever really needed. On top of that, your boot times are over twice as slow, as my boot times include lvm and all services. Never been locked out of my system, yet, but first time I try 'your way', I'm locked out by sysd. I may use sysd, but it can't stay as 'init', as it isn't trustworthy or reliable. Maybe I'll try leap next time. BTW, most of the pain sweat and anguish came from you. -- 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 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 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.
No, Anton, this time she is not using those customizations. It is a standard install, and doesn't work. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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 2017-04-22 00:52, Anton Aylward wrote:
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.
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.
Or is she doing two things and confusing the reporting of them, somehow conflating the reporting?
She compares (and complains) her working setup with the non working new install made "correctly". -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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 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 -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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
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' # -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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)
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? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
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 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. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 <jsmeix@...> 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)
Carlos E. R. composed on 2017-04-22 19:11 (UTC+0200): ...
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.
The problem with the requirement is it does not *need* the font to provide functionality, only appearance, aka branding. In the current since about two decades ago era of HTML, its appearance is "controlled" by CSS. CSS in turn is merely suggestive, not authoritative, that is, the viewer of HTML pages using a web browser has ultimate authority over styling permitted, able to disable all 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. 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. 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. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
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.
And that thread?
Two years old?
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 :-(
Dunno. I use YaST for software too little. Zypper doesn't complain after 'zypper al google-opensan*', but adding or updating the relnotes does take a bit of extra admin effort. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
Carlos E. R. composed on 2017-04-23 14:31 (UTC+0200):
On 2017-04-23 05:51, Felix Miata wrote:
Carlos E. R. composed on 2017-04-23 00:09 (UTC+0200):
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.
At the bottom of every bugzilla page is a link to "My Bugs". Anyone who has been assigned bugs knows which they are, or doesn't care.
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?
I don't subscribe to packaging any more. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 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 -- 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: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 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. -- 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 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
Anton Aylward composed on 2017-04-21 19:43 (UTC-0400):
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
Something does not seem right there: # grep RETT /etc/*ease /etc/os-release:PRETTY_NAME="openSUSE Leap 42.2" # grep ver.only /etc/zypp/zypp.conf solver.onlyRequires = true # rpm -qa | egrep 'ession|marok|kspac|plash|kwin' plasma5-workspace-5.8.6-8.1.x86_64 plasma5-session-5.8.6-7.1.noarch kdebase4-workspace-libs-4.11.22-3.24.x86_64 kwin5-5.8.6-7.1.x86_64 plasma5-workspace-libs-5.8.6-8.1.x86_64 # zypper -v in amarok Verbosity: 1 Non-option program arguments: 'amarok' Initializing Target ... Reading installed packages... Force resolution: No Selecting 'amarok-2.8.0-14.3.x86_64' from repository 'OSS' for installation. Resolving package dependencies... Force resolution: No The following 13 NEW packages are going to be installed: amarok 2.8.0-14.3 libfftw3-3 3.3.5-1.7 libgpod4 0.8.3-5.32 liblastfm1 1.0.8-4.2 libloudmouth-1-0 1.4.3-25.4 libmygpo-qt1 1.0.7-6.4 libmysqld18 10.0.29-18.1 libofa0 0.9.3-102.3 libtag-extras1 1.0.1-24.1 libtag_c0 1.11-1.23 mariadb-errormessages 10.0.29-18.1 phonon-backend-gstreamer 4.8.2-4.1 taglib 1.11-1.23 13 new packages to install. Overall download size: 10.8 MiB. Already cached: 0 B. After the operation, additional 40.8 MiB will be used. Continue? [y/n/? shows all options] (y): n -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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)
19.04.2017 04:38, L A Walsh пишет:
For some reason, I'm seeing no lvm devices, though when I do an "lvs", I see them: (have to type them right now, as setup didn't ask me for network settings). LV VG Attr LSize Pool Home Data Vwi---tz-- 512.00g HomePool HomePool Data twi---tz-- 750.00g
Any ideas how to turn them on?
Please test proposed fix (works for me): zypper ar obs://home:arvidjaar:boo:983221/openSUSE_Tumbleweed boo983221 zypper refresh boo983221 zypper dup -r boo983221 Revert whatever you did to fix it to have clean environment. The bug was (IMNSHO) caused by modprobe being no more installed by default. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
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? VBox *WILL* *BREAK* on any kernel upgrade, unless it is itself updated at the same time (closed kernel modules, don' cha no). On any rolling release, VBox is a pain. 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 :-) Cheers, Wol -- 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 Thursday, 27 April 2017 13:23:30 ACST L A Walsh wrote:
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.
I have been using dkms on openSuSe since 13.0 (now running Tumbleweed) and it works fine! I've not had to rebuild vbox modules since I installed and configured it. (Mostly) the same with Nvidia drivers, although certain X/KDE updates can (do) break the drivers and require a re-install. Vbox, however, "Just Works (TM)" with dkms installed and properly configured. There are instructions on the web for setting up vbox with dkms, but I only had to do it once and I can't remember the page I got the info from. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- 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 2017-04-27 13:54, Anton Aylward wrote:
On 26/04/17 11:53 PM, L A Walsh wrote:
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.
Isengard:~ # lsmod | wc -l 164 That's a nearly default install of Leap 42.2.
# find /lib/modules/$(uname -r)/kernel -type f -print | wc -l 3845
Isengard:~ # find /lib/modules/$(uname -r)/kernel -type f -print | wc -l 3696
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.
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. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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
On 2017-04-27 05:53, L A Walsh wrote:
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)
I have 6 MB kernel + 13 MB initrd. Not 30. You get 30 when you also include the boot splash in plymouth. It doesn't really matter. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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
participants (13)
-
Andrei Borzenkov -
Anton Aylward -
Brian K. White -
Carlos E. R. -
Dave Plater -
David C. Rankin -
Felix Miata -
John Andersen -
L A Walsh -
Per Jessen -
Peter Suetterlin -
Rodney Baker -
Wols Lists