Why are all snaps being mounted and listed as block devices or partitions for Ubuntu 18.04?
As of Ubuntu 18.04 running lsblk shows 16 snap loops (2-3 times for each snap). The question is, why are they being listed as results for lsblk, fdisf-l, and blkid?
It creates a lot of clutter from the actual disks drive partitions I need to see, namely /dev/ partitions. I know a purported duplicate of this question exists, but it only asks why three loops are being listed per snap. I want to know why these snaps are being listed in the first place, and the purported duplicate does not answer this (perhaps those marking this as duplicate could help me by explaining why it is a duplicate). Technically, they qualify as file systems (which I neither created nor asked for), but they are getting in the way of the information output for the /dev/ partitions I am interested in. This becomes a problem when fdisk -l outputs a three page+ list filled mainly with snaps.
The output of a recent (1 week old) Ubuntu install and I have not installed any snaps:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 14.5M 1 loop /snap/gnome-logs/37
loop1 7:1 0 2.3M 1 loop /snap/gnome-calculator/170
loop2 7:2 0 86.6M 1 loop /snap/core/4486
loop3 7:3 0 86.6M 1 loop /snap/core/4650
loop4 7:4 0 1.6M 1 loop /snap/gnome-calculator/154
loop5 7:5 0 14.5M 1 loop /snap/gnome-logs/34
loop6 7:6 0 3.3M 1 loop /snap/gnome-system-monitor/36
loop7 7:7 0 2.3M 1 loop /snap/gnome-calculator/178
loop8 7:8 0 13M 1 loop /snap/gnome-characters/101
loop9 7:9 0 3.7M 1 loop /snap/gnome-system-monitor/45
loop10 7:10 0 139.5M 1 loop /snap/gnome-3-26-1604/64
loop11 7:11 0 140M 1 loop /snap/gnome-3-26-1604/59
loop12 7:12 0 3.7M 1 loop /snap/gnome-system-monitor/41
loop13 7:13 0 21M 1 loop /snap/gnome-logs/25
loop14 7:14 0 12.2M 1 loop /snap/gnome-characters/69
loop15 7:15 0 13M 1 loop /snap/gnome-characters/96
sda 8:0 0 298.1G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 297.6G 0 part /
sr0 11:0 1 1024M 0 rom
(supplemental screen capture of above text):
screenshot.jpg
My snap list shows 6 results:
core
gnome-3-26-1604
gnome-calculator
gnome-characters
gnome-logs
gnome-system-monitor
Meanwhile, gnome-disk-utility shows nothing at all for snaps, only showing my HDD and optical drive.
It won't be very efficient if every installed snap gets listed as a block device (2-3 times each to add). Should I expect future updates to deal with this?
Edit:fdisk-l also dumps out a very long list with 16 instances of these "disk loops" (Disk /dev/loop0, Disk /dev/loop1, etc., each with details which I won't show here because it's too long). This can't be intended behaviour, can it?blkid also lists 16 loops, as TYPE="squashfs". At least parted -l works as expected, only outing my actual disk partitions.
I just tested this, and installing more snaps does add more to the lsblk output. Therefore, fdisk, lsblk, blkid could have potentially huge output lists, according to the number of snaps available, and installed.
gnome 18.04 snap
add a comment |
As of Ubuntu 18.04 running lsblk shows 16 snap loops (2-3 times for each snap). The question is, why are they being listed as results for lsblk, fdisf-l, and blkid?
It creates a lot of clutter from the actual disks drive partitions I need to see, namely /dev/ partitions. I know a purported duplicate of this question exists, but it only asks why three loops are being listed per snap. I want to know why these snaps are being listed in the first place, and the purported duplicate does not answer this (perhaps those marking this as duplicate could help me by explaining why it is a duplicate). Technically, they qualify as file systems (which I neither created nor asked for), but they are getting in the way of the information output for the /dev/ partitions I am interested in. This becomes a problem when fdisk -l outputs a three page+ list filled mainly with snaps.
The output of a recent (1 week old) Ubuntu install and I have not installed any snaps:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 14.5M 1 loop /snap/gnome-logs/37
loop1 7:1 0 2.3M 1 loop /snap/gnome-calculator/170
loop2 7:2 0 86.6M 1 loop /snap/core/4486
loop3 7:3 0 86.6M 1 loop /snap/core/4650
loop4 7:4 0 1.6M 1 loop /snap/gnome-calculator/154
loop5 7:5 0 14.5M 1 loop /snap/gnome-logs/34
loop6 7:6 0 3.3M 1 loop /snap/gnome-system-monitor/36
loop7 7:7 0 2.3M 1 loop /snap/gnome-calculator/178
loop8 7:8 0 13M 1 loop /snap/gnome-characters/101
loop9 7:9 0 3.7M 1 loop /snap/gnome-system-monitor/45
loop10 7:10 0 139.5M 1 loop /snap/gnome-3-26-1604/64
loop11 7:11 0 140M 1 loop /snap/gnome-3-26-1604/59
loop12 7:12 0 3.7M 1 loop /snap/gnome-system-monitor/41
loop13 7:13 0 21M 1 loop /snap/gnome-logs/25
loop14 7:14 0 12.2M 1 loop /snap/gnome-characters/69
loop15 7:15 0 13M 1 loop /snap/gnome-characters/96
sda 8:0 0 298.1G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 297.6G 0 part /
sr0 11:0 1 1024M 0 rom
(supplemental screen capture of above text):
screenshot.jpg
My snap list shows 6 results:
core
gnome-3-26-1604
gnome-calculator
gnome-characters
gnome-logs
gnome-system-monitor
Meanwhile, gnome-disk-utility shows nothing at all for snaps, only showing my HDD and optical drive.
It won't be very efficient if every installed snap gets listed as a block device (2-3 times each to add). Should I expect future updates to deal with this?
Edit:fdisk-l also dumps out a very long list with 16 instances of these "disk loops" (Disk /dev/loop0, Disk /dev/loop1, etc., each with details which I won't show here because it's too long). This can't be intended behaviour, can it?blkid also lists 16 loops, as TYPE="squashfs". At least parted -l works as expected, only outing my actual disk partitions.
I just tested this, and installing more snaps does add more to the lsblk output. Therefore, fdisk, lsblk, blkid could have potentially huge output lists, according to the number of snaps available, and installed.
gnome 18.04 snap
I think the actual answer to your question is at this related question: "Snap packages are squashfs file systems. The only way to access snaps is to mount them. So yes, they will always be mounted." askubuntu.com/questions/842093/… God I wish they didn't have to be mounted!
– craq
Jan 26 at 5:55
add a comment |
As of Ubuntu 18.04 running lsblk shows 16 snap loops (2-3 times for each snap). The question is, why are they being listed as results for lsblk, fdisf-l, and blkid?
It creates a lot of clutter from the actual disks drive partitions I need to see, namely /dev/ partitions. I know a purported duplicate of this question exists, but it only asks why three loops are being listed per snap. I want to know why these snaps are being listed in the first place, and the purported duplicate does not answer this (perhaps those marking this as duplicate could help me by explaining why it is a duplicate). Technically, they qualify as file systems (which I neither created nor asked for), but they are getting in the way of the information output for the /dev/ partitions I am interested in. This becomes a problem when fdisk -l outputs a three page+ list filled mainly with snaps.
The output of a recent (1 week old) Ubuntu install and I have not installed any snaps:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 14.5M 1 loop /snap/gnome-logs/37
loop1 7:1 0 2.3M 1 loop /snap/gnome-calculator/170
loop2 7:2 0 86.6M 1 loop /snap/core/4486
loop3 7:3 0 86.6M 1 loop /snap/core/4650
loop4 7:4 0 1.6M 1 loop /snap/gnome-calculator/154
loop5 7:5 0 14.5M 1 loop /snap/gnome-logs/34
loop6 7:6 0 3.3M 1 loop /snap/gnome-system-monitor/36
loop7 7:7 0 2.3M 1 loop /snap/gnome-calculator/178
loop8 7:8 0 13M 1 loop /snap/gnome-characters/101
loop9 7:9 0 3.7M 1 loop /snap/gnome-system-monitor/45
loop10 7:10 0 139.5M 1 loop /snap/gnome-3-26-1604/64
loop11 7:11 0 140M 1 loop /snap/gnome-3-26-1604/59
loop12 7:12 0 3.7M 1 loop /snap/gnome-system-monitor/41
loop13 7:13 0 21M 1 loop /snap/gnome-logs/25
loop14 7:14 0 12.2M 1 loop /snap/gnome-characters/69
loop15 7:15 0 13M 1 loop /snap/gnome-characters/96
sda 8:0 0 298.1G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 297.6G 0 part /
sr0 11:0 1 1024M 0 rom
(supplemental screen capture of above text):
screenshot.jpg
My snap list shows 6 results:
core
gnome-3-26-1604
gnome-calculator
gnome-characters
gnome-logs
gnome-system-monitor
Meanwhile, gnome-disk-utility shows nothing at all for snaps, only showing my HDD and optical drive.
It won't be very efficient if every installed snap gets listed as a block device (2-3 times each to add). Should I expect future updates to deal with this?
Edit:fdisk-l also dumps out a very long list with 16 instances of these "disk loops" (Disk /dev/loop0, Disk /dev/loop1, etc., each with details which I won't show here because it's too long). This can't be intended behaviour, can it?blkid also lists 16 loops, as TYPE="squashfs". At least parted -l works as expected, only outing my actual disk partitions.
I just tested this, and installing more snaps does add more to the lsblk output. Therefore, fdisk, lsblk, blkid could have potentially huge output lists, according to the number of snaps available, and installed.
gnome 18.04 snap
As of Ubuntu 18.04 running lsblk shows 16 snap loops (2-3 times for each snap). The question is, why are they being listed as results for lsblk, fdisf-l, and blkid?
It creates a lot of clutter from the actual disks drive partitions I need to see, namely /dev/ partitions. I know a purported duplicate of this question exists, but it only asks why three loops are being listed per snap. I want to know why these snaps are being listed in the first place, and the purported duplicate does not answer this (perhaps those marking this as duplicate could help me by explaining why it is a duplicate). Technically, they qualify as file systems (which I neither created nor asked for), but they are getting in the way of the information output for the /dev/ partitions I am interested in. This becomes a problem when fdisk -l outputs a three page+ list filled mainly with snaps.
The output of a recent (1 week old) Ubuntu install and I have not installed any snaps:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 14.5M 1 loop /snap/gnome-logs/37
loop1 7:1 0 2.3M 1 loop /snap/gnome-calculator/170
loop2 7:2 0 86.6M 1 loop /snap/core/4486
loop3 7:3 0 86.6M 1 loop /snap/core/4650
loop4 7:4 0 1.6M 1 loop /snap/gnome-calculator/154
loop5 7:5 0 14.5M 1 loop /snap/gnome-logs/34
loop6 7:6 0 3.3M 1 loop /snap/gnome-system-monitor/36
loop7 7:7 0 2.3M 1 loop /snap/gnome-calculator/178
loop8 7:8 0 13M 1 loop /snap/gnome-characters/101
loop9 7:9 0 3.7M 1 loop /snap/gnome-system-monitor/45
loop10 7:10 0 139.5M 1 loop /snap/gnome-3-26-1604/64
loop11 7:11 0 140M 1 loop /snap/gnome-3-26-1604/59
loop12 7:12 0 3.7M 1 loop /snap/gnome-system-monitor/41
loop13 7:13 0 21M 1 loop /snap/gnome-logs/25
loop14 7:14 0 12.2M 1 loop /snap/gnome-characters/69
loop15 7:15 0 13M 1 loop /snap/gnome-characters/96
sda 8:0 0 298.1G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 297.6G 0 part /
sr0 11:0 1 1024M 0 rom
(supplemental screen capture of above text):
screenshot.jpg
My snap list shows 6 results:
core
gnome-3-26-1604
gnome-calculator
gnome-characters
gnome-logs
gnome-system-monitor
Meanwhile, gnome-disk-utility shows nothing at all for snaps, only showing my HDD and optical drive.
It won't be very efficient if every installed snap gets listed as a block device (2-3 times each to add). Should I expect future updates to deal with this?
Edit:fdisk-l also dumps out a very long list with 16 instances of these "disk loops" (Disk /dev/loop0, Disk /dev/loop1, etc., each with details which I won't show here because it's too long). This can't be intended behaviour, can it?blkid also lists 16 loops, as TYPE="squashfs". At least parted -l works as expected, only outing my actual disk partitions.
I just tested this, and installing more snaps does add more to the lsblk output. Therefore, fdisk, lsblk, blkid could have potentially huge output lists, according to the number of snaps available, and installed.
gnome 18.04 snap
gnome 18.04 snap
edited Jan 15 at 11:05
DK Bose
13.8k124184
13.8k124184
asked Jun 17 '18 at 21:48
jordyjordy
715315
715315
I think the actual answer to your question is at this related question: "Snap packages are squashfs file systems. The only way to access snaps is to mount them. So yes, they will always be mounted." askubuntu.com/questions/842093/… God I wish they didn't have to be mounted!
– craq
Jan 26 at 5:55
add a comment |
I think the actual answer to your question is at this related question: "Snap packages are squashfs file systems. The only way to access snaps is to mount them. So yes, they will always be mounted." askubuntu.com/questions/842093/… God I wish they didn't have to be mounted!
– craq
Jan 26 at 5:55
I think the actual answer to your question is at this related question: "Snap packages are squashfs file systems. The only way to access snaps is to mount them. So yes, they will always be mounted." askubuntu.com/questions/842093/… God I wish they didn't have to be mounted!
– craq
Jan 26 at 5:55
I think the actual answer to your question is at this related question: "Snap packages are squashfs file systems. The only way to access snaps is to mount them. So yes, they will always be mounted." askubuntu.com/questions/842093/… God I wish they didn't have to be mounted!
– craq
Jan 26 at 5:55
add a comment |
5 Answers
5
active
oldest
votes
When you type the command
snap list
you will get the output of actual installed snap packages. The reason is when a snap package is updated, the old version is kept (see snapcraft docu).
Citate from snapcraft docu
Garbage collection then removes and purges any snap files, and their writable areas, for snap versions prior to the one that has just been updated — meaning that, at most, two versions of a snap will be present on the system. This saves disk space without compromising the ability to revert the snap to a previous known-good state.
Explicitly removing a snap from your system will also remove the code and purge the data for all prior versions.
For instance you have got installed more than one versions of gnome-calculator.
In case you only need the newest version, you can use
sudo snap remove gnome-calculator --revision <verison to be placed>
Using the command
losetup -a
shows you the mounted snaps (loop devices)
If you want to delete the double ones, type
sudo losetup -d /dev/loop<loopnumber>
It seems to be an error of the snap code, since all older been kept in the /var/lib/snapd/snaps file.
1
sudo: remove: command not foundandlosetup -dchanges nothing.
– jordy
Jun 27 '18 at 12:45
3
The correct code issudo snap removenotsudo remove. Please revise your answer.
– jordy
Jun 27 '18 at 13:10
add a comment |
From the content in your question, your problem is about searching for a way to have control over what you're seeing when you try to view your block devices than how snap uses block devices for its operation.
I agree with your referenced distinction between fdisk -l and parted -l. While fdisk shows a very good detailed output of block devices, it shows too many other things that distract from what you're trying to see.
Resolution
You can use filter the lsblk formatted output. This works well to give a clean output like what you get with gnome-disk-utility.
$ lsblk -o name,mountpoint,label,size,fstype,uuid | egrep -v "^loop"
Or as you indicated in your question:
$ sudo parted -l
For the df command in your question, use:
$ df | egrep -v /dev/loop
3
I was waiting a long time for someone to suggest exactly this, a filtered output for lsblk (rather than all those comments defending the excessive output as normal and good). I would like to avoid having to do this, however, just because plain and straightlsblkwas quick, easy to remember, and it worked beautifully, before snap interfered with it. I want it back as it was. Hopefully, the excessive output is just a bug that will get fixed.
– jordy
Jun 22 '18 at 9:36
4
@danthonyd Thanks for the acknowledgment. I was sure I understood the question and felt certain it deserved a spot in the AU database of information for consideration and answering. This is something I've been concerned about for a long time. However, the problem isn't Snap. The problem is with thefdiskdevelopers. They should add a method to filter out real devices over the pseudo devices to remove the excessive output and make their application more manageable, like the Gnome-disk-utility. No one would be usingfdiskto manage their loop devices. (continued)...
– L. D. James
Jun 22 '18 at 10:31
4
... (continued) They don't even need to see it in the the fdisk output. That is what losetup and other pseudo application commands are for. So why bother showing it, if you can't manage it with the tool. This flaw in the fdisk design is making apps like parted and lsblk more popular and user friendly.
– L. D. James
Jun 22 '18 at 10:34
Thank you. I'm adding| egrep -v "^loop"to all my 16.04lsblkscripts today to reduce maintenance on the day I convert to 18.04. (FYI I had already up-voted your answer before today)
– WinEunuuchs2Unix
Oct 21 '18 at 15:32
add a comment |
If you use the snap version of the system monitor, then you will see all file systems used by snap as well as the ones you use.
An easy "fix" is to uninstall Gnome System Monitor from the app store. It is the snap-version.
Then install Gnome System Monitor from the normal repositories using Synaptic package manager. It is the normal version that installs a bunch of files all over you root partition. Nice!
And you will see just what you expect to see when you launch Gnome System Monitor...
Great! This is what I was looking for. The commands aresnap remove gnome-system-monitor(no sudo required), followed bysudo apt install gnome-system-monitor(this time with sudo).
– PerlDuck
Nov 17 '18 at 19:06
add a comment |
I find this annoying too. It seems if they are not running they should not be mounted or listed.
You can run this command to exclude all the loop devices.
$ lsblk -e 7
add a comment |
To only show mounts excluding loopback you could also simply:
lsblk -af |grep -sv loop
;)
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1047456%2fwhy-are-all-snaps-being-mounted-and-listed-as-block-devices-or-partitions-for-ub%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
When you type the command
snap list
you will get the output of actual installed snap packages. The reason is when a snap package is updated, the old version is kept (see snapcraft docu).
Citate from snapcraft docu
Garbage collection then removes and purges any snap files, and their writable areas, for snap versions prior to the one that has just been updated — meaning that, at most, two versions of a snap will be present on the system. This saves disk space without compromising the ability to revert the snap to a previous known-good state.
Explicitly removing a snap from your system will also remove the code and purge the data for all prior versions.
For instance you have got installed more than one versions of gnome-calculator.
In case you only need the newest version, you can use
sudo snap remove gnome-calculator --revision <verison to be placed>
Using the command
losetup -a
shows you the mounted snaps (loop devices)
If you want to delete the double ones, type
sudo losetup -d /dev/loop<loopnumber>
It seems to be an error of the snap code, since all older been kept in the /var/lib/snapd/snaps file.
1
sudo: remove: command not foundandlosetup -dchanges nothing.
– jordy
Jun 27 '18 at 12:45
3
The correct code issudo snap removenotsudo remove. Please revise your answer.
– jordy
Jun 27 '18 at 13:10
add a comment |
When you type the command
snap list
you will get the output of actual installed snap packages. The reason is when a snap package is updated, the old version is kept (see snapcraft docu).
Citate from snapcraft docu
Garbage collection then removes and purges any snap files, and their writable areas, for snap versions prior to the one that has just been updated — meaning that, at most, two versions of a snap will be present on the system. This saves disk space without compromising the ability to revert the snap to a previous known-good state.
Explicitly removing a snap from your system will also remove the code and purge the data for all prior versions.
For instance you have got installed more than one versions of gnome-calculator.
In case you only need the newest version, you can use
sudo snap remove gnome-calculator --revision <verison to be placed>
Using the command
losetup -a
shows you the mounted snaps (loop devices)
If you want to delete the double ones, type
sudo losetup -d /dev/loop<loopnumber>
It seems to be an error of the snap code, since all older been kept in the /var/lib/snapd/snaps file.
1
sudo: remove: command not foundandlosetup -dchanges nothing.
– jordy
Jun 27 '18 at 12:45
3
The correct code issudo snap removenotsudo remove. Please revise your answer.
– jordy
Jun 27 '18 at 13:10
add a comment |
When you type the command
snap list
you will get the output of actual installed snap packages. The reason is when a snap package is updated, the old version is kept (see snapcraft docu).
Citate from snapcraft docu
Garbage collection then removes and purges any snap files, and their writable areas, for snap versions prior to the one that has just been updated — meaning that, at most, two versions of a snap will be present on the system. This saves disk space without compromising the ability to revert the snap to a previous known-good state.
Explicitly removing a snap from your system will also remove the code and purge the data for all prior versions.
For instance you have got installed more than one versions of gnome-calculator.
In case you only need the newest version, you can use
sudo snap remove gnome-calculator --revision <verison to be placed>
Using the command
losetup -a
shows you the mounted snaps (loop devices)
If you want to delete the double ones, type
sudo losetup -d /dev/loop<loopnumber>
It seems to be an error of the snap code, since all older been kept in the /var/lib/snapd/snaps file.
When you type the command
snap list
you will get the output of actual installed snap packages. The reason is when a snap package is updated, the old version is kept (see snapcraft docu).
Citate from snapcraft docu
Garbage collection then removes and purges any snap files, and their writable areas, for snap versions prior to the one that has just been updated — meaning that, at most, two versions of a snap will be present on the system. This saves disk space without compromising the ability to revert the snap to a previous known-good state.
Explicitly removing a snap from your system will also remove the code and purge the data for all prior versions.
For instance you have got installed more than one versions of gnome-calculator.
In case you only need the newest version, you can use
sudo snap remove gnome-calculator --revision <verison to be placed>
Using the command
losetup -a
shows you the mounted snaps (loop devices)
If you want to delete the double ones, type
sudo losetup -d /dev/loop<loopnumber>
It seems to be an error of the snap code, since all older been kept in the /var/lib/snapd/snaps file.
edited Jun 27 '18 at 13:19
answered Jun 17 '18 at 22:43
abu_buaabu_bua
3,38681227
3,38681227
1
sudo: remove: command not foundandlosetup -dchanges nothing.
– jordy
Jun 27 '18 at 12:45
3
The correct code issudo snap removenotsudo remove. Please revise your answer.
– jordy
Jun 27 '18 at 13:10
add a comment |
1
sudo: remove: command not foundandlosetup -dchanges nothing.
– jordy
Jun 27 '18 at 12:45
3
The correct code issudo snap removenotsudo remove. Please revise your answer.
– jordy
Jun 27 '18 at 13:10
1
1
sudo: remove: command not found and losetup -d changes nothing.– jordy
Jun 27 '18 at 12:45
sudo: remove: command not found and losetup -d changes nothing.– jordy
Jun 27 '18 at 12:45
3
3
The correct code is
sudo snap remove not sudo remove. Please revise your answer.– jordy
Jun 27 '18 at 13:10
The correct code is
sudo snap remove not sudo remove. Please revise your answer.– jordy
Jun 27 '18 at 13:10
add a comment |
From the content in your question, your problem is about searching for a way to have control over what you're seeing when you try to view your block devices than how snap uses block devices for its operation.
I agree with your referenced distinction between fdisk -l and parted -l. While fdisk shows a very good detailed output of block devices, it shows too many other things that distract from what you're trying to see.
Resolution
You can use filter the lsblk formatted output. This works well to give a clean output like what you get with gnome-disk-utility.
$ lsblk -o name,mountpoint,label,size,fstype,uuid | egrep -v "^loop"
Or as you indicated in your question:
$ sudo parted -l
For the df command in your question, use:
$ df | egrep -v /dev/loop
3
I was waiting a long time for someone to suggest exactly this, a filtered output for lsblk (rather than all those comments defending the excessive output as normal and good). I would like to avoid having to do this, however, just because plain and straightlsblkwas quick, easy to remember, and it worked beautifully, before snap interfered with it. I want it back as it was. Hopefully, the excessive output is just a bug that will get fixed.
– jordy
Jun 22 '18 at 9:36
4
@danthonyd Thanks for the acknowledgment. I was sure I understood the question and felt certain it deserved a spot in the AU database of information for consideration and answering. This is something I've been concerned about for a long time. However, the problem isn't Snap. The problem is with thefdiskdevelopers. They should add a method to filter out real devices over the pseudo devices to remove the excessive output and make their application more manageable, like the Gnome-disk-utility. No one would be usingfdiskto manage their loop devices. (continued)...
– L. D. James
Jun 22 '18 at 10:31
4
... (continued) They don't even need to see it in the the fdisk output. That is what losetup and other pseudo application commands are for. So why bother showing it, if you can't manage it with the tool. This flaw in the fdisk design is making apps like parted and lsblk more popular and user friendly.
– L. D. James
Jun 22 '18 at 10:34
Thank you. I'm adding| egrep -v "^loop"to all my 16.04lsblkscripts today to reduce maintenance on the day I convert to 18.04. (FYI I had already up-voted your answer before today)
– WinEunuuchs2Unix
Oct 21 '18 at 15:32
add a comment |
From the content in your question, your problem is about searching for a way to have control over what you're seeing when you try to view your block devices than how snap uses block devices for its operation.
I agree with your referenced distinction between fdisk -l and parted -l. While fdisk shows a very good detailed output of block devices, it shows too many other things that distract from what you're trying to see.
Resolution
You can use filter the lsblk formatted output. This works well to give a clean output like what you get with gnome-disk-utility.
$ lsblk -o name,mountpoint,label,size,fstype,uuid | egrep -v "^loop"
Or as you indicated in your question:
$ sudo parted -l
For the df command in your question, use:
$ df | egrep -v /dev/loop
3
I was waiting a long time for someone to suggest exactly this, a filtered output for lsblk (rather than all those comments defending the excessive output as normal and good). I would like to avoid having to do this, however, just because plain and straightlsblkwas quick, easy to remember, and it worked beautifully, before snap interfered with it. I want it back as it was. Hopefully, the excessive output is just a bug that will get fixed.
– jordy
Jun 22 '18 at 9:36
4
@danthonyd Thanks for the acknowledgment. I was sure I understood the question and felt certain it deserved a spot in the AU database of information for consideration and answering. This is something I've been concerned about for a long time. However, the problem isn't Snap. The problem is with thefdiskdevelopers. They should add a method to filter out real devices over the pseudo devices to remove the excessive output and make their application more manageable, like the Gnome-disk-utility. No one would be usingfdiskto manage their loop devices. (continued)...
– L. D. James
Jun 22 '18 at 10:31
4
... (continued) They don't even need to see it in the the fdisk output. That is what losetup and other pseudo application commands are for. So why bother showing it, if you can't manage it with the tool. This flaw in the fdisk design is making apps like parted and lsblk more popular and user friendly.
– L. D. James
Jun 22 '18 at 10:34
Thank you. I'm adding| egrep -v "^loop"to all my 16.04lsblkscripts today to reduce maintenance on the day I convert to 18.04. (FYI I had already up-voted your answer before today)
– WinEunuuchs2Unix
Oct 21 '18 at 15:32
add a comment |
From the content in your question, your problem is about searching for a way to have control over what you're seeing when you try to view your block devices than how snap uses block devices for its operation.
I agree with your referenced distinction between fdisk -l and parted -l. While fdisk shows a very good detailed output of block devices, it shows too many other things that distract from what you're trying to see.
Resolution
You can use filter the lsblk formatted output. This works well to give a clean output like what you get with gnome-disk-utility.
$ lsblk -o name,mountpoint,label,size,fstype,uuid | egrep -v "^loop"
Or as you indicated in your question:
$ sudo parted -l
For the df command in your question, use:
$ df | egrep -v /dev/loop
From the content in your question, your problem is about searching for a way to have control over what you're seeing when you try to view your block devices than how snap uses block devices for its operation.
I agree with your referenced distinction between fdisk -l and parted -l. While fdisk shows a very good detailed output of block devices, it shows too many other things that distract from what you're trying to see.
Resolution
You can use filter the lsblk formatted output. This works well to give a clean output like what you get with gnome-disk-utility.
$ lsblk -o name,mountpoint,label,size,fstype,uuid | egrep -v "^loop"
Or as you indicated in your question:
$ sudo parted -l
For the df command in your question, use:
$ df | egrep -v /dev/loop
edited Jun 21 '18 at 9:26
answered Jun 21 '18 at 8:49
L. D. JamesL. D. James
18.5k43789
18.5k43789
3
I was waiting a long time for someone to suggest exactly this, a filtered output for lsblk (rather than all those comments defending the excessive output as normal and good). I would like to avoid having to do this, however, just because plain and straightlsblkwas quick, easy to remember, and it worked beautifully, before snap interfered with it. I want it back as it was. Hopefully, the excessive output is just a bug that will get fixed.
– jordy
Jun 22 '18 at 9:36
4
@danthonyd Thanks for the acknowledgment. I was sure I understood the question and felt certain it deserved a spot in the AU database of information for consideration and answering. This is something I've been concerned about for a long time. However, the problem isn't Snap. The problem is with thefdiskdevelopers. They should add a method to filter out real devices over the pseudo devices to remove the excessive output and make their application more manageable, like the Gnome-disk-utility. No one would be usingfdiskto manage their loop devices. (continued)...
– L. D. James
Jun 22 '18 at 10:31
4
... (continued) They don't even need to see it in the the fdisk output. That is what losetup and other pseudo application commands are for. So why bother showing it, if you can't manage it with the tool. This flaw in the fdisk design is making apps like parted and lsblk more popular and user friendly.
– L. D. James
Jun 22 '18 at 10:34
Thank you. I'm adding| egrep -v "^loop"to all my 16.04lsblkscripts today to reduce maintenance on the day I convert to 18.04. (FYI I had already up-voted your answer before today)
– WinEunuuchs2Unix
Oct 21 '18 at 15:32
add a comment |
3
I was waiting a long time for someone to suggest exactly this, a filtered output for lsblk (rather than all those comments defending the excessive output as normal and good). I would like to avoid having to do this, however, just because plain and straightlsblkwas quick, easy to remember, and it worked beautifully, before snap interfered with it. I want it back as it was. Hopefully, the excessive output is just a bug that will get fixed.
– jordy
Jun 22 '18 at 9:36
4
@danthonyd Thanks for the acknowledgment. I was sure I understood the question and felt certain it deserved a spot in the AU database of information for consideration and answering. This is something I've been concerned about for a long time. However, the problem isn't Snap. The problem is with thefdiskdevelopers. They should add a method to filter out real devices over the pseudo devices to remove the excessive output and make their application more manageable, like the Gnome-disk-utility. No one would be usingfdiskto manage their loop devices. (continued)...
– L. D. James
Jun 22 '18 at 10:31
4
... (continued) They don't even need to see it in the the fdisk output. That is what losetup and other pseudo application commands are for. So why bother showing it, if you can't manage it with the tool. This flaw in the fdisk design is making apps like parted and lsblk more popular and user friendly.
– L. D. James
Jun 22 '18 at 10:34
Thank you. I'm adding| egrep -v "^loop"to all my 16.04lsblkscripts today to reduce maintenance on the day I convert to 18.04. (FYI I had already up-voted your answer before today)
– WinEunuuchs2Unix
Oct 21 '18 at 15:32
3
3
I was waiting a long time for someone to suggest exactly this, a filtered output for lsblk (rather than all those comments defending the excessive output as normal and good). I would like to avoid having to do this, however, just because plain and straight
lsblk was quick, easy to remember, and it worked beautifully, before snap interfered with it. I want it back as it was. Hopefully, the excessive output is just a bug that will get fixed.– jordy
Jun 22 '18 at 9:36
I was waiting a long time for someone to suggest exactly this, a filtered output for lsblk (rather than all those comments defending the excessive output as normal and good). I would like to avoid having to do this, however, just because plain and straight
lsblk was quick, easy to remember, and it worked beautifully, before snap interfered with it. I want it back as it was. Hopefully, the excessive output is just a bug that will get fixed.– jordy
Jun 22 '18 at 9:36
4
4
@danthonyd Thanks for the acknowledgment. I was sure I understood the question and felt certain it deserved a spot in the AU database of information for consideration and answering. This is something I've been concerned about for a long time. However, the problem isn't Snap. The problem is with the
fdisk developers. They should add a method to filter out real devices over the pseudo devices to remove the excessive output and make their application more manageable, like the Gnome-disk-utility. No one would be using fdisk to manage their loop devices. (continued)...– L. D. James
Jun 22 '18 at 10:31
@danthonyd Thanks for the acknowledgment. I was sure I understood the question and felt certain it deserved a spot in the AU database of information for consideration and answering. This is something I've been concerned about for a long time. However, the problem isn't Snap. The problem is with the
fdisk developers. They should add a method to filter out real devices over the pseudo devices to remove the excessive output and make their application more manageable, like the Gnome-disk-utility. No one would be using fdisk to manage their loop devices. (continued)...– L. D. James
Jun 22 '18 at 10:31
4
4
... (continued) They don't even need to see it in the the fdisk output. That is what losetup and other pseudo application commands are for. So why bother showing it, if you can't manage it with the tool. This flaw in the fdisk design is making apps like parted and lsblk more popular and user friendly.
– L. D. James
Jun 22 '18 at 10:34
... (continued) They don't even need to see it in the the fdisk output. That is what losetup and other pseudo application commands are for. So why bother showing it, if you can't manage it with the tool. This flaw in the fdisk design is making apps like parted and lsblk more popular and user friendly.
– L. D. James
Jun 22 '18 at 10:34
Thank you. I'm adding
| egrep -v "^loop" to all my 16.04 lsblk scripts today to reduce maintenance on the day I convert to 18.04. (FYI I had already up-voted your answer before today)– WinEunuuchs2Unix
Oct 21 '18 at 15:32
Thank you. I'm adding
| egrep -v "^loop" to all my 16.04 lsblk scripts today to reduce maintenance on the day I convert to 18.04. (FYI I had already up-voted your answer before today)– WinEunuuchs2Unix
Oct 21 '18 at 15:32
add a comment |
If you use the snap version of the system monitor, then you will see all file systems used by snap as well as the ones you use.
An easy "fix" is to uninstall Gnome System Monitor from the app store. It is the snap-version.
Then install Gnome System Monitor from the normal repositories using Synaptic package manager. It is the normal version that installs a bunch of files all over you root partition. Nice!
And you will see just what you expect to see when you launch Gnome System Monitor...
Great! This is what I was looking for. The commands aresnap remove gnome-system-monitor(no sudo required), followed bysudo apt install gnome-system-monitor(this time with sudo).
– PerlDuck
Nov 17 '18 at 19:06
add a comment |
If you use the snap version of the system monitor, then you will see all file systems used by snap as well as the ones you use.
An easy "fix" is to uninstall Gnome System Monitor from the app store. It is the snap-version.
Then install Gnome System Monitor from the normal repositories using Synaptic package manager. It is the normal version that installs a bunch of files all over you root partition. Nice!
And you will see just what you expect to see when you launch Gnome System Monitor...
Great! This is what I was looking for. The commands aresnap remove gnome-system-monitor(no sudo required), followed bysudo apt install gnome-system-monitor(this time with sudo).
– PerlDuck
Nov 17 '18 at 19:06
add a comment |
If you use the snap version of the system monitor, then you will see all file systems used by snap as well as the ones you use.
An easy "fix" is to uninstall Gnome System Monitor from the app store. It is the snap-version.
Then install Gnome System Monitor from the normal repositories using Synaptic package manager. It is the normal version that installs a bunch of files all over you root partition. Nice!
And you will see just what you expect to see when you launch Gnome System Monitor...
If you use the snap version of the system monitor, then you will see all file systems used by snap as well as the ones you use.
An easy "fix" is to uninstall Gnome System Monitor from the app store. It is the snap-version.
Then install Gnome System Monitor from the normal repositories using Synaptic package manager. It is the normal version that installs a bunch of files all over you root partition. Nice!
And you will see just what you expect to see when you launch Gnome System Monitor...
answered Sep 20 '18 at 14:55
Anders LarsenAnders Larsen
111
111
Great! This is what I was looking for. The commands aresnap remove gnome-system-monitor(no sudo required), followed bysudo apt install gnome-system-monitor(this time with sudo).
– PerlDuck
Nov 17 '18 at 19:06
add a comment |
Great! This is what I was looking for. The commands aresnap remove gnome-system-monitor(no sudo required), followed bysudo apt install gnome-system-monitor(this time with sudo).
– PerlDuck
Nov 17 '18 at 19:06
Great! This is what I was looking for. The commands are
snap remove gnome-system-monitor (no sudo required), followed by sudo apt install gnome-system-monitor (this time with sudo).– PerlDuck
Nov 17 '18 at 19:06
Great! This is what I was looking for. The commands are
snap remove gnome-system-monitor (no sudo required), followed by sudo apt install gnome-system-monitor (this time with sudo).– PerlDuck
Nov 17 '18 at 19:06
add a comment |
I find this annoying too. It seems if they are not running they should not be mounted or listed.
You can run this command to exclude all the loop devices.
$ lsblk -e 7
add a comment |
I find this annoying too. It seems if they are not running they should not be mounted or listed.
You can run this command to exclude all the loop devices.
$ lsblk -e 7
add a comment |
I find this annoying too. It seems if they are not running they should not be mounted or listed.
You can run this command to exclude all the loop devices.
$ lsblk -e 7
I find this annoying too. It seems if they are not running they should not be mounted or listed.
You can run this command to exclude all the loop devices.
$ lsblk -e 7
answered Jan 7 at 3:08
user911218user911218
111
111
add a comment |
add a comment |
To only show mounts excluding loopback you could also simply:
lsblk -af |grep -sv loop
;)
add a comment |
To only show mounts excluding loopback you could also simply:
lsblk -af |grep -sv loop
;)
add a comment |
To only show mounts excluding loopback you could also simply:
lsblk -af |grep -sv loop
;)
To only show mounts excluding loopback you could also simply:
lsblk -af |grep -sv loop
;)
answered Jan 12 at 13:32
jbrios777jbrios777
11
11
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1047456%2fwhy-are-all-snaps-being-mounted-and-listed-as-block-devices-or-partitions-for-ub%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I think the actual answer to your question is at this related question: "Snap packages are squashfs file systems. The only way to access snaps is to mount them. So yes, they will always be mounted." askubuntu.com/questions/842093/… God I wish they didn't have to be mounted!
– craq
Jan 26 at 5:55