Bug#807071: util-linux: please allow term-utils/script.c without signalfd (needed for kFreeBSD and Hurd)
On Thu, Feb 02, 2023 at 02:08:11AM +, Thorsten Glaser wrote: > Karel Zak dixit: > > >On Thu, Oct 24, 2019 at 12:38:51AM +, Thorsten Glaser wrote: > >> you were involved in changing script(1) to use signalfd, which > >> is apparently Linux-specific but util-linux also is used, at > >> least in Debian, on other kernels, such as the FreeBSD and Hurd > >> ones (FSVO “kernel”, for the latter). > > > >The problem is that with signalfd it's more reliable than when > >classic signals interrupt any syscall, but I have no problem to > >support any #ifdefs for non-signalfd systems. > > > >I have added this request to our TODO file. We'll see. > > How’s this progressing? Sorry, no progress. I have added git hub issue for this https://github.com/util-linux/util-linux/issues/2054 Karel -- Karel Zak http://karelzak.blogspot.com
Bug#1030285: Fwd: Bug#1030285: bsdutils: logger: regressed to reusing initial timestamp
On Thu, Feb 02, 2023 at 02:50:30PM +, Thorsten Glaser wrote: > this regressed between 2.37.3 and 2.38~rc1 and you were the person > to touch this code last; do you have any idea which change introduced > this regression and a possible fix? Already reported: https://github.com/util-linux/util-linux/issues/1866 Bugfix: http://github.com/util-linux/util-linux/commit/96ccdc00e1fcf1684f9734a189baf90e00ff0c9a Karel > > Thanks in advance! > > -- Forwarded message -- > Message-ID: <167530436240.9092.12628425440425024484.report...@ara4.mirbsd.org> > Date: Thu, 02 Feb 2023 02:19:22 + > Subject: Bug#1030285: bsdutils: logger: regressed to reusing initial timestamp > > Package: bsdutils > Version: 1:2.38.1-4 > Severity: normal > X-Debbugs-Cc: t...@mirbsd.de > > I *know* we had this bug already, and it got fixed at some time, > but apparently a regression was introduced and this bug shows up > again in sid: long-running logger(1) sessions do not receive an > updated timestamp for later lines: > > root@ara4:~ # tail -F /var/log/syslog& > root@ara4:~ # (echo foo; sleep 5; echo bar) | logger -t baz > Feb 2 02:04:24 ara4 baz: foo > Feb 2 02:04:24 ara4 baz: bar > > Compare bullseye: > > tglase@x61w:~ $ (echo foo; sleep 5; echo bar) | logger -t baz > Feb 2 03:04:45 x61w baz: foo > Feb 2 03:04:50 x61w baz: bar > > I use “dæmonprogram | logger -t nameofthat” quite often, and > having output with ancient timestamps suddenly show up in logs > is confusing (especially fail2ban very much dislikes that). > > For the sake of completeness, the bullseye system uses > inetutils-syslogd 2:2.0-1+deb11u1, the sid system has > inetutils-syslogd 2:2.4-2, but TTBOMK the timestamp is > generated by logger(1), not the syslog dæmon (that would > be weird). > > > -- System Information: > Debian Release: bookworm/sid > APT prefers unreleased > APT policy: (500, 'unreleased'), (500, 'unstable') > Architecture: m68k > > Kernel: Linux 6.1.0-2-m68k (UP) > Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/bash > Init: sysvinit (via /sbin/init) > > Versions of packages bsdutils depends on: > ii libc6 2.36-4+ports > ii libsystemd0 252.4-1 > > Versions of packages bsdutils recommends: > ii bsdextrautils 2.38.1-4 > > bsdutils suggests no packages. > > -- no debconf information > -- Karel Zak http://karelzak.blogspot.com
Bug#1003095: /usr/bin/script: hangs when child doesn't read input fast enough
On Tue, Apr 12, 2022 at 04:25:14PM +0200, наб wrote: > Added pty->free_buffers where we put free-to-use (fully-written-out buffers) > instead of free()ing them; my testing indicates, that for interactive use > we allocate a single buffer and re-use 100% of the time. Cool. > include/pty-session.h | 7 +++ > lib/pty-session.c | 126 ++ > 2 files changed, 110 insertions(+), 23 deletions(-) Applied, thanks! Please, next time use "Signed-off-by:" line :-) Karel -- Karel Zak http://karelzak.blogspot.com
Bug#1003095: /usr/bin/script: hangs when child doesn't read input fast enough
On Fri, Jan 14, 2022 at 12:28:11AM +0100, наб wrote:
> -static int write_to_child(struct ul_pty *pty, char *buf, size_t bufsz)
> +static int schedule_child_write(struct ul_pty *pty, char *buf, size_t bufsz,
> int final)
> {
> - return write_all(pty->master, buf, bufsz);
> + struct ul_pty_child_buffer *stash = calloc(1, sizeof(*stash));
It means that for each activity on the file descriptor it will
allocate a new buffer (in BUFSIZ). It seems pretty expensive.
Cannot we reuse the buffers?
Maybe use include/list.h, define two lists, one for not-yet-written
buffers and another for ready-to-use buffers and move from one list to
another in schedule_child_write() and flush_child_buffers().
> + if (!stash)
> + return -1;
> +
> + memcpy(stash->buf, buf, bufsz);
> + stash->size = bufsz;
> + stash->final_input = final ? 1 : 0;
> +
> + if (pty->child_buffer_head)
> + pty->child_buffer_tail = pty->child_buffer_tail->next = stash;
> + else
> + pty->child_buffer_head = pty->child_buffer_tail = stash;
> + return 0;
> }
>
> /*
> @@ -311,16 +329,13 @@ static int write_to_child(struct ul_pty
> * maintains master+slave tty stuff within the session. Use pipe to write to
> * pty and assume non-interactive (tee-like) behavior is NOT well supported.
> */
> -void ul_pty_write_eof_to_child(struct ul_pty *pty)
> +static void drain(struct ul_pty *pty)
drain_child_buffers() :-)
Anyway, it looks good.
Karel
--
Karel Zak
http://karelzak.blogspot.com
Bug#1003095: /usr/bin/script: hangs when child doesn't read input fast enough
On Wed, Feb 02, 2022 at 03:49:38PM +0100, наб wrote: > Bumping this patch after 2ish weeks :) Sorry for my delay. Your solution seems elegant, but it seems to late for the next release v2.38 (now rc1). I'll play with it next week and prepare it for v2.39. Karel -- Karel Zak http://karelzak.blogspot.com
Bug#1003095: /usr/bin/script: hangs when child doesn't read input fast enough
On Tue, Jan 04, 2022 at 06:31:24PM +0100, наб wrote:
> Control: tags -1 + upstream
>
> On Tue, Jan 04, 2022 at 05:24:54PM +0100, Chris Hofstaedtler wrote:
> > * наб [220104 00:06]:
> > > (This, at least, responds to ^\, but it also seems to function
> > > slightly differently. Also, this is a race and you're more
> > > likely to lose it under strace. The loopy thing seems
> > > like it's pretty good at hitting it 100% of the time.)
> As an additional note, because it's a race, if you're using bash,
> script < some-photo.jpeg
> also hangs, because setup takes long enough.
>
> > 1) is this Debian-specific or already present upstream?
> Debian doesn't patch script.c at all, so this is an upstream bug.
>
> > 2) did this work with previous versions of util-linux?
> The oldest one I fould from the site at Homepage: in d/control is
> "util-linux-ng 2.13", dated 19.1.2012. It's much closer to the original
> 4.4BSD-Lite implementation and still forks twice. As expected, testing
> reveals it does not have the bug.
>
> Performing a simple manual bisect across the versions available therein
> reveals that 2.25 is the first broken version. (Though, skimming the
> source, with a slightly different code path (select(2)?), since it still
> double-forks and is not so hard-stuck so as to be immune to ^\.)
>
> The first version that does get hard-stuck (because it forks once
> and only uses poll) is 2.27.
Resolve the problem with the signal should be simple. Now it
ignores all when it write to the master. Something like:
diff --git a/lib/pty-session.c b/lib/pty-session.c
index 6f038e1c5..84ea33860 100644
--- a/lib/pty-session.c
+++ b/lib/pty-session.c
@@ -292,7 +292,20 @@ static int write_output(char *obuf, ssize_t bytes)
static int write_to_child(struct ul_pty *pty, char *buf, size_t bufsz)
{
- return write_all(pty->master, buf, bufsz);
+ sigset_t set, org;
+ int rc;
+
+ sigemptyset(&set);
+ sigemptyset(&org);
+ sigaddset(&set, SIGINT);
+ sigaddset(&set, SIGTERM);
+
+ sigprocmask(SIG_UNBLOCK, &set, &org);
+
+ rc = write_all(pty->master, buf, bufsz);
+
+ sigprocmask(SIG_SETMASK, &org, NULL);
+ return rc;
}
--
Karel Zak
http://karelzak.blogspot.com
Bug#977562: systemd: Incorrect order of agetty arguments in serial-getty@ttyS0.service definition file
On Thu, Jan 14, 2021 at 05:26:40PM +0100, Michael Biebl wrote: > Karel, > > sorry for poking you directly: Could you weigh in here? agetty accepts both: agetty --help Usage: agetty [options] [,...] [] agetty [options] ,... [] and code differentiates between these variants by digits, if the string contains only "0123456789," than it . > > On 1/14/21 3:06 PM, Michael Biebl wrote: > > > Am 19.12.20 um 16:47 schrieb Andreas Henriksson: > > > > Control: tags -1 + moreinfo > > > > > > > > On Wed, Dec 16, 2020 at 11:39:06PM +0100, Michael Biebl wrote: > > > > > Am 16.12.20 um 20:49 schrieb MK: > > > > > > Package: systemd > > > > > > Version: 241-7~deb10u5 > > > > > > Severity: normal > > > > [...] > > > > > > Incorrect order of arguments to agetty in the > > > > > > serial-getty@ttyS0.service > > > > > > unit file. > > > > > > > > > > > > It is: > > > > > > > > > > > > ExecStart=/sbin/agetty --autologin root -8 --keep-baud > > > > > > 115200,38400,9600 ttyS0 xterm-256color > > > > > > > > > > > > > > > > > > While it should be like: > > > > > > > > > > > > ExecStart=/sbin/agetty --autologin root -8 --keep-baud > > > > > > ttyS0 115200 xterm-256color > > > > [...] > > > > > According to the examples in man agetty, both should work. > > > > > > > > > > Andreas, can you comment here? > > > > > If what MK is saying, should the "EXAMPLE" section in man > > > > > agetty be updated? I think the man page is correct. > > > > I don't really have much prior knowledge about *getty, but in my past > > > > experience with other util-linux tools it is often the case that > > > > (likely for historical reasons/compatibility) the arguments that > > > > doesn't come in a dash-form is attempted to be accepted in either > > > > order based on guessing which one was specified. In my past experience > > > > something that was guessable in the past might in later years become > > > > sometimes impossible to correctly guess right, so sticking with > > > > what synopsis describes is usually the safest as far as I'm concerned. > > > > > > > > In the agetty case, the guessing is done here: > > > > https://sources.debian.org/src/util-linux/2.36.1-2/term-utils/agetty.c/#L897 > > > > > > > > > > > > is_speed basically checks if the current argument only consists of > > > > either 0-9 or ','. Yes > > > > It is not obvious to me how it could go wrong in the example originally > > > > described in this bug report. > > > > > > > > Please also note that for example sysvinit's inittab also uses getty > > > > with arguments in both orders. > > > > > > > > Simply it should work either way. > > > > > > > > Please also note that the argument order is not the only thing changed. > > > > It was also changed from specifying 3 speeds to only 1. > > > > > > > > Maybe the real issue here is that line speed detection isn't working? > > > > I'd appreciate if the bug reporter could dive a bit deeper into the > > > > problem. Yes. Karel -- Karel Zak http://karelzak.blogspot.com
Bug#807071: util-linux: please allow term-utils/script.c without signalfd (needed for kFreeBSD and Hurd)
On Thu, Oct 24, 2019 at 12:38:51AM +, Thorsten Glaser wrote:
> you were involved in changing script(1) to use signalfd, which
> is apparently Linux-specific but util-linux also is used, at
> least in Debian, on other kernels, such as the FreeBSD and Hurd
> ones (FSVO “kernel”, for the latter).
I have added this request to our TODO file. We'll see.
The problem is that with signalfd it's more reliable than when
classic signals interrupt any syscall, but I have no problem to
support any #ifdefs for non-signalfd systems.
Karel
--
Karel Zak
http://karelzak.blogspot.com
Bug#898426: [PATCH] partx: exit with error code when partition read failed
On Sun, Jun 17, 2018 at 02:49:15PM +0200, Andreas Henriksson wrote: > disk-utils/partx.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Applied, thanks. -- Karel Zak http://karelzak.blogspot.com
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 09:34:14PM +0200, Simon Ruderich wrote: > On Mon, Oct 03, 2016 at 09:22:50PM +0200, up201407...@alunos.dcc.fc.up.pt > wrote: > > Loss of job control in the shell. > > I'm confused. I'm not talking about removing the controlling > terminal, but instead spawning a new session, opening a new pts > and connecting that to the program. This way the program has a > tty, job control works, but the tty is different and therefore > can't be controlled by the less-privileged account. Yes, I'm thinking about this way (as discussed on util-linux mailing list), but it's relatively complex. My plan is to try to implement it. We will see. Karel -- Karel Zak http://karelzak.blogspot.com
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 03:34:49PM +0200, Simon Ruderich wrote:
> @Karel: Could you please have a look at the patches in this bug
> report which use setsid() to create a new session and adapt your
> commit with a patch based on this approach? Sudo's use_pty option
> does the same to fix this issue (but not enabled by default).
I'll think about it.
Karel
--
Karel Zak
http://karelzak.blogspot.com
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 04:11:41PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Quoting "Simon Ruderich" : > > Btw, at least in redhat based systems, su uses setsid() when the -c option > is given, just like use_pty in sudo. Not sure if this is true in debian. The problem is that we don't want to use setsid() in all situations, because it will introduce regressions. From util-linux ReleaseNotes: CVE-2016-2779 This security issue is NOT FIXED yet. It is possible to disable the ioctl TIOCSTI by setsid() only. Unfortunately, setsid() has well-defined use cases in su(1) and runuser(1) and any changes would introduce regressions. It seems we need a better way -- ideally another ioctl (or whatever is supported by the kernel) to disable TIOCSTI without setsid(). and yes, blacklisting ioctl is hack. Karel -- Karel Zak http://karelzak.blogspot.com
Bug#827225: [PATCH] tests: really fix fdisk/bsd for hppa
On Mon, Aug 15, 2016 at 10:26:30PM +0200, Helge Deller wrote: > Finally fix the bsd testcase on the hppa architecture. > > Commit 1b7be556e553cdcef6213ead6340832c306011ed tried to fix it, > but missed the fact that "uname -m" returns "parisc" or "parisc64" > instead of "hppa*". > > Signed-off-by: Helge Deller > Cc: 827...@bugs.debian.org > > diff -up ./tests/ts/fdisk/bsd.org ./tests/ts/fdisk/bsd > --- ./tests/ts/fdisk/bsd.org 2016-08-15 22:16:24.849052620 +0200 > +++ ./tests/ts/fdisk/bsd 2016-08-15 22:16:42.645094364 +0200 > @@ -48,7 +48,7 @@ BYTE_ORDER=$($TS_HELPER_SYSINFO byte-ord > ARCH=$(uname -m) > case $ARCH in > # see include/pt-bsd.h > - *alpha* | *ppc* | *ia64* | *hppa* ) > + *alpha* | *ppc* | *ia64* | *parisc* ) Applied, but we had hppa also in ./confugure, so I guess that "hppa" has been also correct for some boxes. It seems more robust to use *alpha* | *ppc* | *ia64* | *hppa* | *parisc* ) for sure. Fixed. Thanks Karel -- Karel Zak http://karelzak.blogspot.com
Bug#809016: mount.8: missing documentation for overlay
On Sat, Dec 26, 2015 at 01:20:31PM +0900, Osamu Aoki wrote: > sys-utils/mount.8 | 31 +++ > 1 file changed, 31 insertions(+) Applied to upstream tree (with some changes), thanks! Karel -- Karel Zak http://karelzak.blogspot.com
Bug#801527: mount believes correctly-formatted UDF uid=forget option is in error
On Sun, Oct 11, 2015 at 10:58:48PM +0200, Andreas Henriksson wrote: > Using LIBMOUNT_DEBUG=all mount -t udf -o uid=ignore,gid=forget ... > shows the following message (among others): > > 24171: libmount:UTILS: cannot convert 'ignore' username to UID > > ... and according to the following code you seem to be very right > that except an actual uid you can also pass 'uid=ignore' or > 'uid=forget' explicitly: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/udf/super.c#n352 > > I see several possible options for implementing this in the future: > - special-case 'ignore' and 'forget' and pass those as is. > - if uid-lookup fails, try the above. > - (assuming different filesystems have different special options) >let any fs-option through as-is if 'smart lookup' fails. This is the way how the original mount(8) has worked. Fixed: https://github.com/karelzak/util-linux/commit/440a355a3d3934d99f7ef82adf02342e6f2f7983 will be in v2.27.1. Thanks! Karel -- Karel Zak http://karelzak.blogspot.com
Bug#794727: "mesg n" exits with error, even if the command is successful
On Sun, Aug 09, 2015 at 09:11:19PM +0200, Santiago Vila wrote: > On Sun, Aug 09, 2015 at 06:58:15PM +0100, Sami Kerola wrote: > > On 9 August 2015 at 18:19, Santiago Vila wrote: > > > On Sun, Aug 09, 2015 at 07:14:30PM +0200, Reuti wrote: > > >> The profile is usually sourced. How does the error show up at the login > > >> prompt on Debian? > > > > > > The problem only happens in Debian testing and unstable, which I am not > > > using yet. > > > This is the original report which I received against base-files: > > > > > > https://bugs.debian.org/794727 > > > > Please notice the mesg(1) exit behavior is defined in POSIX > > > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mesg.html > > > > Unfortunately the standard does not appear to be explicit whether the > > exit value should be set only when requesting write permissions > > (running without arguments), or if also when setting the permissions. > > So if the standard is not explicit about this, there is some room for > interpretation. Would not be possible to interpret the standard in a > sensible way? I think Posix standard is pretty explicit: EXIT STATUS The following exit values shall be returned: 0 Receiving messages is allowed. 1 Receiving messages is not allowed. >1 An error occurred. but you're asking for 0 also when 'n' or 'y' operants are specified. For me it seems like complicated return code semantic... > Hmm, but who does really need message *setting* to report exit codes? > They make more harm than help. > > As explained before, if I do "mesg y" I can reasonably think that > messages will be enabled after that, and if I do "mesg n" I can > reasonably think that messages will be disabled after that. > > I don't need an exit code for that, unless I don't trust the program > to do its job, and this is why I think there is no need to interpret > the standard so strictly. I think standard wants to keep the things simple and stupid without any extra exceptions (another exit codes when executed with operants). BTW, you can use "mesg $SOMETHING_FROM_USER" and then return code maybe an elegant way how to interpret user's input without parsing $SOMETHING_FROM_USER. (The current mesg implementation supporst rpmatch().) Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786554: [PATCH] man: fix nolazytime typo in mount(8)
On Wed, Jun 03, 2015 at 06:32:09PM +0200, Andreas Henriksson wrote: > sys-utils/mount.8 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784709: when would blkid success but not filesystem type?
On Tue, May 26, 2015 at 12:21:36PM +0800, Paul Wise wrote: > On Thu, 21 May 2015 13:07:35 +0200 Karel Zak wrote: > > > The option '-s' does not affect return code ... we have information > > about all (including empty) partitions! > > Ok, I see. Sounds like the proposed patch is appropriate then. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;filename=0001-Fix-by-forcing-fs-type-to-not-detected-if-not-named.patch;att=1;bug=784709 > > > Note that my recommendation is to use lsblk, for example: > > That has the same issue: > > $ sudo lsblk --noheading --output FSTYPE /dev/sda2 ; echo $? > > 0 Why do you want rely on return code? It is not error when FS type is undefined/unknown. All you need is to check result. FSTYPE=$(lsblk --nodeps --noheading --output FSTYPE /dev/sda2) [ -n "$FSTYPE" ] && echo $FSTYPE > I think for our purposes we would need --nodeps too. Yes. Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784709: when would blkid success but not filesystem type?
On Thu, May 21, 2015 at 04:24:38PM +0800, Paul Wise wrote: > In https://bugs.debian.org/784709 Jérôme Kieffer wrote: > > > Here is the answer for the 3.16 kernel: > > > > jerome@patagonia:~$ sudo blkid -o value -s TYPE /dev/sdb4 > > jerome@patagonia:~$ echo $? > > 0 > ... > > > > The output is the same on 3.2, as you can see on attached images. > > Anyone know when blkid would return success but not the filesystem type? The option '-s' does not affect return code, this option controls output filter only. I have improved the description in the man page to make it more obvious. blkid returns success always when it's possible to gather any information about the device. The important detail is that the recent versions provide also PARTUUID=, so we have information about all (including empty) partitions! For example (very very old version from e2fsprogs): # blkid /dev/sdc1; echo $? 2 but the current util-linux upstream: #blkid /dev/sdc1; echo $? /dev/sdc1: PARTUUID="4b6f59ea-01" 0 And yes, we have PARTUUID also for MBR partitions, the method used to generate the UUID is the same like kernel uses for root= command line option. Note that my recommendation is to use lsblk, for example: # lsblk --noheading --output FSTYPE /dev/sda1 vfat it reads info from udev db (libblkid is only fallback here), and it provides better way how to control output. Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785116: util-linux: blkid -s returns too much information
On Thu, May 14, 2015 at 06:50:52AM +0930, Ron wrote: > Right, in the situation where you *do* want multiple values, caring > about the order should be less of a problem, since you'd just access > the variables being set rather than trying to parse or interpret > them literally. If for some reason you did care about the order, > you'd run that multiple times with one value for each invocation. > > Which, right now if you do that, you'll end up with something like: > > # blkid -s UUID -o export /dev/sda2; blkid -s TYPE -o export /dev/sda2 > DEVNAME=/dev/sda2 > UUID=9621a7e3-14a1-4d03-8250-b4fbeb7b > DEVNAME=/dev/sda2 > TYPE=ext4 > > I guess the other case where that might bite you is if you were already > using DEVNAME as a local variable for something else ... I'd like to keep blkid as very basic command line interface to libblkid and as the library test program. For standard use cases and scripts it's better to use lsblk(8) command which provides more information and better control on output format: # lsblk --pairs -o FSTYPE,UUID /dev/sda2 FSTYPE="ext4" UUID="c5490147-2a6c-4c8a-aa1b-33492034f927" # lsblk --pairs -o UUID,FSTYPE /dev/sda2 UUID="c5490147-2a6c-4c8a-aa1b-33492034f927" FSTYPE="ext4" and it reads information from udev db or from libblkid. Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785116: util-linux: blkid -s returns too much information
On Wed, May 13, 2015 at 08:36:04AM +0200, Andreas Henriksson wrote: > Possibly changing the output format now could be risky. Yes. Ron is right, the current behaviour is strange, but I'm not sure if we want to fix it after 3 years. And I'm also not sure it the current behavior is so big problem. If you want just one value than it makes more sense to use # blkid -s UUID -o value /dev/sdb1 f0710187-82bf-4646-b2e3-11b017e31218 and if you ask for more tags by "-o export" than you cannot rely on order of the lines, so DEVNAME= in the output cannot be a problem. > Lets ask upstream if DEVNAME is considered a tag which should > be included in the tag filtering CCed. I have a patch to fix it, but now when I think about it it's probably better to keep the current behavior than fix one regression by another regression ;-) Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776034: fsck runs in parallel on same physical disk
On Mon, Jan 26, 2015 at 10:36:02AM +0100, Daniel Pocock wrote: > On 26/01/15 10:32, Karel Zak wrote: > > On Mon, Jan 26, 2015 at 02:24:04AM +0100, Michael Biebl wrote: > >>>-l Create an exclusive flock(2) lock file > >>> (/run/fsck/.lock) for whole-disk > >>> device. This option can be used with one device only (this > >>> means that -A and -l are > >>> mutually exclusive). This option is recommended when > >>> more fsck(8) instances are exe- > >>> cuted in the same time. The option is ignored when used > >>> for multiple devices or for > >>> non-rotating disks. fsck does not lock underlying > >>> devices when executed to check > >>> stacked devices (e.g. MD or DM) - this feature is not > >>> implemented yet. > >> > >> Karel, is there an upstream bug report for this issue? What's the state > >> of this feature, is it actively being worked on? > > No, nobody is workning on -l for stacked devices. > > > > Karel > > > > Is there any other workaround, or should people consider moving to BtrFs > instead of using LVM on md? fsck has never been able to determine all the stack, so this is no change (change between "fsck -l" from systemd and "fsck -A" from init scripts). All the problem is possible negative impact to performance if you want to intensively use two partitions on the same hdd, that's all. The question is if this is really issue in all cases for all HW. Frankly, I'm pretty unhappy that we care about such things in userspace -- it's kernel job to schedule things and keep system performance "usable", all we can do in userspace is to inform kernel about the way how we plan to use the devices (e.g. fadvise()). The stack of the block devices maybe pretty complicated and only DM/MD kernel drivers have a clue where are things really stored. The another story is that sometimes nothing include kernel has a clue about HW, because storage maybe completely independent invisible blackbox (SAN, etc.). My recommendation is to ignore this issue, or if you really see any performance problem than disable fsck by systemd and use by hands written script to call fsck. Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776034: fsck runs in parallel on same physical disk
On Mon, Jan 26, 2015 at 02:24:04AM +0100, Michael Biebl wrote: > >-l Create an exclusive flock(2) lock file > > (/run/fsck/.lock) for whole-disk > > device. This option can be used with one device only (this > > means that -A and -l are > > mutually exclusive). This option is recommended when more > > fsck(8) instances are exe- > > cuted in the same time. The option is ignored when used for > > multiple devices or for > > non-rotating disks. fsck does not lock underlying > > devices when executed to check > > stacked devices (e.g. MD or DM) - this feature is not > > implemented yet. > > > Karel, is there an upstream bug report for this issue? What's the state > of this feature, is it actively being worked on? No, nobody is workning on -l for stacked devices. Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770211: LUKS partition types, redux
On Mon, Nov 24, 2014 at 09:42:50AM -0500, Phillip Susi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/24/2014 6:37 AM, Karel Zak wrote: > > The current trend is to use partition type to define for what > > purpose we want to use the partition (for example "this is /home") > > independently on partition format. > > I wouldn't call this bone headed idea of redhat's a trend. Using > partition table type codes to decide to auto mount in particular parts > of the filesystem is such a brain damaged idea, those who thought it > up need beaten with a clue-by-four and its use needs to be *strongly* > discouraged. well, it's designed for auto-generated fstab-less systems like containers/virt images, etc. I'm not big fan of this feature, but for some use cases it makes sense. (And it's systemd upstream decision.) Anyway, use partition type for "usage" makes more sense than for "fs-type". Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770211: LUKS partition types, redux
On Wed, Nov 19, 2014 at 02:59:01PM -0600, Drake Wilson wrote: > Summary: I would like to reopen the suggestion to add LUKS partition type > codes > for MBR and for GPT to util-linux's fdisk. In a previous discussion, it was > said that since Linux does not interpret partition types, there is no need for > this, but concrete data loss has now occurred as a result of a related bug in > other software combined with the lack of a user-visible LUKS type in a similar > partitioning program, and I believe that warrants re-examination of the > situation. But it seems that the problem is what details partitioning tools provide to end-users rather than problem with data within disk labels. I don't see problem to add FS type column to fdisk(s) (it's already linked with libblkid). > I would thus like to re-propose adding a LUKS type. Alternatively, if a LUKS > type is still considered a bad idea, I would like to suggest allocating a GPT > ID > analogous to the "da = Non-FS data" MBR type code, which would at least allow > the > user to choose a fallback that has a known null semantic, rather than tagging > their > volumes with some arbitrary ID that may be misinterpreted; that would help > avert > analogous problems for future types as well. You want to make a connection between partition type and partition format (FS, LUKS, LVM...). This idea is more than 30years old and it has been always fragile and introduced for poorly designed systems (kernels and boot loaders). The current trend is to use partition type to define for what purpose we want to use the partition (for example "this is /home") independently on partition format. For example systemd is able to generate on the fly mount table according to GPT partition types (so we have type for root and /home). All this is independent on FS/LUKS/etc. The same GUID is for XFS, ext4 ... this concept is not compatible with your idea. BTW, LUKS (and also XFS) is one of well designed on-disk formats where magic string is at the begin of the device, so all you need is one seek()+read(). Anyway, I'd like to minimize number of situations when we depend on GPT/MBR partition types at all. > (I also believe more philosophically that the user should be supported in the > possibility of integrating with other partition management systems that may > wish > to detect LUKS and do something special with it, without requiring all other > such > systems to incorporate a blkid-like system for checking in several places for > the > "basic nature" of a volume. I mention this only for the record, since the > previous > thread suggests the util-linux maintainers don't agree with this.) This is about partitioning tools, not about on-disk disk label data. Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764387: [PATCH] autogen.sh: check for libtoolize rather than libtool
On Tue, Oct 07, 2014 at 11:07:19PM +0200, Helmut Grohne wrote: > autogen.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756177: fdisk -l regression between v2.24.2 and v2.25
On Sun, Jul 27, 2014 at 12:48:06PM +0200, Andreas Henriksson wrote: > Hello Jos van Wolput! > > Thanks for your bug report. > > On Sun, Jul 27, 2014 at 03:29:38PM +0800, Jos van Wolput wrote: > [...] > > After upgrading util-linux 2.20.1-5.8 (sid) to version 2.25-3 > > (experimental) fdisk -l ends with > > the following error: cannot open /dev/sr0: No medium found > [...] > > fdisk: cannot open /dev/sr0: No medium found > > --- > > and the other devices /dev/sdb* are not shown. > > > > Indeed I don't use the cdrom (sr0) but using fdisk -l from util-linux > > 2.20.1-5.8 (sid) there is no such issue, all disks are shown: > [...] > > This seems to be a regression between 2.24.2 and 2.25 and git bisect tells > me the first bad commit is: a22c6eb206fb716fa4 > > Reverting a22c6eb206fb716fa4 and reviving wholedisk.h from 62acb047a625059e77 > makes v2.25 fdisk -l work as expected for me. > > I'm CCing the upstream developer mailing list to hopefully have some help > on finding the proper fix. Already fixed in upstream tree. The patch will be in 2.25.1 (probably at the end of the next month). Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747313: [Pkg-shadow-devel] Bug#747313: login: Please move pam_selinux open call higher in the session PAM stack
On Wed, May 07, 2014 at 02:14:34PM +0200, Laurent Bigonville wrote: > After looking at Fedora/CentOS ssh pam config file and talking with > people upstream[0] I think that the call to pam_selinux open should be > moved higher in the session stack (just after pam_loginuid and before > pam_keyinit to follow what Fedora is doing). just for curiosity, why do you still use ligin(1) from shadow-utils? Does it have any feature that is missing in util-linux login(1)? Note that we spent a lot time to make util-linux login(1) compatible with Suse, /etc/login.defs and to make it PAM-only etc. Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675569: Fixed in upstream
On Thu, Jun 21, 2012 at 05:38:58PM +0200, Hilko Bengen wrote:
> After actually reading what Mika had said about the bug still affecting
> upstream, I have identified another error message that should probably
> not cause agetty to abort:
>
> /dev/ttyS2: cannot set process group: Inappropriate ioctl for device
Good catch, TIOCSCTTY is optional in the current code so tcsetpgrp()
should not be required too.
Fixed. Thanks.
> (Unless these errors are all symptoms of another problem, that is.)
The question is why your agetty is not able to get controlling tty.
Karel
--
Karel Zak
http://karelzak.blogspot.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634871: mount refuses to update mtab if there's any entry with "none"
On Wed, Jul 20, 2011 at 07:30:32PM +0200, Tomas Janousek wrote: > tab_parse.c:mnt_parse_mountinfo_line parses "none" in src as NULL, > tab_update.c:fprintf_mtab_fs sets m1 to NULL instead of "none" and returns > -ENOMEM, > tab_update.c:update_table says "write entry failed: Success", as errno hasn't > been set, and gotos to leave, leaving mtab not updated. Fixed by upstream commit 696b84b30a31dcb2fb1383d5afe08abcc1597eab (in stable/v2.19 branch). Thanks! > You definitely owe me a beer, Karel! :-) When and where? :-) Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110720200317.gd22...@nb.net.home
Bug#613589: /sbin/cfdisk: Bad Table error after fresh Squeeze install
On Thu, Apr 14, 2011 at 09:28:05AM +0200, Olaf van der Spek wrote: > On Thu, Apr 14, 2011 at 9:19 AM, Karel Zak wrote: > > On Wed, Apr 13, 2011 at 09:36:28AM +0200, Olaf van der Spek wrote: > >> On Wed, Apr 13, 2011 at 9:33 AM, Timo Juhani Lindfors > >> wrote: > >> > Olaf van der Spek writes: > >> >> In that case it should be forwarded upstream. > >> > > >> > Sure, but I couldn't find the upstream BTS. I was just adding extra info > >> > to the bug report since I hit the same bug. > >> > >> Let's CC the author of the patch. > >> > >> Hi Karel, > >> > >> We're hitting a check you added to this utility. We think it's a bug. > >> Could you have a look at it? > >> > >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613589 > > > > Fixed by commit 73356e0553bd9ac00f556891a4798064c0ee6849 (v2.19). > > Thanks. Do you know where the upstream bug tracker can be found? We don't have upstream bug tracker. I prefer downstream -> patch -> upstream and I'd like to keep upstream focused on development and I don't want to do support for end-users. This model works fine in last 5 years. If you are not sure about any issue then you can ask at upstream mailing list. http://userweb.kernel.org/~kzak/util-linux/ Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613589: /sbin/cfdisk: Bad Table error after fresh Squeeze install
On Wed, Apr 13, 2011 at 09:36:28AM +0200, Olaf van der Spek wrote: > On Wed, Apr 13, 2011 at 9:33 AM, Timo Juhani Lindfors > wrote: > > Olaf van der Spek writes: > >> In that case it should be forwarded upstream. > > > > Sure, but I couldn't find the upstream BTS. I was just adding extra info > > to the bug report since I hit the same bug. > > Let's CC the author of the patch. > > Hi Karel, > > We're hitting a check you added to this utility. We think it's a bug. > Could you have a look at it? > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613589 Fixed by commit 73356e0553bd9ac00f556891a4798064c0ee6849 (v2.19). Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#494001: Bug: mount: "user" mounts broken when /etc/mtab is a symlink
On Sun, Jan 09, 2011 at 12:37:49PM +, Roger Leigh wrote: > I just wanted to check with you which versions of util-linux-ng would > work correctly with /etc/mtab removed [...] > If 2.19 is required Yes. Note that "mtab removed" means mtab is symlink to /proc/mounts :-) > I'd be interested to know how experimental libmount support is. The code is not well tested. > i.e. are there any known regressions or failing use cases which we > should be aware of, or any other reasons not to enable it at this > point? Probably the most problematic thing is read-only bind. The problem is described in the mount man page and this problem is not specific to 2.19, but to all systems without mtab. with mtab: mount --bind olddir newdir mount -o remount,ro newdir without mtab: mount --bind olddir newdir mount -o remount,ro,bind olddir newdir The another problem is mount -o loop /path/foo.img /mnt mount | grep /path/foo.img where the grep command returns nothing on systems without mtab and with old kernels (< 2.6.37). The latest kernel provides info about loopdevs in /sys, so mtab is unnecessary. > Have you removed mtab in Fedora/RedHat yet? Yes, this is my plan for Fedora rawhide, because mtab is unsupported by systemd. On systems without systemd I'd suggest to be conservative and compile mount without --enable-libmount-mount. Note that more utils depend on mtab. It's not enough to updated mount(8) -- the long term goal is to modify also mount. helpers to use libmount library (this is my goal for this year). Then we can say that mtab is really dead. Karel -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510130: Error calculing volhdr partition boundaries on SGI disklabel
On Thu, Nov 25, 2010 at 05:58:37PM +0100, Moritz Muehlenhoff wrote:
> > --- util-linux-2.13.1.1.orig/fdisk/fdisksgilabel.c
> > +++ util-linux-2.13.1.1/fdisk/fdisksgilabel.c
> > @@ -501,6 +501,9 @@
> > }
> > start = sgi_get_start_sector(Index[i])
> > + sgi_get_num_sectors(Index[i]);
> > + /* Align free space on cylinder boundary */
> > + if (start % cylsize != 0)
> > + start += cylsize - (start % cylsize);
> > if (debug > 1) {
> > if (verbose)
> > printf("%2d:%12d\t%12d\t%12d\n", Index[i],
>
> Karel,
> what do you think about the patch proposed by Aurelien?
Applied, thanks.
Karel
--
Karel Zak
http://karelzak.blogspot.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566072: [PATCH] fsck: list nonexistent devices that are declared without nofail
On Sat, Oct 23, 2010 at 11:53:13AM +0200, Serafeim Zanikolas wrote: > Pardon me for being persistent. Have you missed the email below, or do you > find the argument unconvincing? Yes, unconvincing. Sorry. Karel > On Thu, Oct 07, 2010 at 10:13:34PM +0200, Serafeim Zanikolas wrote: > > On Thu, Oct 07, 2010 at 10:56:49AM +0200, Karel Zak wrote: > > > On Sat, Oct 02, 2010 at 02:26:58PM +0200, Serafeim Zanikolas wrote: > > > > fsck -A output does not indicate the offending device(s), when a device > > > > is > > > > nonexistent and declared without nofail (e2fsck doesn't mention > > > > anything, and > > > > dosfsck outputs just "No such file or directory") > > > > > > Hmm... I'd like to be conservative with this kind of warnings. The > > > "nofail" option is relatively new and I guess that many people still > > > successfully rely on the old behavior (because e2fsck doesn't mention > > > anything ;-). > > > > The motivation is that, currently, fsck bombs out during system boot without > > any hint (which, I hope you'll agree, is not helpful). A -V option won't > > make > > any difference for this use case. > > > > > I have applied the patch below -- it prints the warning if -V > > > (verbose) option is specified. > > > > ignore() is called multiple times per filesystem, so it's not the best place > > to put the warning, imho. > > > > -S > -- > To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Karel Zak http://karelzak.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593336: New version breaks encfs in some ways in combination with pam_encfs
On Thu, Oct 07, 2010 at 04:05:12PM +0200, Miklos Szeredi wrote:
> On Thu, 07 Oct 2010, Thomas Schwery wrote:
> > > Could someone who can reproduce this please do a "strace -f" of the
> > > login process to see where it hangs?
> >
> > You will find attached a trace ('strace -o login_trace -f login') of the
> > login process for root (a normal user would fail with a "Operation not
> > permitted" error).
> >
> > I had to interrupt the trace because after 10 minutes, nothing more
> > happened ... The last line printed during login by encfs / pam-encfs is :
> > (Interface.cpp:165) checking if nameio/block(3:0:1) implements
> > nameio/block(3:0:0)
>
> Thomas, thanks for the quick response.
>
> It looks like --no-canonicalize isn't working 100% correctly in
This is my mistake, I forgot that we call canonicalize() also from
fsprobe_get_devname_by_spec().
> mount(8). Here's a patch to fix it. Coud you please rebuild
> util-linux with this patch to verify that it fixes the hang?
>
> Karel, does this patch look OK?
Yes. Applied, thanks!
Karel
--
Karel Zak
http://karelzak.blogspot.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#579948: [parted-devel] Some debugging info
On Mon, Jun 14, 2010 at 01:06:09PM +0100, Colin Watson wrote:
> parted-devel, can anyone comment on this? It seems to me that either
> (a) _get_lax_constraint should be using ped_alignment_any for its start
> alignment, rather than aligning to sectors * heads boundaries, or (b)
> Sun labels really and truly require cylinder alignment, in which case
> requests to use optimal alignment shouldn't be honoured.
The begin of the partition has to be defined in cylinders:
struct __attribute__ ((packed)) _SunRawPartition {
u_int32_t start_cylinder; /* where the part starts... */
u_int32_t num_sectors;/* ...and it's length */
};
IMHO it does not make sense to use non-cylinder alignment here.
Karel
--
Karel Zak
http://karelzak.blogspot.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505271: [Pkg-shadow-devel] Bug#505271: Bug#505071: login tty mis-determination (see bug#332198)
On Mon, Dec 08, 2008 at 11:22:34AM +0100, Nicolas François wrote:
> On Mon, Dec 08, 2008 at 09:37:42AM +1100, [EMAIL PROTECTED] wrote:
> > > The bug should affect ubuntu and probably gentoo (4.1.2.2 already
> > > packaged). Not RedHat / Mandrake.
> >
> > A quick peek into shadow-utils-4.1.2-8.fc10.src.rpm suggests Fedora is
> > also affected. I do not know about RHEL.
>
> shadow-utils.spec:rm $RPM_BUILD_ROOT/%{_bindir}/login
>
> makes me think Fedora / RHEL should be free of login's bugs.
yes, we use the classic login(1) from util-linux(-ng).
Karel
--
Karel Zak <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
