* Re: Escape sequences in /var/log/auth.log
From: Karel Zak @ 2024-03-04 12:33 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: Serge E. Hallyn, util-linux
In-Reply-To: <ZeRYJ6HD77humJzg@debian>
On Sun, Mar 03, 2024 at 11:59:51AM +0100, Alejandro Colomar wrote:
> This seems to be a bug in util-linux, not shadow, so I've added
> util-linux@ to the thread.
Fixed. Thanks for your report.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: Escape sequences in /var/log/auth.log
From: Alejandro Colomar @ 2024-03-03 10:59 UTC (permalink / raw)
To: Serge E. Hallyn, util-linux
Cc: Skyler Ferrante (RIT Student), Christian Brauner, Iker Pedrosa
In-Reply-To: <20240302173316.GA1508977@mail.hallyn.com>
[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]
Hi,
This seems to be a bug in util-linux, not shadow, so I've added
util-linux@ to the thread.
The discussion started in the email below, and was later continued in
<https://github.com/shadow-maint/shadow/pull/960>.
Have a lovely day!
Alex
On Sat, Mar 02, 2024 at 11:33:16AM -0600, Serge E. Hallyn wrote:
> On Sat, Mar 02, 2024 at 11:34:07AM -0500, Skyler Ferrante (RIT Student) wrote:
> > Hi Serge,
> >
> > I was playing around with some of the shadow-utils binaries and I
> > realized that an unprivileged user can set argv[0] to contain escape
> > sequences, and then cause it to be logged in /var/log/auth.log.
> >
> > PoC
> > ```
> > #include<stdio.h>
> > #include<unistd.h>
> > int main(int argc, char** my_argv){
> > char* prog = "/usr/bin/su";
> > char* argv[] = {"\033[33mYellow", "root", NULL};
> > char* envp[] = {NULL};
> >
> > execve(prog, argv, envp);
> > printf("Failed to exec\n");
> > }
> > ```
> > Run the binary, and type an incorrect password for root. Now run `tail
> > /var/log/auth.log`. It should contain Yellow text. This can be used to
> > hide log contents (move the cursor/delete characters). Some terminals
> > also allow setting clipboard contents through escape sequences (my
> > terminal, windows-terminal, supports this).
> >
> > It may be a good idea to refuse argv[0] if it contains binary data.
> > You could also prevent this bug by not allowing an attacker to choose
> > Prog (e.g. su could just use "su" as Prog).
> >
> > If you don't think this is a bad enough security issue to hide, I can
> > post an issue on github. I would argue that you shouldn't cat auth.log
> > or view it from tail, but I know a lot of people do.
> >
> > Cheers,
> > Skyler
>
> Terminals can be a nuisance :)
>
> I don't think we need to hide this issue, but of course definitely address
> it. I'm Cc:ing the other maintainers in case they feel differently.
>
> Did you want to send a PR to fix it?
>
> Thanks,
> -serge
--
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Finding a block device quickly with libblkid
From: Eric Curtin @ 2024-03-01 18:30 UTC (permalink / raw)
To: util-linux, systemd-devel; +Cc: Eric Chanudet, Brian Masney
Hi Guys,
We are looking into optimizing the boot sequence of a device with many
partitions.
On boot in the default systemd implementation, all the block devices
are queried via libblkid and the various symlinks are set up in
/dev/disk/* from the results of those queries. The problem is on a
device with many partitions this can delay the boot by hundreds of
milliseconds, which is not ideal, especially when in many cases all
you really care about is mounting the block device that represents the
rootfs partition. We can sort of guess "/dev/sde38" is the correct
one, but that's not deterministic.
So we started digging and came across blkid_find_dev_with_tag and
blkid_dev_devname, which you can call like this:
blkid_dev_devname(blkid_find_dev_with_tag(cache, "PARTLABEL", "system_a")))
blkid_dev_devname(blkid_find_dev_with_tag(cache, "PARTLABEL", "system_b")))
On first glance this looks useful as you don't have to loop through
all the devices to use.
But this function only seems to work if the data is already cached, so
it's not so useful on boot.
Has anyone any ideas on how we can optimize the identification of a
block device via UUID, LABEL, PARTUUID, PARTLABEL, etc.? Because the
current implementations don't scale well when you have many block
devices.
I suspect we may not be the first to encounter this, so just probing
to see if anyone had ideas on how to solve this in the past.
Is mise le meas/Regards,
Eric Curtin
^ permalink raw reply
* [ANNOUNCE] util-linux v2.40-rc2
From: Karel Zak @ 2024-02-29 21:25 UTC (permalink / raw)
To: linux-kernel, linux-fsdevel, util-linux
The util-linux release v2.40-rc2 is available at
http://www.kernel.org/pub/linux/utils/util-linux/v2.40/
Feedback and bug reports, as always, are welcomed.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] setterm: Document behavior of redirection
From: Karel Zak @ 2024-02-29 18:56 UTC (permalink / raw)
To: Stanislav Brabec; +Cc: util-linux@vger.kernel.org
In-Reply-To: <2b12341f-5935-463c-8301-a4a4f139541c@suse.cz>
On Wed, Feb 28, 2024 at 03:06:14PM +0100, Stanislav Brabec wrote:
> term-utils/setterm.1.adoc | 4 ++++
> 1 file changed, 4 insertions(+)
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH] setterm: Document behavior of redirection
From: Stanislav Brabec @ 2024-02-28 14:06 UTC (permalink / raw)
To: util-linux@vger.kernel.org
Debugging an error of setterm, I realized that setterm --powerdown operates
on stdout but setterm --powersave operates on stdin. Such unexpected
behavior should be documented.
I prefer a less accurate generic "always redirect both stdin and stdout"
over recommending of the correct I/O stream for each option separately.
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
---
term-utils/setterm.1.adoc | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/term-utils/setterm.1.adoc b/term-utils/setterm.1.adoc
index 880fe10d6..365c4bb00 100644
--- a/term-utils/setterm.1.adoc
+++ b/term-utils/setterm.1.adoc
@@ -156,6 +156,10 @@ Turns underline mode on or off.
include::man-common/help-version.adoc[]
+== WARNING
+
+Use of *setterm* in combination with stdout redirection can have
unexpected results, as some options operate on stdin. To prevent
problems, always redirect both stdin and stdout to the same device.
+
== COMPATIBILITY
Since version 2.25 *setterm* has support for long options with two
hyphens, for example *--help*, beside the historical long options with a
single hyphen, for example *-help*. In scripts it is better to use the
backward-compatible single hyphen rather than the double hyphen.
Currently there are no plans nor good reasons to discontinue
single-hyphen compatibility.
--
2.43.0
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com
Křižíkova 148/34 (Corso IIa) tel: +420 284 084 060
186 00 Praha 8-Karlín fax: +420 284 084 001
Czech Republic http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
^ permalink raw reply related
* Re: [PATCH] libmount: don't hold write fd to mounted device
From: Karel Zak @ 2024-02-26 8:53 UTC (permalink / raw)
To: Jan Kara; +Cc: util-linux, Christian Brauner, JunChao Sun
In-Reply-To: <20240221173050.21970-1-jack@suse.cz>
On Wed, Feb 21, 2024 at 06:30:50PM +0100, Jan Kara wrote:
> libmount/src/hook_loopdev.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] libmount: don't hold write fd to mounted device
From: Christian Brauner @ 2024-02-22 9:19 UTC (permalink / raw)
To: Jan Kara; +Cc: util-linux, JunChao Sun
In-Reply-To: <20240221173050.21970-1-jack@suse.cz>
On Wed, Feb 21, 2024 at 06:30:50PM +0100, Jan Kara wrote:
> Avoid holding writeable fd to a loop device that is being mounted. In
> the hardened configurations (CONFIG_BLK_DEV_WRITE_MOUNTED = n) the
> kernel wants to make sure nobody else has the block device writeably
> open when mounting so this makes the mount fail.
>
> Reported-by: JunChao Sun <sunjunchao2870@gmail.com>
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
Sounds good!
Acked-by: Christian Brauner <brauner@kernel.org>
> libmount/src/hook_loopdev.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/libmount/src/hook_loopdev.c b/libmount/src/hook_loopdev.c
> index 8c8f7f218732..e2114b0cbebe 100644
> --- a/libmount/src/hook_loopdev.c
> +++ b/libmount/src/hook_loopdev.c
> @@ -356,15 +356,19 @@ success:
> */
> mnt_optlist_append_flags(ol, MS_RDONLY, cxt->map_linux);
>
> - /* we have to keep the device open until mount(1),
> - * otherwise it will be auto-cleared by kernel
> + /*
> + * We have to keep the device open until mount(1), otherwise it
> + * will be auto-cleared by kernel. However we don't want to
> + * keep writeable fd as kernel wants to block all writers to
> + * the device being mounted (in the more hardened
> + * configurations). So grab read-only fd instead.
> */
> - hd->loopdev_fd = loopcxt_get_fd(&lc);
> + hd->loopdev_fd = open(lc.device, O_RDONLY | O_CLOEXEC);
> if (hd->loopdev_fd < 0) {
> - DBG(LOOP, ul_debugobj(cxt, "failed to get loopdev FD"));
> + DBG(LOOP,
> + ul_debugobj(cxt, "failed to reopen loopdev FD"));
> rc = -errno;
> - } else
> - loopcxt_set_fd(&lc, -1, 0);
> + }
> }
> done:
> loopcxt_deinit(&lc);
> --
> 2.35.3
>
^ permalink raw reply
* [PATCH] libmount: don't hold write fd to mounted device
From: Jan Kara @ 2024-02-21 17:30 UTC (permalink / raw)
To: util-linux; +Cc: Christian Brauner, Jan Kara, JunChao Sun
Avoid holding writeable fd to a loop device that is being mounted. In
the hardened configurations (CONFIG_BLK_DEV_WRITE_MOUNTED = n) the
kernel wants to make sure nobody else has the block device writeably
open when mounting so this makes the mount fail.
Reported-by: JunChao Sun <sunjunchao2870@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
---
libmount/src/hook_loopdev.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/libmount/src/hook_loopdev.c b/libmount/src/hook_loopdev.c
index 8c8f7f218732..e2114b0cbebe 100644
--- a/libmount/src/hook_loopdev.c
+++ b/libmount/src/hook_loopdev.c
@@ -356,15 +356,19 @@ success:
*/
mnt_optlist_append_flags(ol, MS_RDONLY, cxt->map_linux);
- /* we have to keep the device open until mount(1),
- * otherwise it will be auto-cleared by kernel
+ /*
+ * We have to keep the device open until mount(1), otherwise it
+ * will be auto-cleared by kernel. However we don't want to
+ * keep writeable fd as kernel wants to block all writers to
+ * the device being mounted (in the more hardened
+ * configurations). So grab read-only fd instead.
*/
- hd->loopdev_fd = loopcxt_get_fd(&lc);
+ hd->loopdev_fd = open(lc.device, O_RDONLY | O_CLOEXEC);
if (hd->loopdev_fd < 0) {
- DBG(LOOP, ul_debugobj(cxt, "failed to get loopdev FD"));
+ DBG(LOOP,
+ ul_debugobj(cxt, "failed to reopen loopdev FD"));
rc = -errno;
- } else
- loopcxt_set_fd(&lc, -1, 0);
+ }
}
done:
loopcxt_deinit(&lc);
--
2.35.3
^ permalink raw reply related
* Re: [PATCH] Mention systemd implementation of fsck
From: Stanislav Brabec @ 2024-02-17 20:01 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <20240215093755.557tkkvtcnshaot4@ws.net.home>
Dne 15. 02. 24 v 10:37 Karel Zak napsal(a):
> On Wed, Feb 14, 2024 at 03:23:45PM +0100, Karel Zak wrote:
>> What about:
>>
>> systemd does not invoke fsck -A to check all devices; instead, it
>> calls fsck individually for devices selected based on the logic
>> implemented in systemd-fsck.
> I had short discussion about it with Lennart, and he suggested not to
> document anywhere systemd-fsck as it's private systemd stuff. I have
> pushed to repository:
>
> https://github.com/util-linux/util-linux/commit/9cb7b7671d903573d6c3b9d8112ec13953cdcdc6
It sound clear. I didn't want to document any details of the
implementation in the third party package and it will not need an
update in case of an systemd change.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com
Křižíkova 148/34 (Corso IIa) tel: +420 284 084 060
186 00 Praha 8-Karlín fax: +420 284 084 001
Czech Republic http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
^ permalink raw reply
* Re: [PATCH] Mention systemd implementation of fsck
From: Karel Zak @ 2024-02-15 9:37 UTC (permalink / raw)
To: Stanislav Brabec; +Cc: util-linux
In-Reply-To: <20240214142342.x24dioosah2i27na@ws.net.home>
On Wed, Feb 14, 2024 at 03:23:45PM +0100, Karel Zak wrote:
> On Wed, Feb 14, 2024 at 01:17:46PM +0100, Stanislav Brabec wrote:
> > systemd uses its own implementation of fsck with a slightly different
> > behavior (e. g. fsck -A checks noauto volumes, systemd-fsck does not).
>
> systemd calls fsck from util-linux, but a new instance (with -l) for each device.
> It would be nice to be more explicit and explain it, because "it has its
> own implementation" sounds like fsck from util-linux is completely out
> of game :-)
>
> > +== NOTES
> > +*systemd* does not call *fsck -A*, but it has its own implementation
> > *systemd-fsck*(8).
>
> What about:
>
> systemd does not invoke fsck -A to check all devices; instead, it
> calls fsck individually for devices selected based on the logic
> implemented in systemd-fsck.
I had short discussion about it with Lennart, and he suggested not to
document anywhere systemd-fsck as it's private systemd stuff. I have
pushed to repository:
https://github.com/util-linux/util-linux/commit/9cb7b7671d903573d6c3b9d8112ec13953cdcdc6
Hope it good enough :-)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] Mention systemd implementation of fsck
From: Karel Zak @ 2024-02-14 14:23 UTC (permalink / raw)
To: Stanislav Brabec; +Cc: util-linux
In-Reply-To: <adf1f630-a264-4db7-9777-d4e2de2bad3b@suse.cz>
On Wed, Feb 14, 2024 at 01:17:46PM +0100, Stanislav Brabec wrote:
> systemd uses its own implementation of fsck with a slightly different
> behavior (e. g. fsck -A checks noauto volumes, systemd-fsck does not).
systemd calls fsck from util-linux, but a new instance (with -l) for each device.
It would be nice to be more explicit and explain it, because "it has its
own implementation" sounds like fsck from util-linux is completely out
of game :-)
> +== NOTES
> +*systemd* does not call *fsck -A*, but it has its own implementation
> *systemd-fsck*(8).
What about:
systemd does not invoke fsck -A to check all devices; instead, it
calls fsck individually for devices selected based on the logic
implemented in systemd-fsck.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH] Mention systemd implementation of fsck
From: Stanislav Brabec @ 2024-02-14 12:17 UTC (permalink / raw)
To: util-linux
systemd uses its own implementation of fsck with a slightly different
behavior (e. g. fsck -A checks noauto volumes, systemd-fsck does not).
Refer to it.
It is a complementar change to
https://github.com/systemd/systemd/commit/000680a68d.
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
---
disk-utils/fsck.8.adoc | 4 ++++
sys-utils/fstab.5.adoc | 2 ++
2 files changed, 6 insertions(+)
diff --git a/disk-utils/fsck.8.adoc b/disk-utils/fsck.8.adoc
index 976e7ff08..4ba6f4cc1 100644
--- a/disk-utils/fsck.8.adoc
+++ b/disk-utils/fsck.8.adoc
@@ -151,6 +151,9 @@ enables libmount debug output.
_/etc/fstab_
+== NOTES
+*systemd* does not call *fsck -A*, but it has its own implementation
*systemd-fsck*(8).
+
== AUTHORS
mailto:tytso@mit.edu>[Theodore Ts'o],
@@ -169,6 +172,7 @@ mailto:kzak@redhat.com[Karel Zak]
*fsck.vfat*(8),
*fsck.xfs*(8),
*reiserfsck*(8)
+*systemd-fsck*(8)
include::man-common/bugreports.adoc[]
diff --git a/sys-utils/fstab.5.adoc b/sys-utils/fstab.5.adoc
index 1b972ef3b..0f12560e3 100644
--- a/sys-utils/fstab.5.adoc
+++ b/sys-utils/fstab.5.adoc
@@ -132,6 +132,8 @@ The proper way to read records from *fstab* is to
use the routines *getmntent*(3
The keyword *ignore* as a filesystem type (3rd field) is no longer
supported by the pure libmount based mount utility (since util-linux v2.22).
+This document describes handling of *fstab* by *util-linux* and
*libmount*. For *systemd*, read *systemd* documentation. There are
slight differences.
+
== HISTORY
The ancestor of this *fstab* file format appeared in 4.0BSD.
--
2.43.0
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com
Křižíkova 148/34 (Corso IIa)
186 00 Praha 8-Karlín
Czech Republic http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
^ permalink raw reply related
* Re: fsck exits 0 with no output (just version) when it doesn't find a type-specific fsck
From: наб @ 2024-02-08 14:24 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <20240208115549.4iucrphww74l5zna@ws.net.home>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Thu, Feb 08, 2024 at 12:55:49PM +0100, Karel Zak wrote:
> On Wed, Feb 07, 2024 at 06:52:47PM +0100, наб wrote:
> > I think in -A mode it makes sense to silently ignore a lack of type-specific fsck.
> > But when explicitly requesting fsck /dev/whatever, that condition
> > should at /least/ warn (I'm assuming erroring out would be too invasive),
> > because right now fsck cleared my potentially-broken filesystem w/o checks.
> Good idea, possible improvements:
> https://github.com/util-linux/util-linux/pull/2777
Looks good, works for me.
(The warning is in slavic word order, though;
ought to be "fsck.%s not found".)
Best,
наб
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: fsck exits 0 with no output (just version) when it doesn't find a type-specific fsck
From: Karel Zak @ 2024-02-08 11:55 UTC (permalink / raw)
To: наб; +Cc: util-linux
In-Reply-To: <f63r2qpu2tzoaabfsuq5yjlqguystzu4tyjvok3etadzy4ouk6@tarta.nabijaczleweli.xyz>
On Wed, Feb 07, 2024 at 06:52:47PM +0100, наб wrote:
> I think in -A mode it makes sense to silently ignore a lack of type-specific fsck.
> But when explicitly requesting fsck /dev/whatever, that condition
> should at /least/ warn (I'm assuming erroring out would be too invasive),
> because right now fsck cleared my potentially-broken filesystem w/o checks.
Good idea, possible improvements:
https://github.com/util-linux/util-linux/pull/2777
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* fsck exits 0 with no output (just version) when it doesn't find a type-specific fsck
From: наб @ 2024-02-07 17:52 UTC (permalink / raw)
To: util-linux
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
Downstream bug: https://bugs.debian.org/1062208
Just got
[ 3030.473467] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
great idea! After unmounting I did
# fsck /dev/mmcblk1p1
fsck from util-linux 2.39.3
which is just --version. Maybe
# fsck -AR
fsck from util-linux 2.39.3
so also no.
strace says
close(6</sys/devices/platform/soc/11240000.mmc/mmc_host/mmc1/mmc1:e624/block/mmcblk1/mmcblk1p1/start>) = 0
close(5</sys/devices/platform/soc/11240000.mmc/mmc_host/mmc1/mmc1:e624/block/mmcblk1/mmcblk1p1>) = 0
close(3</dev/mmcblk1p1>) = 0
munmap(0xffffa8eb7000, 266240) = 0
munmap(0xffffa8e76000, 266240) = 0
munmap(0xffffa8e35000, 266240) = 0
munmap(0xffffa8df4000, 266240) = 0
close(4</dev/mmcblk1>) = 0
faccessat(AT_FDCWD</root>, "/usr/local/sbin/fsck.vfat", X_OK) = -1 ENOENT (No such file or directory)
faccessat(AT_FDCWD</root>, "/usr/local/bin/fsck.vfat", X_OK) = -1 ENOENT (No such file or directory)
faccessat(AT_FDCWD</root>, "/usr/sbin/fsck.vfat", X_OK) = -1 ENOENT (No such file or directory)
faccessat(AT_FDCWD</root>, "/usr/bin/fsck.vfat", X_OK) = -1 ENOENT (No such file or directory)
faccessat(AT_FDCWD</root>, "/sbin/fsck.vfat", X_OK) = -1 ENOENT (No such file or directory)
faccessat(AT_FDCWD</root>, "/bin/fsck.vfat", X_OK) = -1 ENOENT (No such file or directory)
dup(1<pipe:[10683]>) = 3<pipe:[10683]>
close(3<pipe:[10683]>) = 0
dup(2<pipe:[10683]>) = 3<pipe:[10683]>
close(3<pipe:[10683]>) = 0
exit_group(0) = ?
+++ exited with 0 +++
which looks like a failed path traversal and then nothing?
I think in -A mode it makes sense to silently ignore a lack of type-specific fsck.
But when explicitly requesting fsck /dev/whatever, that condition
should at /least/ warn (I'm assuming erroring out would be too invasive),
because right now fsck cleared my potentially-broken filesystem w/o checks.
Best,
наб
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* branches and v2.40
From: Karel Zak @ 2024-02-05 11:23 UTC (permalink / raw)
To: util-linux
Hi all,
I've created a "stable/v2.40" branch where we will continue to work on
v2.40 (rc2, etc). The "master" branch will be used for development as
usual, and relevant bug fixes will be ported to the stable branch.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Details of the order
From: Edmond Downton @ 2024-02-02 9:05 UTC (permalink / raw)
To: util-linux
Hi,
We are a manufacturing company from Poland, and we have created unique packaging solutions that are a novelty in the market and work perfectly not only for ice cream, sweets, and other snacks but also for funnels, candles, and lanterns.
This is a reusable product with a delicate structure, lightweight, and an attractive appearance. It offers an excellent alternative to traditional napkins that become unpleasantly sticky and soft when exposed to moisture.
If you are interested in such a solution, please contact us, and we will be happy to provide more details.
Best regards
Edmond Downton
^ permalink raw reply
* Re: fdisk corrupts data on USB stick
From: Thorsten Glaser @ 2024-01-29 22:45 UTC (permalink / raw)
To: Bill Unruh; +Cc: util-linux
In-Reply-To: <10251865-9fc4-2dff-1054-673e64c67fe2@physics.ubc.ca>
Bill Unruh dixit:
> Great. I am just pointing out a program which seems to do exactly what you
> want.
It’s called fdisk. This does what I want. Only the one from
util-linux does more.
> Clearly had others know of your manifold-boot, they might well have used that
> instead of instead of reinventing isohybrid.
Huh? Grml used it.
Anyway, that’s independent, as the problem here does not come from
initial partitioning but from adding one more partition.
And I got an actually useful reply in the other subthread, so no
need to continue here.
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
^ permalink raw reply
* Re: fdisk corrupts data on USB stick
From: Bill Unruh @ 2024-01-29 22:36 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: util-linux
In-Reply-To: <Pine.BSM.4.64L.2401292219080.19873@herc.mirbsd.org>
[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ theory.physics.ubc.ca/
On Mon, 29 Jan 2024, Thorsten Glaser wrote:
> [CAUTION: Non-UBC Email]
>
> Bill Unruh dixit:
>
>> the usb. Now you will have a 2GB partition on the usb that you can write to
>> etc. It will I believe be ext4 by default although you can choose others. No
>
> Again, I prefer to keep the original ISO 9660 filesystem
> at the beginning of the stick so it doesn’t get modified
> (by accident or not).
isodumper does install the iso filesystem at the beginning of the usb. The
persistant partition uses up the free end of the usb.
>
> I’ve been doing this for ages, in fact I good as invented
> making ISOs directly bootable (before isohybrid reinvented
> the same thing, though mine for MirBSD also boot on sparc)
> under the name manifold-boot. Incidentally also for grml.
Great. I am just pointing out a program which seems to do exactly what you
want. Using it is of course up to you. Of course if you are not on Mageia or a
close derivative, I have no idea if it will work for you without some work, so
another solution might well be better. But solutions already exist.
Clearly had others know of your manifold-boot, they might well have used that
instead of instead of reinventing isohybrid.
>
> bye,
> //mirabilos
> --
> 16:47⎜«mika:#grml» .oO(mira ist einfach gut....) 23:22⎜«mikap:#grml»
> mirabilos: und dein bootloader ist geil :) 23:29⎜«mikap:#grml» und ich
> finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
> gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
>
>
^ permalink raw reply
* Re: fdisk corrupts data on USB stick
From: Thorsten Glaser @ 2024-01-29 22:27 UTC (permalink / raw)
To: Bill Unruh; +Cc: util-linux
In-Reply-To: <70cac0f2-ec94-33f7-4a5d-c17f8eb82588@physics.ubc.ca>
Bill Unruh dixit:
> the usb. Now you will have a 2GB partition on the usb that you can write to
> etc. It will I believe be ext4 by default although you can choose others. No
Again, I prefer to keep the original ISO 9660 filesystem
at the beginning of the stick so it doesn’t get modified
(by accident or not).
I’ve been doing this for ages, in fact I good as invented
making ISOs directly bootable (before isohybrid reinvented
the same thing, though mine for MirBSD also boot on sparc)
under the name manifold-boot. Incidentally also for grml.
bye,
//mirabilos
--
16:47⎜«mika:#grml» .oO(mira ist einfach gut....) 23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :) 23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
^ permalink raw reply
* Re: fdisk corrupts data on USB stick
From: Bill Unruh @ 2024-01-29 22:11 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: util-linux
In-Reply-To: <Pine.BSM.4.64L.2401292118320.19873@herc.mirbsd.org>
[-- Attachment #1: Type: text/plain, Size: 7038 bytes --]
On Mageia, run isodumper. It asks if you want to create a persistant
partition. Tell it to put a persistent partition of of 2GB or so to fill up
the usb. Now you will have a 2GB partition on the usb that you can write to
etc. It will I believe be ext4 by default although you can choose others. No
need for fdisk. As has been stated this is not something that fdisk is
designed for. If you want to fix it so it will do what you want, you are of
course free to do so. Otherwise it is far simpler to use a tool that does what
you want already.
I suspect that isodumper would also work on other linux versions, but do not
know for sure. It is a Python based program, so you would need the appropriate
version of Python installed (or just install Mageia :-). Maybe Debian could
import it.
Of course it would then be irrelevant for
util-linux
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ theory.physics.ubc.ca/
On Mon, 29 Jan 2024, Thorsten Glaser wrote:
> [CAUTION: Non-UBC Email]
>
> Bill Unruh dixit:
>
>> Perhaps if you told us what you really wanted to do, instead of asking
>> why your first method did not work and how to fix it. Eg, you wnat to
>> add another partition to the usb disk since the boot system only used
>> 5GB of a 128GB usb, and you don't want to waste 123GB of space.
>
> Something like that.
>
> I have: an ISO 9660 filesystem that already contains a bootable MBR
> with a partition table and even inlines an EFI thingy:
>
> tglase@x61w:~ $ /sbin/fdisk -l /tmp/grml96-full_2022.11.iso
> Disk /tmp/grml96-full_2022.11.iso: 1.62 GiB, 1734606848 bytes, 3387904 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x2e49ce75
>
> Device Boot Start End Sectors Size Id Type
> /tmp/grml96-full_2022.11.iso1 * 0 3387903 3387904 1.6G 0 Empty
> /tmp/grml96-full_2022.11.iso2 628 8819 8192 4M ef EFI (FAT-12/16/32)
>
> I can dd(8) that to a USB stick and it’ll be bootable. My USB stick
> measures 4 GiB however, so I wanted to add a third partition that
> uses the remaining space to store extra data, which I can then use
> in the live system, alongside on the stick:
>
> tglase@x61w:~ $ sudo fdisk -l /dev/sdb
> Disk /dev/sdb: 3.73 GiB, 4009754624 bytes, 7831552 sectors
> Disk model: Flash Disk
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x2e49ce75
>
> Device Boot Start End Sectors Size Id Type
> /dev/sdb1 * 0 3387903 3387904 1.6G 0 Empty
> /dev/sdb2 628 8819 8192 4M ef EFI (FAT-12/16/32)
> /dev/sdb3 3389440 7831551 4442112 2.1G 83 Linux
>
> (Oh, apparently it’s less than 4 GiB. Anyway.)
>
> So I did “sudo fdisk /dev/sdb” and added a partition, as usual.
>
>
> Karel Zak dixit:
>> Thomas Weißschuh dixit:
>>> In the message you may or may not have seen there is a reference to the
>>> `--wipe` option that describes the reasoning and possibilities.
>
> Oh, good point. I guess I’m surprised it does that by default.
>
>> There is also --protect-boot and --wipe-partitions, that may help in
>> some cases.
>
> Incidentally, I *did* know-ish about --wipe-partitions precisely
> because the default “auto” (according to the manpage…
>
>>> Reproduced here for your convenience:
>>> https://manpages.debian.org/bookworm/fdisk/fdisk.8.en.html
>
> … I’m on bullseye, so slightly older but still present) *does* ask
> for “auto” in interactive mode.
>
> But --wipe doesn’t‽
>
> -w, --wipe when
> […]
> given, the default is auto, in which case signatures are wiped
> only when in interactive mode. In all cases detected signatures
> […]
> -W, --wipe-partitions when
> […]
> tion is not given, the default is auto, in which case signatures
> are wiped only when in interactive mode and after confirmation
> by user. In all cases detected signatures are reported by warn‐
> […]
>
> So this inconsistency combined with auto being the default but
> auto not meaning the same thing tripped me up.
>
>>> As for why: "in order to avoid possible collisions".
>
> Huh. But there already was a partition table there, and all I did
> was to add another partition in free space at the end.
>
>>> For convenience it even may have shown a prominent warning in bright red
>>> letters with helpful pointers. Or maybe it didn't.
>
> Let’s see…
>
> tglase@x61w:~ $ sudo fdisk /dev/sdb
>
> Welcome to fdisk (util-linux 2.36.1).
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
>
> The device contains 'iso9660' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.
>
> Command (m for help):
>
> No line wrapping, but no bright red letters either ☻
>
> The terminal wrapped this between --wi and pe, so I guess
> this is the reason for me to oversee that. (And even then,
> the message does not indicate that I could also disable
> wiping there as the option is just named --wipe and not
> either paired with --no-wipe or named --wipe-mode which
> would have implied multiple possibilities. Here, a user
> could think “meh, I don’t want to wipe, so I don’t pass
> --wipe and then it won’t do that”.
>
>>>> So, how do I get fdisk to not corrupt the ISO 9660 part?
>>>
>>> Try `--wipe never` as explained above.
>
> OK, thanks, will try that next time. Or actually…
>
> tglase@x61w:~ $ sudo fdisk -w never /dev/sdb
>
> Welcome to fdisk (util-linux 2.36.1).
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
>
> The device contains 'iso9660' signature and it may remain on the device. It is recommended to wipe the device with wipefs(8) or fdisk --wipe, in order to avoid possible collisions.
>
> Command (m for help):
>
> … from the message this sounds like it’ll do the trick.
> (I still think that “possible collisions” could have been
> worded better as well, but I’m not English, so…)
>
> bye,
> //mirabilos
> --
> FWIW, I'm quite impressed with mksh interactively. I thought it was much
> *much* more bare bones. But it turns out it beats the living hell out of
> ksh93 in that respect. I'd even consider it for my daily use if I hadn't
> wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
>
>
^ permalink raw reply
* Re: fdisk corrupts data on USB stick
From: Thorsten Glaser @ 2024-01-29 21:29 UTC (permalink / raw)
To: util-linux
In-Reply-To: <20240129205623.sgvkhcyyepbsjzh3@ws.net.home>
Bill Unruh dixit:
> Perhaps if you told us what you really wanted to do, instead of asking
> why your first method did not work and how to fix it. Eg, you wnat to
> add another partition to the usb disk since the boot system only used
> 5GB of a 128GB usb, and you don't want to waste 123GB of space.
Something like that.
I have: an ISO 9660 filesystem that already contains a bootable MBR
with a partition table and even inlines an EFI thingy:
tglase@x61w:~ $ /sbin/fdisk -l /tmp/grml96-full_2022.11.iso
Disk /tmp/grml96-full_2022.11.iso: 1.62 GiB, 1734606848 bytes, 3387904 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2e49ce75
Device Boot Start End Sectors Size Id Type
/tmp/grml96-full_2022.11.iso1 * 0 3387903 3387904 1.6G 0 Empty
/tmp/grml96-full_2022.11.iso2 628 8819 8192 4M ef EFI (FAT-12/16/32)
I can dd(8) that to a USB stick and it’ll be bootable. My USB stick
measures 4 GiB however, so I wanted to add a third partition that
uses the remaining space to store extra data, which I can then use
in the live system, alongside on the stick:
tglase@x61w:~ $ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 3.73 GiB, 4009754624 bytes, 7831552 sectors
Disk model: Flash Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2e49ce75
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 3387903 3387904 1.6G 0 Empty
/dev/sdb2 628 8819 8192 4M ef EFI (FAT-12/16/32)
/dev/sdb3 3389440 7831551 4442112 2.1G 83 Linux
(Oh, apparently it’s less than 4 GiB. Anyway.)
So I did “sudo fdisk /dev/sdb” and added a partition, as usual.
Karel Zak dixit:
>Thomas Weißschuh dixit:
>>In the message you may or may not have seen there is a reference to the
>>`--wipe` option that describes the reasoning and possibilities.
Oh, good point. I guess I’m surprised it does that by default.
>There is also --protect-boot and --wipe-partitions, that may help in
>some cases.
Incidentally, I *did* know-ish about --wipe-partitions precisely
because the default “auto” (according to the manpage…
>>Reproduced here for your convenience:
>>https://manpages.debian.org/bookworm/fdisk/fdisk.8.en.html
… I’m on bullseye, so slightly older but still present) *does* ask
for “auto” in interactive mode.
But --wipe doesn’t‽
-w, --wipe when
[…]
given, the default is auto, in which case signatures are wiped
only when in interactive mode. In all cases detected signatures
[…]
-W, --wipe-partitions when
[…]
tion is not given, the default is auto, in which case signatures
are wiped only when in interactive mode and after confirmation
by user. In all cases detected signatures are reported by warn‐
[…]
So this inconsistency combined with auto being the default but
auto not meaning the same thing tripped me up.
>>As for why: "in order to avoid possible collisions".
Huh. But there already was a partition table there, and all I did
was to add another partition in free space at the end.
>>For convenience it even may have shown a prominent warning in bright red
>>letters with helpful pointers. Or maybe it didn't.
Let’s see…
tglase@x61w:~ $ sudo fdisk /dev/sdb
Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
The device contains 'iso9660' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.
Command (m for help):
No line wrapping, but no bright red letters either ☻
The terminal wrapped this between --wi and pe, so I guess
this is the reason for me to oversee that. (And even then,
the message does not indicate that I could also disable
wiping there as the option is just named --wipe and not
either paired with --no-wipe or named --wipe-mode which
would have implied multiple possibilities. Here, a user
could think “meh, I don’t want to wipe, so I don’t pass
--wipe and then it won’t do that”.
>>> So, how do I get fdisk to not corrupt the ISO 9660 part?
>>
>>Try `--wipe never` as explained above.
OK, thanks, will try that next time. Or actually…
tglase@x61w:~ $ sudo fdisk -w never /dev/sdb
Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
The device contains 'iso9660' signature and it may remain on the device. It is recommended to wipe the device with wipefs(8) or fdisk --wipe, in order to avoid possible collisions.
Command (m for help):
… from the message this sounds like it’ll do the trick.
(I still think that “possible collisions” could have been
worded better as well, but I’m not English, so…)
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
^ permalink raw reply
* Re: fdisk corrupts data on USB stick
From: Karel Zak @ 2024-01-29 20:56 UTC (permalink / raw)
To: Thomas Weißschuh; +Cc: Thorsten Glaser, util-linux
In-Reply-To: <5b8f9459-cc95-4c08-b68c-39abb2ff9f68@t-8ch.de>
On Mon, Jan 29, 2024 at 09:44:21PM +0100, Thomas Weißschuh wrote:
> On 2024-01-29 20:27:13+0000, Thorsten Glaser wrote:
> > Thomas Weißschuh dixit:
> >
> > > The device contains 'iso9660' signature and it will be removed by a
> > > write command. See fdisk(8) man page and --wipe option for more
> > > details.
> >
> > >I guess your version does the same, but maybe is not printing the
> > >warning.
> >
> > Hm, maybe it does, maybe it doesn’t, but even so, why should it?
>
> In the message you may or may not have seen there is a reference to the
> `--wipe` option that describes the reasoning and possibilities.
There is also --protect-boot and --wipe-partitions, that may help in
some cases.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: fdisk corrupts data on USB stick
From: Bill Unruh @ 2024-01-29 20:44 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: Thomas Weißschuh, util-linux
In-Reply-To: <Pine.BSM.4.64L.2401292023270.19873@herc.mirbsd.org>
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]
Perhaps if you told us what you really wanted to do, instead of asking why
your first method did not work and how to fix it. Eg, you wnat to add another
partition to the usb disk since the boot system only used 5GB of a 128GB usb,
and you don't want to waste 123GB of space. Or some other problem you want to
solve. That way you might get ways of solving your real problem you never
thought of.
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ theory.physics.ubc.ca/
On Mon, 29 Jan 2024, Thorsten Glaser wrote:
> [CAUTION: Non-UBC Email]
>
> Thomas Weißschuh dixit:
>
>> The device contains 'iso9660' signature and it will be removed by a
>> write command. See fdisk(8) man page and --wipe option for more
>> details.
>
>> I guess your version does the same, but maybe is not printing the
>> warning.
>
> Hm, maybe it does, maybe it doesn’t, but even so, why should it?
>
>> So the disk gets converted to a normal MBR layout and the ISO signature
>> get wiped. Which makes sense as the ISO image would need to be
>> remastered.
>
> Totally not! First of, the ISO already contained an MBR with a
> partition table in the first sector, which I extended, and second,
> it’s fdisk’s task to precisely edit the MBR partition table (and,
> if the 55h AAh magic is missing, create it), nothing else (okay,
> extended partitions if someone uses them, but nothing else).
>
>>> Is there a way we can make it not corrupt such media?
>>
>> Did you look into grml2usb?
>
> I know that, but I wanted to keep the original ISO 9660 filesystem
> so things don’t accidentally get changed on it. (And the original
> EFI thingy, in case it’s needed.)
>
> So, how do I get fdisk to not corrupt the ISO 9660 part?
> MirBSD fdisk doesn’t do that, it sticks to the MBR.
>
> Thanks,
> //mirabilos
> --
> „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
> mksh auf jedem System zu installieren.“
> -- XTaran auf der OpenRheinRuhr, ganz begeistert
> (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox