From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7BFC91396D0 for ; Thu, 31 Aug 2017 07:47:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 67FC8E0D12; Thu, 31 Aug 2017 07:47:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 07EABE0CB8 for ; Thu, 31 Aug 2017 07:47:18 +0000 (UTC) Received: from localhost (unknown [46.148.235.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: bircoph) by smtp.gentoo.org (Postfix) with ESMTPSA id A78CF33BEC7 for ; Thu, 31 Aug 2017 07:47:17 +0000 (UTC) Date: Thu, 31 Aug 2017 10:47:13 +0300 From: Andrew Savchenko To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] strange behaviour in quite special case Message-Id: <20170831104713.80ae4a836eab50c994375dd8@gentoo.org> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.30; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Thu__31_Aug_2017_10_47_13_+0300_cM86gBIi8FPwdQzc" X-Archives-Salt: b69069a6-d3af-485c-86eb-2153a0726794 X-Archives-Hash: 0d167f2eb7cac07249387b08317be006 --Signature=_Thu__31_Aug_2017_10_47_13_+0300_cM86gBIi8FPwdQzc Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, 24 Aug 2017 18:27:22 -0300 Francisco Ares wrote: > Hi, All. >=20 > This is a rather special case, so I don't expect much, but who knows? >=20 > I've built a Gentoo x86-64 system for an embedded application. >=20 > Just after a lot of updates, which I am unable to track, it stopped worki= ng > as usual. >=20 > There is the development system, fully loaded of a lot of packages used f= or > development, and the production system, that don't need all of those. >=20 > There is a line in both systems in /etc/iniitab responsible for auto-login > the production system user and the programs we need running (in its > ".bash_profile" and ".xinitrc"): >=20 > c6:2345:respawn:/sbin/agetty -a production-user 38400 tty6 linux >=20 > The development system starts a WindowMaker session, and the production > system starts a program that controls the rest of the hardware of this > embedded system, with an X11 graphical interface. That runs normally when > simulated at the development system. >=20 > The development system runs smoothly. The production system, after > removing the files from undesirable packages and creating a squashfs image > of the ripped-off root partition behaves strangely at boot: >=20 > It shows the initialization messages as expected, but when the auto-login > and the controller program start should take place, it completely stalls = up > to I plug a USB keyboard and issue some times some of the key combinations > to change to a text console and back to X11 (Ctrl-Alt-F1 and Ctrl-Alt-F6); > only then the things resume as expected. >=20 > As you might suspect, there is no keyboard for the production system ;-) . >=20 > As a matter of fact, I don't know where the stall take place, as when I t= ry > to switch to a text console to see the logs, it switches back to X11 and > starts our program. By the way, the logs just show that the events > occurred at latter times than expected. >=20 > Although the squashfs is read-only, some main directories are arranged in= a > way that, using tmpfs mounts and unionfs with the read-only directory to > the read-write tmpfs directory to that main directory provide a way of > creating temporary files that has been working for a few years now. >=20 > For instance, in "/etc/fstab": >=20 > tmpfs /.etc.rw tmpfs defaults,mode=3D755 > 0 0 > union /etc unionfs > default_permissions,allow_other,use_ino,nonempty,suid,cow,dirs=3D= /. > etc.rw=3Drw:/.etc.ro=3Dro 0 0 >=20 > And there is a "/.etc.ro" with a copy of all files present in regular > "/etc" , a "/.etc.rw" directory to be mounted tmpfs, and the original > "/etc" directory, that needs to be there at boot, even before mounting all > this. >=20 > Does anyone have a clue? Try to dissect your problem. Start with removing squashfs and all tmpfs/unionfs manipulations. Create the same image, but on "normal" writable file system and see how it goes. It may be fs-related bug, may be you removed too many files and some "undesired" packages are actually mandatory. If you have some form on snapshots of your changes, you can try to bisect them in a git bisect way. Another approach is to run X server (or any other app suspected as a troublemaker) under strace (or attach strace to a running process) and see what is going on. You will have a lot of low level information and extensive filtering will be required; strace is capable of that, but you will need to dig into its documentation. Best regards, Andrew Savchenko --Signature=_Thu__31_Aug_2017_10_47_13_+0300_cM86gBIi8FPwdQzc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE63ZIHsdeM+1XgNer9lNaM7oe5I0FAlmnvwEACgkQ9lNaM7oe 5I0U5w/9ElwIKqR5RQqqYN2eqa1l6saUIxAW4S1HAWhMbOlbD+lO+U6o1CKs6gRf PndPdWl04RZRhpU4oXcQkf2C8dc5BwKdMu4haSzdygeSe2e6EO0KfD22dFb6npZA gGrFJj2pYwOLNTzPqlZ6QDcaatPnzUnYCIhMFAD5b9PD4tvM43LP2zHiKK5+u2uw FOm6T8UPGrQo2SNIyHukpnfzFzJaFJVgqCMp+ort3uJ56Ap8UOLk0r0VY+tiY5vJ twqbeCmk2iDNxkQUgZlZ7DrikI6v56yTUHcDn19ynJW8viS477pQI7kZIh2xGL83 GJY+EqtMhPBlGaf0y1pu/+2yjdhsi75/+GMpEmmPdXpyuqiPFPduC2gWTb3WmIO2 V5cweW5Zqj75UQbpLOC5HjpXTqrqOGLoNsa7c3r+qKXQwiBTAEY+gEl3Nj2qKWK7 G+L92NvLNVwgyqNI9msMOSOCD+rHXeAI5sS79FR2TW6x1RTu4usIjkc6Leqn8f1I ZzmNg2DkAFIvkMAqEq5fNoVmeFThknI9GOkKDzFQMEvlmGwn1piWrZknMlh1AXna qHjlpFzW4cfwwk83LlOdLeQmYf34nYXrV+8iUUwGbk+5U5xc+erKIqWFPr4QCkcG N0DXSWGBqf+I3gOaeZA8WvPyXaNQ1RrwGf3wMUoaGkGgMH3BS/w= =xZrl -----END PGP SIGNATURE----- --Signature=_Thu__31_Aug_2017_10_47_13_+0300_cM86gBIi8FPwdQzc--