util-linux

[musca]

Hi terroreek,

no worries, your input is appreciated by us, your contribution of ideas and information is always valueable. Early warnings are okay, and sometimes the case isn't as critical as it appeared at first. Even better then!

I didn't see problems with util-linux, but i observed remarkably slow processing with dpkg 1.17.19. But this should be solved with dpkg 1.17.20.

greetings
musca

PS.  I hope our bad attitude detector continues pointing to LOW.

[piper]

terroeek,

Were you inside a kde  (or other de)  environment when doing this upgrade  ?

[terroreek]

terroeek,
Were you inside a kde  (or other de)  environment when doing this upgrade  ?

Nope, I "systemctl isolate mutl-user.target" prior to every upgrade, as per my understanding of being the equivalent of init runlevel 3 and yourselves and the other devs reccomendation.  I also run a script that prior to doing a dist-upgrade it verifies, that the graphical.target is inactive and takes a snapshot of my btrfs_subvolumes, that way I can 'undo' if the dist-upgrade borks something.

Hi terroreek,

no worries, your input is appreciated by us, your contribution of ideas and information is always valueable. Early warnings are okay, and sometimes the case isn't as critical as it appeared at first. Even better then!

I didn't see problems with util-linux, but i observed remarkably slow processing with dpkg 1.17.19. But this should be solved with dpkg 1.17.20.

greetings
musca

PS.  I hope our bad attitude detector continues pointing to LOW.

@musca, no worries, now before posting I did attempt the upgrade three times and all three times I found that util-linux install was really slow on my main siduction box, where everything normally flys.  I waited over 30 mins one time.  However on my work laptop I flew right through the upgrade, after I found it was just slow.  I am not sure why.  I was actually on dpkg 1.17.18, I have been bogged down with work and hadn't performed the daily updates that I should be.

I love the attitude and friendliness the siduction community has to offer.  -edit- By far the best community I have been in, there are others that are just awful.     

[reinob]

.. and takes a snapshot of my btrfs_subvolumes, that way I can 'undo' if the dist-upgrade borks something.

@musca, no worries, now before posting I did attempt the upgrade three times and all three times I found that util-linux install was really slow on my main siduction box, where everything normally flys.  I waited over 30 mins one time.

However on my work laptop I flew right through the upgrade, after I found it was just slow.  I am not sure why. 

Wild guess: do you use btrfs on your work laptop?

[grandie]

Please try to be cool, we lower class-men "beginners"  enjoy the play on attitudes as much as you upper class-men in reading between the lines from others.  I appreciate the opportunity of having the members of this forum taking their time to warn me and others about problems in keeping our siduction systems up and running, as we can't do it without you. THANK-YOU!


Grandie     

[terroreek]

.. and takes a snapshot of my btrfs_subvolumes, that way I can 'undo' if the dist-upgrade borks something.

@musca, no worries, now before posting I did attempt the upgrade three times and all three times I found that util-linux install was really slow on my main siduction box, where everything normally flys.  I waited over 30 mins one time.

However on my work laptop I flew right through the upgrade, after I found it was just slow.  I am not sure why. 

Wild guess: do you use btrfs on your work laptop?

Yep, I use btrfs on both.  I know btrfs has IO issues for large files that are constantly changing, like journald logs, mysql db's, and VMs.  On those files, I disable COW, but going through the list of files, I am not sure what would cause the IO to bottom out.  The only thing I can think of is the previous weekend I rebalanced the btrfs volume that contained my root subvolume.  The other thing is my desktop has an SSD, and the laptop is running a conventional laptop hard drive.  Like wise, the other 300-400 updates that needed to be updated finished in ~5mins, it was just this one specific package that crawled.