Screen of gparted refuse to reduce https://doc.ubuntu-
fr.org/_media/captures/gparted/gpartedtreduce.png
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1857914
Title:
resize2fs destroy the content of
Hello
I discovered that if I gradually decrease the partition size by 250 MiB
at a time (not tested with 500 MiB), I can shrink the file system to the
minimum value indicated without it being broken.
But the end result is very surprising: The partition cannot be reduced.
There is a message that a
maybe a link with this option that i never used
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.autosuspend=-1"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1857914
Title:
resize2fs destroy the co
Something strange in journalctl
janv. 24 09:02:03 a sudo[2658]: root : TTY=pts/0 ; PWD=/root ; USER=root ;
COMMAND=/usr/sbin/e2fsck -f -y -v /dev/sdb4
janv. 24 09:02:04 a sudo[2667]: root : TTY=pts/0 ; PWD=/root ; USER=root ;
COMMAND=/usr/sbin/resize2fs -P /dev/sdb4
janv. 24 09:02:04 a su
** Attachment added: "commands executed"
https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914/+attachment/5322582/+files/BUGUSB-d.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1857914
Hello
I progressed in the reproduction of the incident which I know how to do
systematically.
It seems to me that resize2fs is part of the incident by forgetting to control
something.
I can raise with a debugging option.
Which advise me you?
In attachment you will find the script of the four co
Hello.
The problem is more complicated or simpler than I thought.
I tried again.
A) With version 18.04.3
Formatting SDB1, SDB2 and SDB3
Creation of the P1, P2, P3 and P4 directories in the 3 partitions.
B) Reboot with version 19.10.
Deletion of the P1 directories in the three partitions.
Shrink
** Attachment added: "result of some commands executed in version 19.10"
https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914/+attachment/5318232/+files/Resize2.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bu
Hello
It took me a little while to reproduce the incident.
I only wanted to put what seemed to me the minimum necessary.
But I couldn't reproduce the incident.
So I replayed the initial scenario. I also couldn't rebuild.
So I destroyed the inaccessible partition to make a new one now called SDB1
Y
** Attachment added: "result of some commands executed in version 19.10 to
repair the partition."
https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914/+attachment/5318233/+files/Resize3.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscr
** Attachment added: "list of all orders"
https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914/+attachment/5318229/+files/BUG5.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1857914
Tit
** Attachment added: "details of actions performed with gparted in version
19.10"
https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914/+attachment/5318231/+files/gparted_1.htm
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu
** Attachment added: "result of some commands executed in version 18.04.3"
https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914/+attachment/5318230/+files/Resize.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://b
Can you provide an exact set of commands to create the file system,
populate the file system, that *anyone* (but especially, the developers
that you are asking to looking at the bug) to replicate this failure?
In particular, how is the file system is created (the exact mke2fs
command) and the set o
Hello
You suggested that I use a file to simulate a partition. I could not highlight
the incident.
However, the commands you offer can also be used with a partition. So I no
longer need to use gparted.
This highlights that it is the resize command that destroys the partition. Here
is the trace
So if the same procedure (with exactly the same files) reproduces
reliably when using a partition and gpart --- and it does not reproduce
at all, even with multiple attmepts, without gpart, then it is clearly a
gpart bug.
** Package changed: e2fsprogs (Ubuntu) => gpart (Ubuntu)
--
You received
Hello
I cannot reproduce the incident with this method
export LC_ALL=POSIX
sudo mke2fs -t ext4 /USB1910bis/fs.img 30G
mke2fs 1.45.3 (14-Jul-2019)
Creating regular file /mnt/USB1910bis/fs.img
Creating filesystem with 7864320 4k blocks and 1966080 inodes
Filesystem UUID: 2cf9eafb-628c-45d3-b452-6bd
Oh, also please send me the dumpe2fs -h of the partition before you try
to resize it, and please send the output of your reproduction with the
locale set to POSIX, so I can read the output of e2fsprogs in English,
please?
--
You received this bug notification because you are a member of Ubuntu
Bu
Can you provide a detailed reproduction instructions --- preferably one
that I can run myself, so I can see exactly is going on?
One thing that would be helpful is whether this can me reproduced
without gpart being part of the mix. That is, can you do something like
this:
mke2fs -t ext4 /path/to
19 matches
Mail list logo
