Hi! On Mon, 2016-09-26 at 16:58:55 -0700, Elliott Mitchell wrote: > On Mon, Sep 26, 2016 at 11:23:56PM +0200, Guillem Jover wrote: > > On Sun, 2016-09-25 at 16:46:56 -0700, Elliott Mitchell wrote: > > > When installing packages which *only* have files in /usr, I generally > > > try to leave / read-only. With the recent release of `dpkg` though this > > > has become problematic. > > > > Do you mean that it used to work, and it does not anymore. In which > > case, what versions? > > Anything 1.16.18 (oldstable) or earlier didn't exhibit this behavior.
That's still surprising. :) > > > >From the error message, during unpacking `dpkg` is trying to create a > > > file/directory as /usr.dpkg-tmp, which fails if / is read-only. This > > > could actually cause some problems. Notably if `dpkg` is doing this to > > > check whether the filesystem has sufficient free space, this check *WILL* > > > fail since / and /usr could well be different filesystems. This could > > > also cause trouble if /usr.dpkg-tmp is large and / has limited free > > > space. > > > > This should not happen for pre-existing directories, and dpkg should > > skip those. The actual error message would be helpful here. Also the > > debug output from using -D113 would also be helpful. > > Sigh, really should have grabbed the full error. Mentioned a failure > trying to do some operation on /usr.<something> and "read-only > filesystem" (/usr was read-write, / was read-only). Remounting / > read-write gets past the error, but I dislike that. Since the package > had no files outside of /usr, this really shouldn't occur. I'd appreciate if you could try to reproduce this, otherwise I don't think I'll find the time to setup a system with that layout. Which means this bug becomes pretty much unactionable. :/ > > > I'm unsure how to rate the severity of this issue. This is distinctly > > > annoying and can trigger warning flags, but I suppose in many cases it > > > won't cause problems for people. Folks who always remount / read-write > > > when upgrading packages may well not notice, but those of use who pay a > > > bit more attention do notice. > > > > I'm actually very surprised by this bug report, because something > > related was fixed in dpkg 1.17.14, so the version you are reporting > > against should actually behave better for your use case: > > > > * Never try to remove the root directory or its backups. There's no point > > in > > it, and makes life more difficult for a read-only root with a read-write > > overlay or a symlink farm. Requested by [email protected]. > > This isn't about the removal of something, this is about creating an > unneeded extra file/directory outside of where any files should be > being created. This file/directory is removed afterwords, but writing > outside bothers me. Sure, my point is that there's other people doing similar stuff and they have not complained since, and this is not the expected behavior in dpkg, which I can prove when installing a simple package, so I'm still very skeptical this is some problem in dpkg itself. These are the relevant parts of the debug output when reinstalling a package: ,--- … D000010: tarobject ti->name='./bin/con2fbmap' mode=100755 owner=0:0 type=48(-) ti->linkname='' namenode='/bin/con2fbmap' flags=2 instead='<none>' D000100: setupvnamevbs main='/bin/con2fbmap' tmp='/bin/con2fbmap.dpkg-tmp' new='/bin/con2fbmap.dpkg-new' D000100: tarobject already exists D000010: path_remove_tree '/bin/con2fbmap.dpkg-new' D000010: path_remove_tree '/bin/con2fbmap.dpkg-tmp' D000100: tarobject file open size=6200 D000100: tarobject file hash=c2c72b6dbce87a928cb53354feba50be D000100: tarobject nondirectory, 'link' backup D000100: tarobject done and installation deferred D000010: tarobject ti->name='./usr' mode=40755 owner=0:0 type=53(d) ti->linkname='' namenode='/usr' flags=2 instead='<none>' D000100: setupvnamevbs main='/usr' tmp='/usr.dpkg-tmp' new='/usr.dpkg-new' D000100: tarobject already exists D000100: tarobject directory exists … `--- As you see here, no backup is created for /usr, because it's a pre-existing directory. And then there's a subsequent remove trial: ,--- D000010: path_remove_tree '/usr.dpkg-tmp' `--- which does not give any error, because the backup directory does not exist. Thanks, Guillem
