Search results for

Re: [opensuse-factory] Re: Re: Re: Re: Testing many small file write on several filesystems [Was: btrfs still fails writing more than 15-TB]

by Greg Freemyer

-- Greg Freemyer On Mon, Oct 28, 2013 at 4:37 PM, Yamaban <foerster(a)lisas.de> wrote: > On Mon, 28 Oct 2013 21:16, Greg Freemyer <greg.freemyer@...> wrote: > >> On Mon, Oct 28, 2013 at 9:30 AM, Yamaban <foerster(a)lisas.de> wrote: >>> >>> >>> Other filesystems (XFS,JFS,ZFS,...) should be only in expert-mode >>> made available, or above a certain partition-size (see btrfs and 15TB), >>> with a strong hint about these fs not being useful in most SOHO cases. >> >> >> I argue XFS for sure should stay on the list. >> >> == background >> >> Dave Chinner (xfs devel) would argue that ext2/3/4 is what should be >> removed from the default list and XFS & btrfs be the only 2 choices. >> >> See this from Jan 2012: http://www.youtube.com/watch?v=FegjLbCnoBw >> He says anything with a 3.0 or newer kernel should be considering xfs >> in preference to ext2/3/4 if they have multiple CPUs (and even my >> phone has multiple CPUs) performing I/O to the fiilesystem. >> >> The core argument for that is recent XFS from the last couple years >> has incorporated a lot of the ext3 / ext4 speed improvements in >> journal handling, but it has maintained the scalability capacity it >> always had. Thus it is now useable from the desktop to the >> datacenter. >> >> I haven't seen a xfs related lost data horror story from a routine >> power outage in years, so the old statement the xfs only made sense if >> you had solid power is no longer true I don't think. >> >> Thus Dave Chinner argues that a user wanting a stable FS that scales >> from desktop to enterprise should focus on XFS. >> >> Users that want the features of btrfs should use it on their desktops >> and XFS on their big systems. > > > For big partitions (see 15 TB) better xfs than btrfs, sure. > ATM I'd say btrfs up to ca 8 TB, XFS as a valid option ca 6 TB and up. > > What hinders me to give a full recomentation for XFS is the overhead > on create and remove a file / dir . That summs up, see the tests. I don't know what you saw in Carlos'es results to make you say that. I think the situation is far more nuanced than you suggest. For a single threaded situation, all of the speed benchmarks Carlos posted are acceptable as far as I'm concerned. >From Carlos'es earlier post in this thread for both 100 Byte files and 10MiB files: === 10000 files of 100 B time (real/user/sys) | listing time | rm files time | used free % | (real/user/sys) | (real/user/sys) | space space reiserfs 0m10.171s/0m0.795s/0m1.445s | 0m0.030s/0m0.027s/0m0.003s | 0m0.282s/0m0.002s/0m0.277s | 9.9M 118G 1% ext4 0m10.087s/0m0.779s/0m1.387s | 0m0.050s/0m0.045s/0m0.006s | 0m0.126s/0m0.004s/0m0.121s | 266M 112G 1% ext3 0m10.266s/0m0.732s/0m1.415s | 0m0.050s/0m0.040s/0m0.010s | 0m0.156s/0m0.005s/0m0.148s | 228M 112G 1 xfs 0m10.193s/0m0.680s/0m1.332s | 0m0.028s/0m0.023s/0m0.005s | 0m0.235s/0m0.003s/0m0.231s | 270M 120G 1% btrfs 0m10.195s/0m0.689s/0m1.394s | 0m0.030s/0m0.026s/0m0.004s | 0m0.280s/0m0.005s/0m0.273s | 9.6M 118G 1% === 10000 files of 10 MB (not 10 MiB). Disk busy at up to 155MB/s - hardware is the limit. time (real/user/sys) | listing time | rm files time | used free % | (real/user/sys) | (real/user/sys) | space space reiserfs 12m39.628s/0m4.775s/3m10.519s | 0m0.309s/0m0.032s/0m0.005s | 0m13.438s/0m0.032s/0m0.005s | 94G 27G 78% ext4 12m15.974s/0m3.833s/1m43.232s | 0m0.077s/0m0.043s/0m0.009s | 0m6.394s/0m0.004s/0m1.490s | 94G 19G 84% ext3 15m20.931s/0m3.756s/2m40.206s | 0m0.156s/0m0.045s/0m0.007s | 0m9.677s/0m0.005s/0m3.006s | 94G 19G 84% xfs 11m11.731s/0m4.737s/1m26.311s | 0m0.155s/0m0.024s/0m0.005s | 0m9.480s/0m0.011s/0m1.584s | 94G 27G 78% btrfs 10m37.071s/0m4.837s/1m11.542s | 0m0.376s/0m0.027s/0m0.004s | 0m9.755s/0m0.004s/0m2.691s | 92G 27G 78% === >> Create Speads All 5 create the 10,000 100 Byte files at the same speed +/- 1%. XFS is second fastest at creating 10MB files and is over 3 minutes faster that ext3 and a minute faster that ext4. In fact XFS is faster than everything but BtrFS at creating the 10MB files. If creating 10 MB files is important to you, then it is reiserfs and ext3/ext4 you should eliminate from you options. If you only care about small files, then they all create files very quickly. There is certainly no reason to make a blanket statement that XFS is slow at creating files. >> Listing files For the 100 Byte files, all list the files at roughly the same speed. For 10 MB files, listing is effectively fast for all except BtrFS and ReiserFS which take about 1/3 of a second each. For an interactive user, 1/3rd of a second is noticeable. >> Removing files For 100 Byte files, xfs takes 0.235 seconds to delete 10,000 files. Both ReiserFS and BtrFS take longer. For 10 MB files, XFS is only bested by ext4, but admittedly by over 3 seconds. ------ I don't know about you, but I don't delete directories with 10,000 files in them very often and when I do I can stand to wait an extra 3 seconds. The speed tests certainly don't rule XFS out in my mind even for a singlethreaded test like Carlos did. Then if you watch the video, you see that Carlos tested XFS in it's worst mode. Were it shines is if you have multiple threads sending file i/o at it. For up to 8 threads it basically sees a linear speed bump. Neither ext4 or BtrFS can keep up. (ReiserFS was not part of Dave Chinner's testing). Historically XFS fell down because it couldn't handle huge tarball extraction and large tree deletion very well. That issue is resolved and if you are compiling in parallel like a lot of builds do these days, then XFS may be the best choice even for a developer working with large tarballs. fyi: I did not read the test script to confirm all the cache flushes are handled right for the above benchmark to be valid, but it probably doesn't matter. For a normal user, they just want to know how long the command prompt takes to return and don't care if the kernel is still processing the removes in the background. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

11 years

Re: [opensuse-factory] One of the options for staging projects

by Sascha Peilicke

On Tuesday 03 December 2013 10:41:59 Michal Hrusecky wrote: > Sascha Peilicke - 10:17 3.12.13 wrote: > > On Monday 02 December 2013 19:52:47 Michal Hrusecky wrote: > > > Hi, > > > > > > we are having a nice torrent of ideas in this mailing list since coolo > > > > > > presented this proposal last Thursday: > > > https://progress.opensuse.org/workflow/factory-proposal.html > > > > > > Some of them are related to staging projects, so I will try to expand > > > further one of the options regarding what could be happening inside that > > > dashed box in the diagram. > > > > > > The main goal of staging projects is preventing Factory from breaking > > > so often by creating a "temporary and alternative Factory" where > > > dangerous and conflicting submissions have to learn to live in peace > > > and harmony before entering the real Factory. The original mail from > > > coolo contains a great example with new automake. > > > > > > So let's look closer into all those boxes, arrows and decision boxes: > > > > > > 1) Developer sends SR#1 to Factory and review team decides it needs > > > > > > staging, so staging project gets created (let's assume the decision > > > is > > > made by the review team, even if this is currently being discussed in > > > the mailing list). The staging project initially contains only the > > > package that is being sent and rebuilds everything from Factory that > > > depend on it. > > > > The art here is how to make that decisions. If it would be based on past > > experience, we would always recommend to stage glibc :-) > > And probably rightfully. Although I would say that bugfix releases not > changing API/ABI probably don't need to go to such an extent. > > > On the other hand, there's udev, which doesn't break builds but peoples > > running systems. So staging udev wouldn't reveal anything until people > > actually test the staged udev. > > Well, apart from staging projects, there is need QA part in the proposed > workflow ;-) Ah ok, I have to admit that this thread became TL;DR for me already. So who will do the QA part? Before we propose anything there we should ask our stable release maintenance guys how pending updates are tested (if at all). > > Though this is a counter-example, I like the general idea. > > Glad to hear so. > > > The Factory maintainers and the review team could come up with a list of > > packages that are likely to cause issues. For those we could just demand > > staging, no matter what. We would publish / version the list somewhere and > > just add a check to factory-auto. > > Well, I would make it a little softer as part of the review - if you see > that there is just typo in man fixed, no need for staging, if all headers > got renamed, we need staging for sure. These to being just extremes, but > what I'm saying is that I would like to make it more fuzzy... > > > Another category would be packages where the submitter demands staging. I > > expect this to happen far less frequently but we should emphasize that > > this > > option is available. Responsible submitters may want to use it if they > > bring major changes to the distro. > > Sure, packages should be able to ask for it as they should know much better > how drastic are the changes. > > > > 2) [snip] > > > > > > This is just a proposal on how staging projects could work. The main > > > goal of this proposal is to partially move the responsibility of the > > > > > > integration process into the community of packagers so: > > > - Staging project maintainer has to cooperate with package maintainer > > > > > > to get his SR in. > > > > To whom does the SR belong here? Is it the staging prj maintainer that > > wants it or the packager? IMO its usually the latter wanting the SR to > > get in while the former wants to get rid of the staging project again. > > Actually both. It was meant that the guy maintaining staging project has to > work together with other people to get rid of his staging project and get > stuff in, but it works also other way around. Packager need to cooperate > with staging project maintainer to get his new and cool version in. > > > > - Package maintainers have motivation to fix their stuff, otherwise > > > > > > new versions don't get included. > > > > I think this was discussed elsewhere already, but not-so-core community > > members are often asking why they should fix their package if breakage > > came > > from elsewhere (e.g. new glibc vs. random game pkg). But it's > > Well, it works other way around as well, why should glibc maintainer fix > something that uses API that was deprecated long time ago. The important > part is that they should work it out together, otherwise neither of them > can in. I always agree if someone says "people should talk to each other". But the in reality we are talking someone has to fix something after it broke. Usually that's the guys that are either paid for it or who are very concerned about such matters. Often these are the same people :-) > > > The main advantages if this approach are: > > > - Everything has to go through package maintainer to make sure > > > > > > changes don't get lost, package maintainers knows about the problems > > > and agrees with the solution > > > > > > - We move from one good state to another, accepting only changes > > > > > > together with fixes. > > > > I think you are correct that we have to bring the packagers into the > > fix-it > > boat. But let's not be overambitious, this won't solve everything :-) > > Well, this should solve the failing packages in Factory and make Factory > buildable/rebuildable all the time. To make it stable and working, we need > QA, that was in another box :-D What we can improve though is the notification part of it. While we have coolo's reminder mails about new breakage, that's sometimes still overlooked by people (like me). -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

10 years, 11 months

Re: [opensuse-factory] Re: [PLEASE SPEAK UP] Disabling legacy file systems by default?

by Jeff Mahoney

On 1/31/19 2:52 PM, Jim E Bonfiglio wrote: > Hi Jeff- have data been gathered regarding these file systems which the > "vast majority of users" use? If so, where might I find these data? > Does SUSE or anyone else gather these data regarding users of > (open)SUSE? If so, how are these data gathered? > > > Best, Jim > > > > On Thu, 2019-01-31 at 14:43 -0500, Jeff Mahoney wrote: >> On 1/31/19 1:42 PM, Jim E Bonfiglio wrote: >>> Hi Jim- so far as I'm aware, thinking does not necessarily match >>> reality. I couldn't tell you how many attend that conference, but I >>> do >>> wonder what a representative sample of (open)SUSE users would >>> report as >>> "necessary" file systems. Without such a sample this proposed >>> change >>> appears quite reckless. >>> >>> >>> Best, Jim >>> >>> >>> On Thu, 2019-01-31 at 16:45 +0000, Jim Henderson wrote: >>>> On Thu, 31 Jan 2019 04:37:08 -0500, Felix Miata wrote: >>>> >>>>> And yet there are enough to manage to have an annual >>>>> convention: >>>>> http://www.warpstock.org/ >>>> >>>> I don't have a horse in this race, but going to the site for the >>>> Berlin >>>> 2018 conference doesn't make me think that this affects thousands >>>> of >>>> users. It makes me think it affects about 20. Small conference >>>> rooms, a >>>> relatively small lunch gathering. Makes me wonder what the >>>> actual >>>> attendance is. >>>> >>>> The solution is simple - remove the filesystem from the >>>> blacklist. Seems >>>> like a really easy thing to do for something that's used by 20 >>>> people. >>>> >>>> It's not like the filesystem module is not being built or >>>> included. >> >> In terms of local file systems, the vast majority of users use: >> ext2/3/4, xfs, btrfs, and reiserfs[1]. OCFS2 and GFS2 are common >> enough >> that I wouldn't want to blacklist them. JFS saw some use in the past >> but it was never particularly popular since it was the disk format >> used >> by OS/2 and not the AIX version. My opinions on it aren't >> new[2]. The >> rest are for compatibility with now-ancient or otherwise uncommon >> OSes, >> for pure flash (ie: without an FTL) media, or have other maintenance >> issues (f2fs). Are there users out there for any of these? I'm sure >> there are a handful. I just don't think it's worth leaving the >> attack >> surface open for the vast majority of users to accommodate a few -- >> especially if we can minimize the impact on the few. >> >> Now that I look at it again, the list was composed using the file >> systems we build on SLE15. There are two others that should be >> added: >> omfs >> ntfs[3] >> >> -Jeff >> >> [1] I expect this will go on the blacklist at some point in the >> future >> as I'm the last person to do any real work on it and I have other >> priorities that take precedence. >> [2] >> https://sourceforge.net/p/jfs/mailman/jfs-discussion/thread/fpps5p$g2t$2@sa… >> -- I'm assuming the staff member was me in this case. Dave also says >> that he tries to fix bugs but the hard ones go unfixed. This was 11 >> years ago. >> [3] Not that NTFS isn't widely used; Just that the only attention >> that >> the ntfs kernel module has has seen since 2007 has been for tree-wide >> cleanups and API changes. Use ntfs-3g instead. Please observe the list convention and refrain from top-posting. We don't have specific data because we don't do install tracking beyond the standard http logs which don't yield anything more concrete than the number of unique users who downloaded a package. If you'd like to propose deeper, more fine-grained statistics, you're welcome to lead that discussion. This is anecdata based on experience. I've been a contributing member of the Linux file system community for 19 years and have led the SUSE kernel file system team for the last 12. All software has bugs and the lack of bug reports for e.g. befs doesn't mean that it's perfect. It means so few people use it that they're not hitting any. Mailing list activity may also be decent metric of activity and popularity. The btrfs list had 12600 message last year and 897 messages since 1 January 2019. The XFS last had 10200 message last year and 571 since the start of 2019. I don't keep an archive of the ext4 list, but some screen scraping says about 4700 messages last year and 330 message this year so far. I wouldn't use these numbers to /rank/ popularity, but they're sufficient to show that the communities are still active. In contrast, the JFS list had 229 messages last year, most of which were courtesy CC's for tree-wide API changes. ReiserFS had even fewer, but it was our default file system for several years (and, as I said, it'll be added eventually). In terms of commit activity, qnx6 has been largely untouched since it's initial commit in 2012. The last time the qnx4 maintainer committed code he wrote was in 2009 and that was to remove write support entirely. All changes since then have been janitor-style changes. The last substantial changes to adfs were in 2011. I know HFS is unmaintained because I saw a CVE relating to it show up this year and everyone shrugged. The list reflects reality and the blacklist is the most user-friendly solution to shrink the attack surface while allowing flexibility of deployment. -Jeff -- Jeff Mahoney SUSE Labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years, 9 months

Re: [opensuse-factory] Issues starting Docker

by Michael Aquilina

uname -a Linux linux-9wl3 4.16.8-1-default #1 SMP PREEMPT Wed May 9 10:29:52 UTC 2018 (9269cc1) x86_64 x86_64 x86_64 GNU/Linux docker -v Docker version 17.09.1-ce, build f4ffd2511ce9 journalctl -u docker.service -xe -- Subject: Unit docker.service has begun start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit docker.service has begun starting up. May 29 11:38:53 linux-9wl3 dockerd[6894]: time="2018-05-29T11:38:53.414094253+01:00" level=info msg="[graphdriver] using prior storage drive> May 29 11:38:53 linux-9wl3 dockerd[6894]: time="2018-05-29T11:38:53.433686430+01:00" level=info msg="Graph migration to content-addressabili> May 29 11:38:53 linux-9wl3 dockerd[6894]: time="2018-05-29T11:38:53.433909179+01:00" level=warning msg="Your kernel does not support swap me> May 29 11:38:53 linux-9wl3 dockerd[6894]: time="2018-05-29T11:38:53.433943125+01:00" level=warning msg="Your kernel does not support cgroup > May 29 11:38:53 linux-9wl3 dockerd[6894]: time="2018-05-29T11:38:53.433951788+01:00" level=warning msg="Your kernel does not support cgroup > May 29 11:38:53 linux-9wl3 dockerd[6894]: time="2018-05-29T11:38:53.434331950+01:00" level=info msg="Loading containers: start." May 29 11:40:23 linux-9wl3 systemd[1]: docker.service: Start operation timed out. Terminating. May 29 11:40:23 linux-9wl3 dockerd[6894]: time="2018-05-29T11:40:23.437326237+01:00" level=info msg="Processing signal 'terminated'" Unfurtunately journalctl does not seem to provide much more details than that :/ I tried running dockerd directly with debug mode and got the following message: sudo dockerd -D DEBU[2018-05-29T11:38:43.432709369+01:00] Listener created for HTTP on unix (/var/run/docker.sock) Failed to connect to containerd. Please make sure containerd is installed in your PATH or you have specified the correct address. Got error: exec: "docker-containerd": executable file not found in $PATH Searching for `docker-containerd` on my file system with the find utility showed no results. But I can run containerd as a service with no issues: sudo systemctl start containerd journalctl -u containerd.service -xe May 29 11:29:38 linux-9wl3 systemd[1]: Started Containerd Standalone OCI Container Daemon. -- Subject: Unit containerd.service has finished start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit containerd.service has finished starting up. -- -- The start-up result is RESULT. On Tue, May 29, 2018 at 11:41 AM, Antonio Ojea <aojeagarcia(a)suse.com> wrote: > The log message says "Your kernel does not support cgroup >" , can you > obtain the full line with the "journalctl -xe"command? > > Also, what kernel and docker version are you using? > > On 29/05/2018 12:16, Michael Aquilina wrote: >> Is anyone else experiencing issues starting up the docker daemon? >> >> sudo systemctl start docker >> Job for docker.service failed because a timeout was exceeded. >> See "systemctl status docker.service" and "journalctl -xe" for details. >> >> systemctl status docker.service >> ● docker.service - Docker Application Container Engine >> Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; >> vendor preset: disabled) >> Active: failed (Result: timeout) since Tue 2018-05-29 11:11:06 BST; 9s ago >> Docs: http://docs.docker.com >> Process: 24544 ExecStart=/usr/bin/dockerd --containerd >> /run/containerd/containerd.sock --add-runtime >> oci=/usr/sbin/docker-runc $DOCKER_NETW> >> Main PID: 24544 (code=killed, signal=KILL) >> >> May 29 11:08:06 linux-9wl3 dockerd[24544]: >> time="2018-05-29T11:08:06.532027695+01:00" level=warning msg="Your >> kernel does not support cgroup > >> May 29 11:08:06 linux-9wl3 dockerd[24544]: >> time="2018-05-29T11:08:06.532087206+01:00" level=warning msg="Your >> kernel does not support cgroup > >> May 29 11:08:06 linux-9wl3 dockerd[24544]: >> time="2018-05-29T11:08:06.533562226+01:00" level=info msg="Loading >> containers: start." >> May 29 11:09:36 linux-9wl3 systemd[1]: docker.service: Start operation >> timed out. Terminating. >> May 29 11:09:36 linux-9wl3 dockerd[24544]: >> time="2018-05-29T11:09:36.418326793+01:00" level=info msg="Processing >> signal 'terminated'" >> May 29 11:11:06 linux-9wl3 systemd[1]: docker.service: State >> 'stop-sigterm' timed out. Killing. >> May 29 11:11:06 linux-9wl3 systemd[1]: docker.service: Killing process >> 24544 (dockerd) with signal SIGKILL. >> May 29 11:11:06 linux-9wl3 systemd[1]: docker.service: Main process >> exited, code=killed, status=9/KILL >> May 29 11:11:06 linux-9wl3 systemd[1]: docker.service: Failed with >> result 'timeout'. >> May 29 11:11:06 linux-9wl3 systemd[1]: Failed to start Docker >> Application Container Engine. >> >> This was working the last time I tried, so I'm not entirely sure >> what's going on. >> >> I even tried re-installing docker itself as well as deleting all of >> /var/lib/docker - but I still get the same issue. >> >> Mike > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > -- > To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org > -- Michael Aquilina -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 years, 5 months

Re: [opensuse-factory] New submit request workflow for Jump, publicly available builds

by Simon Lees

On 9/2/20 7:55 AM, Christian Boltz wrote: > Hello, > > Am Montag, 31. August 2020, 13:14:04 CEST schrieb Simon Lees: >> On 8/18/20 6:19 AM, Christian Boltz wrote: >>> Am Montag, 10. August 2020, 12:22:50 CEST schrieb Lubos Kocman: > > [Community access to Jira] >>>> We'll initially have rather a smaller pool of users (initially 10) >>>> and will grow it over time based on the popularity. Just FYI: The >>>> standard size of the pool for partners is 2, so openSUSE is being >>>> taken seriously as a partner here. >>> >>> Let me play devil's advocate, and also warn you that the following >>> paragraph might contain traces of sarcasm ;-) >> >> Let me maybe play devil's advocate back. > > That's fine, I already wondered if/why nobody dares to answer ;-) > I was off sick :-) >>> In the good [1] old times ;-) of FATE (aka features.o.o), >>> _everybody_ >>> was able to submit a feature request and to see feature requests by >>> community members. And now you are telling us that we should be >>> thankful that 10 selected people will get access, and maybe that >>> number will increase? Of course, 10 is better than nobody, but IMHO >>> the perfect number of people allowed to access Jira would be ∞ ;-) >> >> I think the problem here was more while everyone could create a >> feature request, no one was reading them let alone thinking about >> implementing them, > > I know this was a problem, but - playing devil's advocate again - why > should this be different/better just because we switch to another tool? Its less about switching to another tool and more about the fact that SUSE is committing resource to do this job now (they weren't doing so in the openSUSE instance of open fate). > And I still think only allowing 10 community members to access Jira > would be a serious problem. Agreed. I believe 10 people is an "Initial pilot program" and it will open up further in the future. >> atleast now they are going into a tool where >> someone will probably look at them, let the maintainer know about >> them and maybe provide some feedback. > > I guess that still needs someone who assigns the request to the > maintainer, so where's the difference to FATE/openFATE? > Yep as I said above SUSE has committed to dedicating resource to do this in the same way as they do for there partners, the difference is SUSE no longer uses FATE to do this so using fate would create 2 different processes rather then one. >>> Allowing everybody to access JIRA could have benefits for both SUSE >>> and the community. For example, with more people having access, >>> maybe someone would accidently stumble over a feature request, and >>> help to implement it? Or someone comes up with an idea for _the_ >>> feature that would generate lots of money for SUSE, but doesn't >>> want to do the paperwork to get access to JIRA? >> >> It would have benefits, but I'm not sure they outweigh the excessive >> costs that would be required to purchase a license that would allow >> every member of the community simultaneous access. >> >> I guess when the product management team were considering the tool >> they wanted to use they didn't consider needing that number of >> licenses and considered a bunch of features jira provides over the >> competition as really important. > > I can't imagine (well, at least I hope) that the product management team > didn't have openSUSE in mind when choosing Jira over $alternatives. > > But if the costs are the only problem you see - AFAIK Atlassian also > provides a community license [1]. I don't know the exact conditions and > requirements, but in general, we could ask for a community license for > openSUSE, which should help to solve the costs argument. > > And even if openSUSE doesn't qualify for a community license for > whatever strange reason, I still think that giving access to all > communiy members would be worth the price. We don't qualify this discussion was already had. Part of the reason is openSUSE doesn't have an independent legal structure, another part I think was we are too tightly tied to SUSE there may have been other reasons. I only heard these third hand but my impression was that because we don't have a foundation its easy for them to say no, but even if we did have a foundation they'd probably find other ways to say no. > [ Personally I wonder why we (both SUSE and openSUSE) need a separate > tool for tracking feature requests at all. I'd simply do everything in > bugzilla, maybe with a separate "feature requests" product. And yes, I'm > aware that bugzilla doesn't let managers do their paperwork (or > "workflow") games they like so much in FATE and now Jira and ECO ;-) ] Beyond that our current bugzilla doesn't have fine grain enough access control on issues among other things, I also believe due to time constraints developing something internally was out of the question and I believe they equally wanted a system they didn't have to host and maintain in house. >>> I also have a question: which feature requests will the selected >>> openSUSE contributors be able to see? Those reported by other >>> openSUSE contributors (would be similar to FATE/features.o.o), or >>> also feature requests reported by other partners? >>> (You can probably guess my prefered answer, but I also understand >>> that other partners might want to have their requests kept >>> private.) >> My guess is GDPR will mean that only the later, and its reasonable to >> expect that some others are under NDA so certainly not all. > > Please don't abuse GDPR as an argument ;-) > GDPR always has the option of permitting something, so if some partners > are willing to make their requests public, GDPR won't stop them. Yep but that requires support in the tooling to ask this option :-) Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

4 years, 2 months

SOLVED!! Re: [opensuse-factory] New Tumbleweed snapshot 20191203 released!

by Manvendra Bhangui

My issue with my system booting to runlevel 3 instead of getting a graphical display got solved. I had a systemd script which would detect if a monitor was connector or not. If no monitor was found, the system would boot to runlevel 3. I was using a utility monitor-get-edid command to check this. For some reason, the command is returning non-zero during boot, as if monitor is not connected. Apologies for raising this which was actually a self created issue. I forget about this systemd service because I had created it more than an year back and totally forgot that this script could be responsible for booting into runlevel 3. On Thu, 5 Dec 2019 at 17:56, Manvendra Bhangui <mbhangui(a)gmail.com> wrote: > > On Thu, 5 Dec 2019 at 15:04, Dominique Leuenberger <dimstar(a)suse.de> wrote: > > > > > > Please note that this mail was generated by a script. > > The described changes are computed based on the x86_64 DVD. > > The full online repo contains too many changes to be listed here. > > > > Please check the known defects of this snapshot before upgrading: > > https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… > > > > Today I updated to the above release and after reboot the machine > boots to runlevel 3. The graphical desktop doesn't start > automatically. I have to login on the console or by ssh and manually > issue the command "sudo init 5" to bring up the graphical desktop. > What should I do to fix this issue? Any pointers? > > $ cat /etc/os-release > NAME="openSUSE Tumbleweed" > # VERSION="20191203" > ID="opensuse-tumbleweed" > ID_LIKE="opensuse suse" > VERSION_ID="20191203" > PRETTY_NAME="openSUSE Tumbleweed" > ANSI_COLOR="0;32" > CPE_NAME="cpe:/o:opensuse:tumbleweed:20191203" > BUG_REPORT_URL="https://bugs.opensuse.org" > HOME_URL="https://www.opensuse.org/" > LOGO="distributor-logo" > > $ systemctl get-default > graphical.target > > Some lines from journalctl > > Dec 05 17:45:45 MediaCenter systemd[2447]: Reached target Timers. > Dec 05 17:45:45 MediaCenter systemd[2447]: Starting D-Bus User Message > Bus Socket. > Dec 05 17:45:45 MediaCenter systemd[2447]: Listening on Sound System. > Dec 05 17:45:45 MediaCenter systemd[2447]: Listening on D-Bus User > Message Bus Socket. > Dec 05 17:45:45 MediaCenter systemd[2447]: Reached target Sockets. > Dec 05 17:45:45 MediaCenter systemd[2447]: Reached target Basic System. > Dec 05 17:45:45 MediaCenter systemd[2447]: Reached target Main User Target. > Dec 05 17:45:45 MediaCenter systemd[2447]: Startup finished in 602ms. > Dec 05 17:45:45 MediaCenter systemd[1]: Started User Manager for UID 1000. > Dec 05 17:45:45 MediaCenter systemd[1]: Started Session 1 of user mbhangui. > Dec 05 17:45:46 MediaCenter kernel: fuse: init (API version 7.31) > Dec 05 17:45:46 MediaCenter systemd[1]: Mounting FUSE Control File System... > Dec 05 17:45:47 MediaCenter systemd[1]: Mounted FUSE Control File System. > Dec 05 17:45:47 MediaCenter systemd[1]: > NetworkManager-dispatcher.service: Succeeded. > Dec 05 17:45:56 MediaCenter systemd[1]: Started Music Player Daemon. > Dec 05 17:45:56 MediaCenter systemd[1]: Reached target Multi-User System. > Dec 05 17:45:56 MediaCenter systemd[1]: Starting Update UTMP about > System Runlevel Changes... > Dec 05 17:45:56 MediaCenter systemd[1]: > systemd-update-utmp-runlevel.service: Succeeded. > Dec 05 17:45:56 MediaCenter systemd[1]: Started Update UTMP about > System Runlevel Changes. > Dec 05 17:45:56 MediaCenter systemd[1]: Startup finished in 3.547s > (kernel) + 3.351s (initrd) + 51.701s (userspace) = 58.600s. > Dec 05 17:45:59 MediaCenter systemd[1]: systemd-hostnamed.service: Succeeded. > Dec 05 17:46:17 MediaCenter systemd[1]: Reloading. > Dec 05 17:46:17 MediaCenter systemd[1]: > /usr/lib/systemd/system/auditd.service:12: PIDFile= references a path > below legacy directory /var/run/, updating /var/run/auditd.pid → > /run/auditd.pid; please update the unit fi> > Dec 05 17:46:17 MediaCenter systemd[1]: > /usr/lib/systemd/system/display-manager.service:12: PIDFile= > references a path below legacy directory /var/run/, updating > /var/run/displaymanager.pid → /run/displaymanager.pid; > > Dec 05 17:46:17 MediaCenter systemd[1]: > /usr/lib/systemd/system/rpc-statd.service:15: PIDFile= references a > path below legacy directory /var/run/, updating /var/run/rpc.statd.pid > → /run/rpc.statd.pid; please update th> > Dec 05 17:46:17 MediaCenter systemd[1]: > /usr/lib/systemd/system/ntpd.service:15: PIDFile= references a path > below legacy directory /var/run/, updating /var/run/ntp/ntpd.pid → > /run/ntp/ntpd.pid; please update the unit > > Dec 05 17:46:17 MediaCenter systemd[1]: > /usr/lib/systemd/system/pcscd.socket:5: ListenStream= references a > path below legacy directory /var/run/, updating > /var/run/pcscd/pcscd.comm → /run/pcscd/pcscd.comm; please upda> > Dec 05 17:46:25 MediaCenter sudo[2555]: mbhangui : TTY=pts/0 ; > PWD=/home/mbhangui ; USER=root ; COMMAND=/usr/bin/svstat > /service/dietpi /service/droidmote /service/glava /service/panalpd > /service/panascan > Dec 05 17:46:25 MediaCenter sudo[2555]: pam_unix(sudo:session): > session opened for user root(uid=0) by mbhangui(uid=0) > Dec 05 17:46:36 MediaCenter sudo[2561]: mbhangui : TTY=pts/0 ; > PWD=/home/mbhangui ; USER=root ; COMMAND=/usr/sbin/init 5 > > The graphical desktop starts only after issuing the above init command -- Regards Manvendra - http://www.indimail.org GPG Pub Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 11 months

Re: [opensuse-factory] M5 Release Notes published.

by Dave Plater

On 04/14/2010 12:38 PM, Sid Boyce wrote: > On 14/04/10 07:16, James Mason wrote: > >> Release Notes for openSUSE 11.3 Milestone 5 are (finally) up on News.o.o. : >> http://news.opensuse.org/2010/04/14/opensuse-11-3-milestone-5-the-community… >> >> Please head over to the Annoying Bugs list and make any necessary updates: >> http://en.opensuse.org/Bugs:Most_Annoying_Bugs_11.3_dev#openSUSE_11.3_Miles… >> >> ----- >> openSUSE 11.3 Milestone 5: The Community Strikes Back >> Wednesday, April 14th, 2010 by James Mason >> >> Milestone 5 (of 7), a snapshot of the Factory “work in progress” >> build, leading up to openSUSE 11.3 release in July, is now available >> for download. >> >> M5 was marked by significant contributions from both the openSUSE >> Community, and the larger Linux community. We’ve added some >> interesting new packages, made some updates to core processes, and >> participated in a coordinated multi-distribution upgrade of a major >> multimedia component. Over 50 bugs were fixed and 8 new features were >> implemented. >> Release News: >> >> * Update to Perl 5.12 (release notes) >> * Update to parted 2.2; M5 has a complete toolkit for supporting >> 4K phyisical sector disks. (openSUSE-factory list) >> * KMS integration for Intel and Nvidia (via nouveau driver) >> graphics, and the ability to disable it. (bugzilla 591400) >> * Update to PackageKit 0.6.2, requiring revisions to KPackageKit >> (openSUSE-factory list) >> * Added librcd and librcc, which provide on-the-fly language >> translation/detection, from the RusXMMS project. (openSUSE-factory >> list) >> * Added xdiskusage, a visual disk-space analyzer. (openSUSE-factory list) >> * A bug in OpenOffice.org that caused crashes when copying >> spreadsheet cells has been resolved. (bugzilla 588957) >> * Access to the official SUSE manuals has been improved. (bugzilla 586682) >> * Documentation has been corrected for the smbfs to cifs changes. >> (bugzilla 561993, bugzilla 578621) >> * The installation slideshow now talks about version 11.3 instead >> of 11.2. (bugzilla 588396) >> * Lithuanian keyboard layout added. (bugzilla 569554) >> * Encrypted swap volumes no longer need to be formatted during >> install; YaST will prompt for LUKS volume passwords. (bugzilla 581341) >> * A locking issue with reiserfs has been resolved and no longer >> prevents installs. (bugzilla 591807) >> * An M4 annoyance with udev init scripts has been fixed. (bugzilla 592445) >> >> System Administrators: >> >> * ssh now shows a visual fingerprint on all relevant activities, >> and the .ssh/known_hosts file is hashed for increased security. >> (openSUSE-factory list) >> * cron has been replaced by cronie, which ships as cron-1.4.4 >> (openSUSE-factory list) >> * pam_mount updated to the latest stable version (1.2.4, libHX >> 2.7). (openFATE 305351, bugzilla 438457) >> * KVM/qemu SDL windows no longer freeze. (bugzilla 586260) >> >> Developers/Packagers: >> >> * Update to rpm 4.8.0 (release notes) >> * Update to zypper 1.4.1 resolves issues with ‘zypper ref’ and >> ‘zypper up’. (bugzilla 586979, bugzilla 591760) >> * Update to NetBeans 6.8 in Java:packages. (bugzilla 593600) >> * rpmlint properly finds RPM_BUILD_ROOT again. (bugzilla 584952) >> >> Multimedia Authors: >> >> * The JACK team is coordinating with openSUSE, Ubuntu, and Debian, >> among others, to upgrade to jack 1.9.5 (JACK2) during the >> spring/summer release cycle. (openSUSE-factory list) >> * lilypond is now in multimedia:apps, to support rosegarden4. >> (openSUSE-factory list) >> >> GUI Users: >> >> * Update to X11 7.5 & xorg-server to 1.8.0. (openFATE 306903, >> bugzilla 586157, bugzilla 586350, bugzilla 587514, bugzilla 576481, >> bugzilla 593878) >> * Added nouveau driver for Nvidia graphics. (openFATE 307588) >> * VMWare mouse drivers are functioning again. (bugzilla 574857, >> bugzilla 592193) >> * Update to gutenprint 5.2.4 with support for many new printer >> models. (openFATE 309091) >> * An hplip update resolves deprecation issues related to udev. >> (bugzilla 577035) >> * Update to PCManFM’s (a lightweight file manager) >> libfm-0.1.9beta resolves some file access issues. (bugzilla 591731) >> * xscreensaver-recommended only installs a recommended subset of >> screensavers, and is selected by default instead of >> xscreensaver-extras. (openFATE 308474) >> * iwl3945 (an Intel Wireless LAN driver) no longer needs to be >> reloaded after NetworkManager startup. (bugzilla 586711) >> * Gnome 2.30 ’About Me’ no longer looses information. (bugzilla 588172) >> * gnome-keyring works properly under LXDE. (bugzilla 580043) >> * Update to gnuplot 4.4. (bugzilla 592563) >> * Update to seamonkey 2.0.4. (bugzilla 592587) >> >> Mobile Users: >> >> * Update to pm-utils to 1.3.0; power management utilities now use >> udisks/upower and have no dependencies on HAL; video quirks are >> included. (openSUSE-factory list) >> * NetworkManager has support for PEAP with Generic Token Card >> (PEAP-GTC). (openFATE 309158) >> * Uacklight controls are working in MacBooks with Intel graphics. >> (bugzilla 581474) >> >> Gamers: >> >> * Added Dungeon Crawl (a nethack clone) to the Games repository. >> (openSUSE-factory list) >> >> Testing! Testing! Testing! >> >> As this is a milestone release, 11.3 M5 does contain bugs that we know >> about, but should not stand between courageous contributors and >> release testing. Some of the most critical bugs are listed on the >> wiki. >> >> Get Milestone 5 Today! >> >> What are you waiting for? Grab the milestone release from >> software.opensuse.org/developer today! >> ----- >> >> - James Mason 'bear454' >> > I keep reading about updates to factory, stuff pushed out to mirrors > like jack-1.9.5 which is still at 0.118, etc. but I've not seen other > than initrd* dated 12th. and most other stuff 7th. and 8th. on > http://download.opensuse.org/factory/repo/oss/suse/x86_64/ > Regards > Sid. > jack-1.9.5 hasn't been built for snapshot yet and standard is looking for python-base, I would have thought milestone 5 would be reflected in snapshot obviously not. Regards Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

14 years, 7 months

Re: [opensuse-factory] 11.2MS8 latest updates not playing nice with ATI

by Juan Erbes

2009/10/19 Peter Nikolic <p.nikolic1(a)btinternet.com>: > On Sunday 18 Oct 2009 21:56:28 Juan Erbes wrote: >> 2009/10/18 Daniel Fuhrmann <schoppehaller(a)vr-web.de>: >> > Am Sonntag 18 Oktober 2009 21:47:20 schrieb Peter Nikolic: >> >> On Friday 16 Oct 2009 05:22:11 David C. Rankin wrote: >> >> > On Saturday 10 October 2009 02:19:25 am Peter Nikolic wrote: >> >> > > On Saturday 10 Oct 2009 00:57:11 Rajko M. wrote: >> >> > > > On Friday 09 October 2009 01:53:37 Peter Nikolic wrote: >> >> > > > > Wrong machine ;-) >> >> > > > >> >> > > > Could be. I'm running M8 + Factory, but what I have forgotten is >> >> > > > that I use xorg.conf while by default M8 doesn't. Try to run 'sax2 >> >> > > > -m 0:radeon' and see if that solves problem. >> >> > > >> >> > > Nope seems it runs deeper than that after shutting the machine down >> >> > > over night it now will not boot init 5 only init 3 i can then >> >> > > SOMETIMES get X top run and KDE up but sure as i try to do anything >> >> > > it just bombs out to the login . >> >> > > >> >> > > will have to try doing another zypper dup in a couple of days see if >> >> > > anything has been CORRECTED ! as it is plainly a failure to test >> >> > > something to a reasonable standard before it is pushed out . 11.0 >> >> > > still works ok so it is not an hardware problem . this is not some >> >> > > strange unusual machine it is a very common Compaq Presario V5030 >> >> > > sold by the truck load >> >> > > >> >> > > Pete >> >> > >> >> > Pete, >> >> > >> >> > Best you are going to do for your card is to go grab the latest >> >> > radeonhd code from the git repository (and drm) and build drm and the >> >> > radeonhd driver and install it. Simple enough. Just follow the >> >> > directions at: >> >> > >> >> > http://wiki.x.org/wiki/radeonhd >> >> > >> >> > Much better performance than the standard radeon or ati driver but >> >> > still 600% poorer performance than the fglrx driver. Also heating is a >> >> > problem with all drivers except the fglrx driver because the >> >> > opensource drivers lack the proprietary downclocking and gpu powerdown >> >> > of the fglrx driver. You will notice the difference on your >> >> > palmrest... >> >> >> >> Hi All >> >> >> >> well been away for a few days (no computers no phones no noise no >> >> hassles ) I have updated the lappy to to the RC1 still strange when >> >> booting if i boot to init 3 log in as root then run init 5 i can log >> >> into KDE ass user no problem and i seems to behave ok no konki crash >> >> and the video driver (radeon) as supplied does not seem to be tooo bad >> >> ! bit snails pace but works . >> >> However if i try to boot straight into graphics mode it freezes just >> >> after HAL and will not respond to anything but a hard reset , Cant find >> >> anything in the logs of use at all so ideas as to just how to go about >> >> trying to find out what is going on please .. >> > >> > Same for me here, radeon xpress 200m. Sometimes it boots into X but only >> > randomly. Thougt it is the grafik driver and waiting for fglrx. ready for >> > 11.2 >> > >> > :( nu success with compiling. Running sax 2 and creating xorg.conf brings >> > : no >> > >> > improvement. >> >> It depends of the model of Your ATI video card. If the model is <2400, >> the latest driver You can use, is Catalyst 9.3. If the model video >> card is >2400, You can use the latest driver, but for example for 9.8, >> it need a few retouching in a source file: >> >> https://bugzilla.novell.com/show_bug.cgi?id=535216#c6 >> >> After a install atempt with sh ati-driver-installer-9-8-x86.x86_64.run, to >> recreate the files in /lib/modules/fglrx, I removed the if rutine related >> to "p = find_task_by_vpid(pid);" >> The source file to edit is: >> /lib/modules/fglrx/build_mod/firegl_public.c >> >> deletting the if routine "p = find_task_by_vpid(pid);" >> >> they was about four lines, and remaked the kernel >> module with >> /lib/modules/fglrx/build_mod # ./make.sh >> >> And later called: >> >> /lib/modules/fglrx # ./make_install.sh >> >> I try to load the module: >> >> modprobe fglrx >> >> I got no errors. >> >> Then I configured the driver with the aticonfig command. >> >> Regards, >> Juan > > the model is M200 PCIE is 9599 so 2400 ect is what ? no sucj numbers on > this card .. > If the model is Radeon 9599, the nearest model in the driver selection is Radeon 9550, then the latest version You use, is 9.3, because the chip is earlier than the 2400 http://support.amd.com/la/gpudownload/linux/Legacy/Pages /radeon_linux.aspx?type=2.4.1&product=2.4.1.3.25&lang=English https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/catalyst_… The supported chips by the latest Catalyst driver, are the video chips > R600 http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units#Ra… Regards -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

15 years, 1 month

Re: [opensuse-factory] Religious and political views in packages

by Greg Freemyer

Guys, If you move the atheism vs primordial creator discussion to opensuse-offtopic I'll join in. But this is not the place for it. Greg On Mon, Sep 12, 2011 at 1:44 PM, phanisvara das <listmail(a)phanisvara.com> wrote: > On Mon, 12 Sep 2011 21:07:58 +0530, Alin Marin Elena <alinm.elena(a)gmail.com> > wrote: > >> in a general sense all of us are believers. all system of thoughts are >> based on believing something... or if you want to be scientific,assuming >> some hypothesis. This is the place where the believers start >> to split... in what I like to think dogmatic and critical thinkers. >> >> the science which is the example you used... indeed starts with the >> statement there is X... and then puts all the machinery of critical >> thinking to establish some value of true or false to that statement... >> if true... the machinery continues and nice consequences areobtained... >> making your life better. if false a new statement is >> generated and the critical thinking process continues... >> >> the problem with the statement there is a god... or if you want in >> a more philosophical manner, there is a primordial cause... is that >> once one applies the critical thinking process the outcome is the >> there is a god or there is not god... cannot be proved... > > > yes, it's beyond our ability to prove, or even to understand. people xxx > years ago couldn't have conceived of electricity, or whatever. there are > things we can't wrap our mind around, which aren't subject to the scientific > process we understand; doesn't mean they can't exist. > > >> The critical thinker... will say... I cannot use something I cannot >> prove to get a system of thoughts... the dogmatic believer will say >> there is a god... and then build his system of thoughts... with >> the consequences that we see today... probably Nietzsche put it the best >> with his God is dead. > > > since it can't be proven either way with the means at our disposal, saying > "yes, there's god," or "no, there isn't one" are equally supported by > scientific evidence. it _is_ a question of belief, either way. now there's > plenty of quotes from scientists like altbert einstein and god knows how > many others [pun intended], and equally or more quotes of others saying the > opposite. confirms the 'scientific' result: is a matter of faith (and not > only idiots believe). > > unfortunately there are idiots in all of these camps, and they'll as happily > misuse religious sentiments (belief based on faith only, without critical > thinking) as they misuse results of scientific research that weren't really > meant for bad purposes. > > >> Of course you will find well versed believers how will tell you... that >> science cannot give you a moral system... law of gravitation will not tell >> you what is good to eat... to rich heaven. indeed moral systems >> come from ethics... And ethics is fully under the governance of critical >> thinking... and absurd outcomes are discarded.. > > > in my opinion that should be applied to any moral code, if it's based on > religious traditions or not. we, humans, are apt to make mistakes and worse: > use anything to our own advantage. there has to be critical thinking. > > >> On the other hand certain system of thought, of religious inspiration will >> not change their moral rules even when the absurdity is shown via >> the critical thinking process and they will dismiss the outcome on the >> base of work of devil, devils, negative forces. In past times and even >> nowadays religion equates ethics in certain spaces, as source of >> moral... and that is in my humble opinion a sorry state. > > > i agree. i don't see it as "the work of religion," but as the work of bad or > selfish people. if they use religion or something else depends on what's > available. do you really think they fought those crusades because they > believed in god, or was it for the plunder and whatever political gains they > wanted to achieve? are the polititians of a certain super-power fighting the > "axis of evil" only for moral reasons? > > >> Now you may come with the argument that many people cannot be wrong, >> and there are plenty being religious around. > > > ahem, i didn't make this argument and don't support it. > > >> I will invite them, then to see if a >> statement like that stands the critical thinking process. >> Who were the wrongs or the rights? The Christian who massacred Muslims or >> the Muslims who massacred the Christians. these are just simple facts >> that happened in the last 1000 years in Europe and Middle East. The >> Hindus who hacked to pieces Muslims or the Muslims who hacked to pieces >> Hindus... that was sometime in the last 100 years on the Indian >> subcontinent.. and all of them started simple by the fact that there is >> a god (in its various flavours) was assumed true by many. > > > in my opinion, that was not the reason for any of these massacres. it's that > people in general don't think very much, don't like to ask themselves and > others uncomfortable questions. talented people w/o scruples can misuse > that, and if there's no "religion" around, they'll use something else. it's > not that by abolishing religion you'll make people more critical; they'll > find something or somebody else to follow; they'll be made an "offer they > can't refuse." > > >> And of course >> one can give a lot of examples of the absurdity that assuming true a >> statement like there is a god! > > > ...and the other way around. > > >> Personally I think more the religious ideas are exposed to critical >> thinking better for society... more people are allowed to question them >> faster the society will move towards a better place... but maybe all >> this is just wishful thinking... > > > and here i finally agree with you. there's so much BS around, not only but > also in the garb of religion. > > > -- > phani. > -- > To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org > For additional commands, e-mail: opensuse-factory+help(a)opensuse.org > > -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrie… The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

13 years, 2 months

Re: [opensuse-factory] Re: 2 questions concerning a recent kernel and hostname

by Sid Boyce

On 18/06/11 06:25, Linda Walsh wrote: > Donn Washburn wrote: >> Group; >> >> 1. Over the past 15 years I have downloaded and compiled about every >> kernel basic and git from www.kernel.org and gotten them to work. I >> have changed the CPU to match this one and the default name using >> make menuconfig. I have tried over and over recently with no luck >> and openSuSE. Using oldconfig and /proc/config.gz as .config and >> make menuconfig. Both work just fine but mkinitrd fails - even >> though the modules are built and installed in /lib/modules/. Both >> openSuSE supplied kernel source and kernel.org kernels fail and have >> even cause this system to need reloading from scratch. >> >> 2. I have gone through all gyrations looking for why at a login I get >> no hostname but (none). And Apache2 complains about (none) at boot >> time. The happened before and was fixed in 11.4 one of alpha/beta >> versions but it is again broken > ---- > I had similar problems when I upgraded, I think it was to the 11 > series (as I also build my own kernel from kernel.org configed for my > hw)... > > It was when they switched to grub and putting everything on a > RAMDISK to boot from and started thinking they could totally go with > file-labels instead of /dev/sda3 -- including at boot.... > > I never was able to get it to work right with the suse framework, > because, in order to give the illusion of booting by the 'name' of the > partition, rather than using /dev/sda3, they basically have to boot a > miniroot of sorts to read the labels, and that all has to be on the > boot-ram disk. Once I switched back to lilo, (I use XFS BTW, for all > my disks, including the boot disk -- have since maybe suse 7-8 > timeframe). > > I did run into a problem in some of the recent kernels with the boot > code not fitting in the boot area, but a new version of lilo has solved > that now as well. > > I'm not saying it can't be done -- I needed my system working again > ASAP, so I didn't have weeks to look at debugging the issue. It's > frustrating too -- since if I don't use their grub setup, I can't get > the suse kernels to load (suse hasn't kept up lilo and was actually > claiming a bug in grub was the fault of xfs -- so they dropped support > for xfs for a while...until some people vehemently pointed out the bug > was in grub (modifying a live-mounted file system?! You've got to be > kidding!!).... > > Anyway, Would be nice if they had the resources to make > everything play nice together, but it's a matter of them using the tools > they are most familiar with and not having the cycles to do everything. > > Doesn't mean I don't continue to put in my voice about problems, > because a lilo boot of my kernel happens in 1/2-1/3 the time of a > standard suse boot from grub. > > > The last kernel problems I had going back a few months was with XFS where modules were being zeroed out on boot sometimes, so I moved to ext4. Donn, can you show us some output, mkinitrd failing says absolutely zero about how it's failing. What filesystem are you using? The previous vanilla kernels all worked as does the current one built minutes ago. slipstream:/home/lancelot/ftp/may11 # uname -r 3.0.0-rc3-git7-smp slipstream:/home/lancelot/ftp/may11 # cat /proc/driver/nvidia/version NVRM version: NVIDIA UNIX x86_64 Kernel Module 275.09.07 Wed Jun 8 14:16:46 PDT 2011 GCC version: gcc version 4.6.0 20110607 [gcc-4_6-branch revision 174741] (SUSE Linux) slipstream:/home/lancelot/ftp/may11 # # lsmod|grep vbox vboxnetadp 13382 0 vboxnetflt 28693 0 vboxdrv 238789 2 vboxnetadp,vboxnetflt I also have all sorts of weird stuff attached and working - SDR transceiver (Software Defined Radio), Logic analyser, VNA (Virtual Network Analyser). # cat /proc/asound/cards 0 [SB ]: HDA-Intel - HDA ATI SB HDA ATI SB at 0xf7df8000 irq 16 1 [Live ]: EMU10K1 - SB Live! 5.1 [SB0060] SB Live! 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xb880, irq 20 2 [DG8SAQI2C ]: USB-Audio - DG8SAQ-I2C www.obdev.at DG8SAQ-I2C at usb-0000:00:13.2-3.3, high speed # lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 001 Device 003: ID 148f:2573 Ralink Technology, Corp. RT2501/RT2573 Wireless Adapter Bus 002 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub Bus 002 Device 003: ID 050d:0307 Belkin Components Bus 006 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 005: ID 16c0:0478 VOTI Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 002 Device 005: ID 047d:2043 Kensington Bus 002 Device 006: ID 16c0:05dc VOTI shared ID for use with libusb Bus 002 Device 007: ID 0402:5602 ALi Corp. M5602 Video Camera Controller Bus 002 Device 012: ID 046d:c404 Logitech, Inc. TrackMan Wheel Bus 002 Device 013: ID 068e:00f2 CH Products, Inc. Flight Sim Pedals Bus 002 Device 014: ID 068e:00ff CH Products, Inc. Flight Sim Yoke Bus 001 Device 007: ID 0925:3881 Lakeview Research # cat /etc/SuSE-release openSUSE 12.1 Milestone 1 (x86_64) VERSION = 12.1 CODENAME = Asparagus So here I am, fat dumb and happy with everything functioning 100%. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

13 years, 5 months

openSUSE Factory search results for query "reproducible-builds"