[Touch-packages] [Bug 1883441] Re: Fatal interaction between sfdisk and lsblk
No worries! Thanks for getting back to this bug report. Marking it as Invalid. ** Changed in: util-linux (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1883441 Title: Fatal interaction between sfdisk and lsblk Status in util-linux package in Ubuntu: Invalid Bug description: I'm posting this against util-linux because it's lsblk calls that fail, but the failure depends on a prior call to sfdisk which is part of the fdisk package. Remove the sfdisk call, and the failure does not happen, at least in my test setup. A call to sfdisk in a script causes a failure of a later series of calls to lsblk, in which lsblk fails to return information. I know sfdisk is designed for humans, but I'm wanting to automate the operation of its --backup option, and don't know of another way. In any event, this failure shoudl be addressed. I'm attaching a script with illustrates both the problem and a workaround. The workaround is to introduce a "sleep 1" call in between the calls to lsblk. I can't even imagine why this works, but it does in my configuration. I call the script with the name of a device which contains two ntfs partitions, and the name of a directory where results are to be stored. The directory must contain a "clone.log" file (it can be empty; it's just to make sure I'm naming the correct directory). If I call it so it fails: bash b5.sh sda /tmp because the final lsblk call does not return any information However, if I call is to, it succeeds: bash -s b5.sh sda /tmp because the "-s" switch introduces a "sleep 1" call between lsblk calls. This makes no sense, which is why I consider it a bug. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: util-linux 2.31.1-0.4ubuntu3.6 ProcVersionSignature: Ubuntu 4.15.0-101.102-generic 4.15.18 Uname: Linux 4.15.0-101-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu7.15 Architecture: amd64 Date: Sun Jun 14 09:36:17 2020 SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1883441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1883441] Re: Fatal interaction between sfdisk and lsblk
I tried, but when I went back to the same system, with the same drives, and tried again -- you guessed it, it did not fail. I really hate intermittent errors. You may as well mark this one "works for me". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1883441 Title: Fatal interaction between sfdisk and lsblk Status in util-linux package in Ubuntu: Incomplete Bug description: I'm posting this against util-linux because it's lsblk calls that fail, but the failure depends on a prior call to sfdisk which is part of the fdisk package. Remove the sfdisk call, and the failure does not happen, at least in my test setup. A call to sfdisk in a script causes a failure of a later series of calls to lsblk, in which lsblk fails to return information. I know sfdisk is designed for humans, but I'm wanting to automate the operation of its --backup option, and don't know of another way. In any event, this failure shoudl be addressed. I'm attaching a script with illustrates both the problem and a workaround. The workaround is to introduce a "sleep 1" call in between the calls to lsblk. I can't even imagine why this works, but it does in my configuration. I call the script with the name of a device which contains two ntfs partitions, and the name of a directory where results are to be stored. The directory must contain a "clone.log" file (it can be empty; it's just to make sure I'm naming the correct directory). If I call it so it fails: bash b5.sh sda /tmp because the final lsblk call does not return any information However, if I call is to, it succeeds: bash -s b5.sh sda /tmp because the "-s" switch introduces a "sleep 1" call between lsblk calls. This makes no sense, which is why I consider it a bug. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: util-linux 2.31.1-0.4ubuntu3.6 ProcVersionSignature: Ubuntu 4.15.0-101.102-generic 4.15.18 Uname: Linux 4.15.0-101-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu7.15 Architecture: amd64 Date: Sun Jun 14 09:36:17 2020 SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1883441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1883441] Re: Fatal interaction between sfdisk and lsblk
Hi Kevin, I could not reproduce this on a Bionic VM with a loop device w/ two NTFS partitions (type + filesystem). Could you please provide a strace log of both default/-s cases from your environment? # strace -ffttTy -o strace.log b5.sh # tar cvf lp1883441-strace.tar strace.log.* ** Changed in: util-linux (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1883441 Title: Fatal interaction between sfdisk and lsblk Status in util-linux package in Ubuntu: Incomplete Bug description: I'm posting this against util-linux because it's lsblk calls that fail, but the failure depends on a prior call to sfdisk which is part of the fdisk package. Remove the sfdisk call, and the failure does not happen, at least in my test setup. A call to sfdisk in a script causes a failure of a later series of calls to lsblk, in which lsblk fails to return information. I know sfdisk is designed for humans, but I'm wanting to automate the operation of its --backup option, and don't know of another way. In any event, this failure shoudl be addressed. I'm attaching a script with illustrates both the problem and a workaround. The workaround is to introduce a "sleep 1" call in between the calls to lsblk. I can't even imagine why this works, but it does in my configuration. I call the script with the name of a device which contains two ntfs partitions, and the name of a directory where results are to be stored. The directory must contain a "clone.log" file (it can be empty; it's just to make sure I'm naming the correct directory). If I call it so it fails: bash b5.sh sda /tmp because the final lsblk call does not return any information However, if I call is to, it succeeds: bash -s b5.sh sda /tmp because the "-s" switch introduces a "sleep 1" call between lsblk calls. This makes no sense, which is why I consider it a bug. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: util-linux 2.31.1-0.4ubuntu3.6 ProcVersionSignature: Ubuntu 4.15.0-101.102-generic 4.15.18 Uname: Linux 4.15.0-101-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu7.15 Architecture: amd64 Date: Sun Jun 14 09:36:17 2020 SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1883441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
