Bug#1064252: closed by Salvatore Bonaccorso (Re: Bug#1064252: linux-image-6.1.0-17-amd64: CONFIG_SYSTEM_TRUSTED_KEYS="y" is in the default config "y")
Since .config lists the response to this as "y" WITH THE DOUBLE QUOTES, IT is not possible to change it in menuconfig, and the quotes break the compile. So, the stock linux-image-6.5-amd64 config file in /boot, if copied to .config into the source directory, it's booby trapped with a config value: "y", that prevents it from being changed in the make config, and it breaks the kernel compile no matter what. Nowhere does Debian kernel development document all the changes that must be made to the stock configs from the linux-image packages when they are copied as .config from /boot to the source directory. Every single stock /boot/config-xyz will break the compile of the source package if used as a template for .config (which could be a super time-saver)--which is bad enough--but Debian has let this problem go on for probably 6 years. I think a patch to fix this problem would be in order. Just have a config option: "patch stock config for successful compile", would be really helpful. Or, better yet, an interactive Makefile option--make compilableconfig, that branches to a script that calls external programs and promts the source package user to create and put in place the necessary files to use the problematic options for their intended purpose, and correct .config options that need to be changed. That would require, at most, 15 minutes per linux-image package. I appreciate all the Debian project gives to the world, and to me personally. I don't mean to just vent on you. Another plan could be to mark stock config files, and if one is detected, to execute the repair script, and print a config-patch.log. Also, perhaps shasums could be calculated for stock config files and .config in the sources directory, and compared to determine whether or not .config is a copy of /boot/config-xyz. I've been using Debian since woody, when I was in elementary school. But I became more of an admin, security, forensics, triage and hacker. Alhough I have some noteworthy programming accomplishments.I devised algorithms to convert between numeric bases, and to do arithematic using numbers of different bases. I was a self-employed consultant while in college. My first job I made $6,000 in 20 hours. I'd like to contribute more to Debian. But most of the English language documentation is well done. Maintaining packages is time-consuming. But, I don't want to go on and on. I hope I've communicated more clearly. Tom Original Message From: Debian Bug Tracking System Sent: March 7, 2024 9:03:05 PM UTC To: tomas k Subject: Bug#1064252 closed by Salvatore Bonaccorso (Re: Bug#1064252: linux-image-6.1.0-17-amd64: CONFIG_SYSTEM_TRUSTED_KEYS="y" is in the default config "y") This is an automatic notification regarding your Bug report which was filed against the src:linux package: #1064252: linux-image-6.1.0-17-amd64: CONFIG_SYSTEM_TRUSTED_KEYS="y" is in the default config "y" It has been closed by Salvatore Bonaccorso . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Salvatore Bonaccorso by replying to this email. -- 1064252: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064252 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1002805: closed by Michael Biebl (Re: Bug#1002805: systemd: Upon mount, immediately umounts external drives not connected at boot)
I can no longer reproduce the problem. Sorry for the long delay. I have a really busy time these days. Mount seems to work seemlessly on USB drives. Thanks, whoever fixed it. On Tue, 2022-01-18 at 19:36 +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the systemd package: > > #1002805: systemd: Upon mount, immediately umounts external drives > not connected at boot > > It has been closed by Michael Biebl . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Michael Biebl > by > replying to this email. > >
Bug#1000239: Rescue system won't find root partition, but insists on /usr
In commercial and industrial applications It is common to have discrete partitions for /, /boot, /home, /usr swap and /var. The rationale for doing so lies in three areas. /var can and does fill up with log files frequently. Having it separate has long been a means to prevent / from filling up, and to permit resizing /var without taking down the system. Many times hardware failure will destroy a partition, and it's much less work to recover if 'everything' does not reside on a single partition. Judicious use of disk space dictatates splitting large disks into smaller partitions, which function more efficiently. If there is a /usr partition, /usr/share will be part of it. So, separate /usr/share is exactly as common s/as separate /usr. For home use none of this matters, because it is trivial to reinstall the OS. Although, my personal lappy has five partitions on the disk. /usr/share has architecture independent files which are architecture independent only because they are not binaries. No documentation is architecture dependent! The reader may be, but not the actual documentation, as is found in /usr/share/. Original Message From: Pascal Hambourg Sent: December 8, 2021 11:41:11 AM UTC To: Philip Hands , 1000...@bugs.debian.org, TomK Subject: Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr Le 08/12/2021 à 10:49, Philip Hands a écrit : > > Is it a problem if /home or /usr/share are left unmounted during rescue? /usr/share contains architecture-independent files for many programs such as bash, grub, os-prober, debconf, dpkg, initramfs-tools... How common is it to have a separate /usr/share and what is the rationale for it ?
Bug#1000239: Rescue system won't find root partition, but insists on /usr
This sounds correct, based on my experience with the bug. I suppose now there are zero ways to definitively determine which partition is actually root. So maybe a hidden flag (empty) file in root might do the trick. But the fact that /usr can be automounted, but nothing else can be manually mounted afterward is also a problem. If there was a separate script to do the chroot part, and some manual interface by which to mount; perhaps the mount command in the rescue system PATH, the whole thing would be more flexible during the transition to ro mount for /usr in future Debian versions. Presently it appears there will be several possibilities for the conditions of root and /usr, so no definite means cannot be devised to always do the correct thing. Even if a flag file is used to identify root, that might not be what rescue requires. In the near future I think the flag file would work, and then /usr could be mounted manually, as once was the case. But perhaps at some point mount would need to be a static binary, to account for libraries moved to /usr. I'm not well versed on Debian policy, so just ignore my input if it makes no sense. If you find it irritating, it's my ignorance at work, nothing intentional. Original Message From: Simon McVittie Sent: December 4, 2021 11:42:56 AM UTC To: Nicholas D Steeves Cc: 1000...@bugs.debian.org, TomK , Steve McIntyre , debian-rele...@lists.debian.org, debian-c...@lists.debian.org Subject: Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr (Speaking only on my own behalf, not on behalf of the TC, here) On Fri, 03 Dec 2021 at 16:08:24 -0500, Nicholas D Steeves wrote: > 1. Debian isn't yet ready for usrmerge Merged /usr is not actually the problem here, although it exacerbates what appears to be a pre-existing bug in the rescue mode[0]. The root cause is that since Debian 9 [1][2], the "/usr-like" parts of the root filesystem are no longer guaranteed to be self-contained: important shared libraries[3] and executables have been gradually moving into /usr for a while, and stretch was the point at which this was declared to be officially allowed. Merged /usr makes this very noticeable because it's the most extreme version of that process, where *literally everything* "/usr-like" (most notably /bin/sh) moves into /usr. When /usr is a separate filesystem, that leaves a root filesystem that potentially contains only /etc, symlinks and mount points, which is certainly not enough to be useful to chroot into. > 2. Reassign to src:rescue, and fix the rescue system. I think this will have to be the answer. See also [0]. > 3. Disallow configuring of a mount for "/usr" That would be unfortunate, since one of the things enabled by merged /usr is the ability to keep all "/usr-like" content on a separate /usr filesystem that is mounted read-only during normal operation, remounting it rw only for system updates[4], while leaving /etc and /var rw (and potentially offering the ability to reformat the partition with /etc and /var, and then repopulate it via systemd-tmpfiles or similar, as a "factory reset" mechanism). smcv [0] https://bugs.debian.org/769738 (opened in 2014) [1] https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#late-mounting-usr [2] and possibly earlier: that release note was documenting current practice rather than describing a new change [3] for example about half the libraries in `ldd /sbin/cryptsetup` [4] which potentially happen atomically across a reboot, as seen in ostree, or while rebooted into a special boot mode, as with systemd.offline-updates(7)
Bug#1000239: Rescue system won't find root partition, but insists on /usr
Package: debian-installer Version: 20210731+deb11u1_amd64 Errors, "No suitable shell found on /dev/sda1" Cycling through every partition results in what should be /usr being selected as the root partition. This is useless for a rescue syatem, because there some commands missing. I tried to mount the root partition on a mount point I made inside the installer, but there was a problem with permissions. I can't perfectly remember. I tried 'sudo', but it isn't available in the installer. I was attempting to reinstall grub, to get the system to boot. I have also used the rescue syatem to change a lost password. It appears this bug may apply only to a gpt partition table and a fat32 boot partition (efi?). I've had this same problem with 2 systems, a lappy and a desktop. I can always work around it. I don't understand what could be going on, for lack of experience. I've only been a Debian user since Woody was in testing. It's easy to reproduce. Do an expert install with defaults, but partition with gpt. Boot the system with the install media, launch a rescue shell, and try to open a root shell. An incorrect device should be identified as '/'. Perhaps this occurs only when /usr is on a different partition that '/'. But it is bothersome, because it essentially removes 90% of the functionality from the rescue system. The install media used to be my goto for rescue. But now I've found this very annoying problem. If you require more info, I can boot the dvd again and record exact errors. I'm on my tablet, so I don't have access to reportbug. Thanks for the help! You guys are the best!
Bug#901721: Additional info
After evaluating the bug, it is actually a wishlist bug, because the BIOS in the system has a BBS list (F12) of all boot devices. Any can be chosen on boot-up. That's why the BIOS setup can get away with being so scant on boot-device options. I would say the problem is solved. I found this while researching another bug. My email is different for this appendage.
Bug#971406: gnome-shell: freezes when laptop is configured for external display only
On Wed, 30 Sep 2020 10:55:34 +0100 Simon McVittie wrote: > Control: reassign -1 gnome-shell 3.30.2-11~deb10u2 > Control: retitle -1 gnome-shell: freezes when laptop is configured for external display only > Control: tags -1 + moreinfo buster > > On Tue, 29 Sep 2020 at 18:58:55 -0400, tom wrote: > > Gnome-conrol-center > devices > displays > external monitor set > > to primary in 'join displays'> 'single display' > > turns off both LVDS and external monitor, freezes keyboard and > > mouse control > > gnome-control-center only changes configuration and doesn't actually > implement the display change, so I'm reassigning this to gnome-shell, > which is the component that -control-center is configuring. Please > send the output of "reportbug --template gnome-shell" so that we can > see the versions of all the related packages. For now I'm assuming >that > it's the latest version from Debian 10.6. > > If you repeat the configuration that caused the freeze, does it >happen > reliably? I think it's fixed. Seems to work now. > What messages appear in the system log (/var/log/syslog or the systemd > journal) when this happens? I could not determine that. > > Are you using the Wayland or Xorg version of the GNOME session? > wayland > What hardware are you using? Lenovo W541 laptop on dock station, ext monitor is Samsung connected by DP port on dock. >You mentioned LVDS, so presumably it's a > laptop. What graphics device does it have? lspci, from the pciutils > package, should list a "VGA compatible controller", perhaps more than > one. Using Intel video 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 01:00.0 VGA compatible controller: NVIDIA Corporation GK106GLM [Quadro K2100M] (rev a1) > > Are you using any GNOME Shell extensions? If you are, please try >disabling > them all and see whether the bug persists. Not using extensions. > hard reboot only solution > > Here are some things that might make a hard reboot unnecessary: > > * press Ctrl+Alt+Delete repeatedly (more than 7 times in 2 seconds) > to reboot semi-gracefully > > * press Ctrl+Alt+F6, then Ctrl+Alt+Delete repeatedly > > * use "magic sysrq key" sequences > (https://en.wikipedia.org/wiki/Magic_SysRq_key#Uses) > to reboot less gracefully > Thanks for the reboot advice. Didn't have a chance to try it 'this' time, but it'll be handy to have in the future. > Do any of those work? If they do, that gives us useful information > about > which layers of the system have stopped working and which layers > still work. > > > If 'mirror' is used, the external monitor is available, but only at > > the resolution of the LVDS or lower. > > Mirroring can only happen at resolutions that are supported by both > displays, so that part isn't a bug. > > smcv > > Lenovo machines can be finicky with Linux, because the hardware depends a lot on custom MS Windows code, written by Lenovo, to function. So, this report may have a very narrow scope. I cannot determine what changed to make 'ext display only' suddenly work. Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: tom To: Debian Bug Tracking System Subject: gnome-shell: none X-Debbugs-Cc: foren...@milwpc.com Package: gnome-shell Version: 3.30.2-11~deb10u2 Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii evolution-data-server3.30.5-1+deb10u1 ii gir1.2-accountsservice-1.0 0.6.45-2 ii gir1.2-atspi-2.0 2.30.0-7 ii gir1.2-freedesktop 1.58.3-2 ii gir1.2-gcr-3 3.28.1-1 ii gir1.2-gdesktopenums-3.0 3.28.1-1 ii gir1.2-gdm-1.0 3.30.2-3 ii gir1.2-geoclue-2.0 2.5.2-1 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-gnomebluetooth-1.03.28.2-4~deb10u1 ii gir1.2-gnomedesktop-3.0 3.30.2.1-2 ii gir1.2-gtk-3.0
Bug#677650: Bug still exists. I get the same error.
I suppose a workaround might be to install the unhide package and make a link to wherever rkhunter looks for it. /usr/sbin/ is not a reasonable install location for the unhide command. It doesn't require privilege elevation to work properly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
