Re: [arch-general] systemd-run --user does not work
On Tue, May 13, 2014 at 3:04 AM, Ismael Bouya wrote: > > [snip-explanation] > -- > Ismael > Thank you, Ismael. I've not yet implemented what you've suggested (been a bit busy), but I'll report back once I get the time to play with my laptop. I'm certain it works, as your explanation makes a lot of sense. -- Savyasachee Jha *"Aerodynamics is for people whodon't know how to build engines."*
[arch-general] Shouldn't libperconaserverclient provide and conflict with libmysqlclient?
When I try to change my database server from mariadb to percona-server I noticed that libperconaserverclient is going to be installed, but libmariadbclient isn't going to be removed. When looking further into the package function of libperconaserverclient [1] I noticed that libmysqlclient isn't provided nor conflicts with libperconaserverclient. However, in the package function of libmariadbclient [2] there are the following lines: conflicts=('libmysqlclient') provides=("libmysqlclient=$pkgver") Shouldn't these lines (or something like them) be in package_libperconaserverclient? If so, I'll file a bug report. Kind regards, Marcel [1] https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/percona-server#n73 [2] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mariadb#n69
Re: [arch-general] systemd-run --user does not work
Hi, I don't know if it's necessary to send the request upstream for the moment: They are busy moving things to kdbus (which is the kernel implementation of dbus, and not "KDE-dbus" as I thought initially). Things are actually slightly messed up currently (that's my opinion, when I spent time reading the systemd code to write my tutorial). The best thing to be sure that everything works is to make sure that all of your processes have the information about DBUS_SESSION_BUS_ADDRESS, and the same information (and that dbus --session is started also, of course). Some processes spawn a dbus when they cannot find one, which makes things harder to debug (because they won't complain but it won't work as expected as they will have their own bus and noone can talk to them. And you end with two dbus processes just for you) About the difference between systemd-run and systemctl: I didn't have a close look at the systemd-run code, but they seem to have a different way of implementing dbus connections (which might come from the comment above, or simply legacy code). And I also ran into trouble with systemctl when I didn't have the DBUS part (I cannot remember which kind of problems, but that's where I started to dive into details of systemd implementation) So to sum up: if you have it everywhere it works; so why not put it and forget about it (it's not so hard to ensure actually). -- Ismael signature.asc Description: Digital signature
Re: [arch-general] systemd-run --user does not work
On Mon, May 12, 2014 at 8:04 PM, Ismael Bouya wrote: > For me it works both with user and system. > > [skip instructions] > > (Note that your shell doesn't have to know the DBUS_SESSION_BUS_ADDRESS > variable) Thank you!! I have followed your instructions and it actually works, although I have to run: $ export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus before being able to run systemd-run. What I don't understand is why. Why "systemd-run" needs the dbus-session daemon while "systemctl" works perfectly fine without it? Both programs ultimately call to the same interface [0], don't they? After some investigation, it looks like the user systemd daemon creates a private dbus address in "/run/user/$(id -u)/systemd/private". Then, systemctl uses this private socket, while systemd-run uses the standard, session, dbus-daemon, if the systemd user daemon is able to connect to it (that's where I had failed but Ismael succeeded). Now, my question is: Why doesn't systemd-run use the private socket address, just as systemctl does? And now that we are into it, why is a separated program? Why not "systemctl run" or "systemctl transient-run"? Maybe too many different command-line options? Just to prove my point I managed to create a user transient unit without using the session bus, running this command: $ gdbus call -a unix:path=/run/user/$(id -u)/systemd/private -o /org/freedesktop/systemd1 -m org.freedesktop.systemd1.Manager.StartTransientUnit \ run-$RANDOM.service fail \ "[('ExecStart', <[('/usr/bin/ls', ['/usr/bin/ls','-l'], false)]>)]" \ "[]" Yes... it took me a while to get the right syntax ;-) Maybe I should move this as a request for upstream? -- Rodrigo [0]: http://www.freedesktop.org/wiki/Software/systemd/dbus/
[arch-general] Need some tips/help with kernel bisection
After the update to kernel 3.14 my laptop stopped suspending/hibernating properly. I have narrowed down the problem somewhat, but before I submit a bug upstream, I'd like to try and bisect the kernel to find exactly what broke things for me (and I suppose I might be asked by upstream to bisect the kernel anyway). I have never done this before, and I suppose there might be a few catches I should be aware of before I start what will be a time consuming process. My plan is to start with the current PKGBUILD for the kernel (or a PKGBUILD from AUR) and modify it a little for my needs. However I don't know if I should start with a kernel configuration file from the 3.13 series or if I can use the one that is used by the current kernel. I was thinking of making use of 'make localmodconfig' to cut down on the compilation time, but I don't know if there are any catches I should be aware of. Should I use 'make config' followed by 'make localmodconfig' or using only the later is ok? Can I compile the kernel on the same dir where I'm using 'git bisect' or is it advisable to clone that to a new dir and build in the new dir? In case compiling in place is ok, should I use 'make clean' before compiling a new kernel? Regarding patches, I suppose I shouldn't need to include any extra patches or are there any known needed patches required to build kernel 3.13? -- Mauro Santos
Re: [arch-general] archlinux kernel 3.14.2-1 Broadcom BCM4312 firmware-files not found
Am 13.05.2014 11:48, schrieb Martti Kühne: > On Fri, May 9, 2014 at 7:00 PM, Andreas Adelmann wrote: >> What have i done: >> reinstalled firmware b43-firmware-5.100.130 by using Kernel >> 3.14.1-1 and 3.14.2-1 - no success. >> > > Only reinstalling the module won't do. You need to recompile for every kernel. > > cheers! > mar77i Thanks for the reply. But in this package there is no kernel module included, only firmware files. The used module b43 is part of kernel and included in the modules-array of my initrd. Therfore i think there is nothing i can do, if the module doesn't find the needed firmware files, or am i wrong? Actually I'm using the broadcom-wl package. By using this you are right, I need recompiling the package after kernelupdate. Greetings
Re: [arch-general] kernel 3.14.2 hangs - VirtualBox suspected
Yes, I had bad sector on md3 (raid10) array. Disk was replaced. But it looks like it is unrelated to the reason why my box is hanging. It started after kernel update from 3.10 to 3.14.2 and vbox to 4.3.10. Now i updated kernel to 3.14.3, going 4h from update and it looks like my problem is gone. Regards, Łukasz On 05/13/14 15:39, Nowaker wrote: I recently updated kernel to 3.14.2 and now I see i/o subsystem hang in few minutes after I start VirtualBox 4.3.10 machines (with Windows7). messages.log below. It looks like every process that tries to access /dev/md3 (even kworker and md3_resync) hangs forever. Anyone has similar problems? I also use soft raid1 so I just ran W7 on my 3.14.3 and it just works. You are probably hitting some bad sector. VM disk is on /dev/md3, isn't it? You may want to `cat` read the VM disk file, and dd `read` the whole drives and the md drive to see if they are readable. You may want to inspect /proc/mdstat, /sys/block/**/bad_blocks and smartctl reports. You may be facing some bug in the raid drivers. I faced one too, which was then fixed. https://bugzilla.kernel.org/show_bug.cgi?id=68181 If it *is* a bug, the best what you can do is to report the bug, and keep the the current raid mirror as long as possible so you can tests patches the kernel guys provide.
Re: [arch-general] kernel 3.14.2 hangs - VirtualBox suspected
I recently updated kernel to 3.14.2 and now I see i/o subsystem hang in few minutes after I start VirtualBox 4.3.10 machines (with Windows7). messages.log below. It looks like every process that tries to access /dev/md3 (even kworker and md3_resync) hangs forever. Anyone has similar problems? I also use soft raid1 so I just ran W7 on my 3.14.3 and it just works. You are probably hitting some bad sector. VM disk is on /dev/md3, isn't it? You may want to `cat` read the VM disk file, and dd `read` the whole drives and the md drive to see if they are readable. You may want to inspect /proc/mdstat, /sys/block/**/bad_blocks and smartctl reports. You may be facing some bug in the raid drivers. I faced one too, which was then fixed. https://bugzilla.kernel.org/show_bug.cgi?id=68181 If it *is* a bug, the best what you can do is to report the bug, and keep the the current raid mirror as long as possible so you can tests patches the kernel guys provide. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
[arch-general] kernel 3.14.2 hangs - VirtualBox suspected
Hi, I recently updated kernel to 3.14.2 and now I see i/o subsystem hang in few minutes after I start VirtualBox 4.3.10 machines (with Windows7). messages.log below. It looks like every process that tries to access /dev/md3 (even kworker and md3_resync) hangs forever. Anyone has similar problems? May 13 12:35:29 serenity kernel: kworker/u16:9 D 0 112 2 0x May 13 12:35:29 serenity kernel: Workqueue: writeback bdi_writeback_workfn (flush-9:3) May 13 12:35:29 serenity kernel: 8804175177c0 0046 88042fc575a0 880417518000 May 13 12:35:29 serenity kernel: 000146c0 880417517fd8 000146c0 880417518000 May 13 12:35:29 serenity kernel: 34ca04fb 880417517710 880412a11e10 8804175177b8 May 13 12:35:29 serenity kernel: Call Trace: May 13 12:35:29 serenity kernel: [] ? check_blkcg_changed+0x57/0x210 May 13 12:35:29 serenity kernel: [] ? mempool_alloc_slab+0x15/0x20 May 13 12:35:29 serenity kernel: [] ? blk_throtl_bio+0x35f/0x940 May 13 12:35:29 serenity kernel: [] ? mempool_alloc_slab+0x15/0x20 May 13 12:35:29 serenity kernel: [] ? mempool_alloc+0x61/0x170 May 13 12:35:29 serenity kernel: [] ? __ext4_handle_dirty_metadata+0x83/0x1a0 [ext4] May 13 12:35:29 serenity kernel: [] schedule+0x29/0x70 May 13 12:35:29 serenity kernel: [] wait_barrier+0xc6/0x190 [raid10] May 13 12:35:29 serenity kernel: [] ? __wake_up_sync+0x20/0x20 May 13 12:35:29 serenity kernel: [] make_request+0x44/0x130 [raid10] May 13 12:35:29 serenity kernel: [] md_make_request+0x103/0x260 [md_mod] May 13 12:35:29 serenity kernel: [] ? mempool_alloc_slab+0x15/0x20 May 13 12:35:29 serenity kernel: [] ? mempool_alloc+0x61/0x170 May 13 12:35:29 serenity kernel: [] generic_make_request+0xf8/0x150 May 13 12:35:29 serenity kernel: [] submit_bio+0x78/0x190 May 13 12:35:29 serenity kernel: [] _submit_bh+0x140/0x230 May 13 12:35:29 serenity kernel: [] __block_write_full_page+0x129/0x370 May 13 12:35:29 serenity kernel: [] ? I_BDEV+0x10/0x10 May 13 12:35:29 serenity kernel: [] block_write_full_page_endio+0xb2/0x150 May 13 12:35:29 serenity kernel: [] block_write_full_page+0x15/0x20 May 13 12:35:29 serenity kernel: [] blkdev_writepage+0x18/0x20 May 13 12:35:29 serenity kernel: [] __writepage+0x13/0x40 May 13 12:35:29 serenity kernel: [] write_cache_pages+0x1e0/0x4d0 May 13 12:35:29 serenity kernel: [] ? mapping_tagged+0x20/0x20 May 13 12:35:29 serenity kernel: [] generic_writepages+0x4d/0x80 May 13 12:35:29 serenity kernel: [] do_writepages+0x1e/0x30 May 13 12:35:29 serenity kernel: [] __writeback_single_inode+0x40/0x2b0 May 13 12:35:29 serenity kernel: [] writeback_sb_inodes+0x26a/0x430 May 13 12:35:29 serenity kernel: [] __writeback_inodes_wb+0x9f/0xd0 May 13 12:35:29 serenity kernel: [] wb_writeback+0x22b/0x360 May 13 12:35:29 serenity kernel: [] ? get_nr_inodes+0x51/0x70 May 13 12:35:29 serenity kernel: [] bdi_writeback_workfn+0x33f/0x4c0 May 13 12:35:29 serenity kernel: [] process_one_work+0x168/0x450 May 13 12:35:29 serenity kernel: [] worker_thread+0x132/0x3e0 May 13 12:35:29 serenity kernel: [] ? manage_workers.isra.23+0x2d0/0x2d0 May 13 12:35:29 serenity kernel: [] kthread+0xea/0x100 May 13 12:35:29 serenity kernel: [] ? kthread_create_on_node+0x1a0/0x1a0 May 13 12:35:29 serenity kernel: [] ret_from_fork+0x7c/0xb0 May 13 12:35:29 serenity kernel: [] ? kthread_create_on_node+0x1a0/0x1a0 May 13 12:35:29 serenity kernel: jbd2/md3-8 D 0 496 2 0x May 13 12:35:29 serenity kernel: 8804136e5ca0 0046 0001 88041963ce80 May 13 12:35:29 serenity kernel: 000146c0 8804136e5fd8 000146c0 88041963ce80 May 13 12:35:29 serenity kernel: 8804136e5bf0 8119d6e6 0046 May 13 12:35:29 serenity kernel: Call Trace: May 13 12:35:29 serenity kernel: [] ? kmem_cache_free+0x216/0x240 May 13 12:35:29 serenity kernel: [] ? cpuacct_charge+0x50/0x60 May 13 12:35:29 serenity kernel: [] ? update_curr+0xec/0x1b0 May 13 12:35:29 serenity kernel: [] ? dequeue_entity+0x13f/0x580 May 13 12:35:29 serenity kernel: [] schedule+0x29/0x70 May 13 12:35:29 serenity kernel: [] jbd2_journal_commit_transaction+0x215/0x19c0 [jbd2] May 13 12:35:29 serenity kernel: [] ? __switch_to+0x1af/0x540 May 13 12:35:29 serenity kernel: [] ? __wake_up_sync+0x20/0x20 May 13 12:35:29 serenity kernel: [] ? try_to_del_timer_sync+0x5e/0x90 May 13 12:35:29 serenity kernel: [] kjournald2+0xec/0x2a0 [jbd2] May 13 12:35:29 serenity kernel: [] ? __wake_up_sync+0x20/0x20 May 13 12:35:29 serenity kernel: [] ? commit_timeout+0x10/0x10 [jbd2] May 13 12:35:29 serenity kernel: [] kthread+0xea/0x100 May 13 12:35:29 serenity kernel: [] ? kthread_create_on_node+0x1a0/0x1a0 May 13 12:35:29 serenity kernel: [] ret_from_fork+0x7c/0xb0 May 13 12:35:29 serenity kernel: [] ? kthread_cr
Re: [arch-general] archlinux kernel 3.14.2-1 Broadcom BCM4312 firmware-files not found
On Fri, May 9, 2014 at 7:00 PM, Andreas Adelmann wrote: > What have i done: > reinstalled firmware b43-firmware-5.100.130 by using Kernel > 3.14.1-1 and 3.14.2-1 - no success. > Only reinstalling the module won't do. You need to recompile for every kernel. cheers! mar77i