How can hwinfo find disks that lsblk can't and that don't show up as a /dev/sdXY?

Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I recently ran into a situation where my kernel was missing a module necessary for accessing an external USB hard drive. The drive wasn't found by lsblk and didn't have a /dev/sdXY but strangely hwinfo --disk was still able to find it.
How does hwinfo search for disks and why can it find things that other tools miss? (I figured all these sorts of tools were just munging through the /dev filesystem in a very similar manner.)
usb disk
add a comment |Â
up vote
0
down vote
favorite
I recently ran into a situation where my kernel was missing a module necessary for accessing an external USB hard drive. The drive wasn't found by lsblk and didn't have a /dev/sdXY but strangely hwinfo --disk was still able to find it.
How does hwinfo search for disks and why can it find things that other tools miss? (I figured all these sorts of tools were just munging through the /dev filesystem in a very similar manner.)
usb disk
1
hwinfo --diskshould give you the answer. Not recognized asblockdevice? As you said the kernel module was missing, so how could the kernel know much about the device?
â ridgy
Dec 26 '17 at 12:41
@ridgy Add some details and this is a good answer. (e.g. how can I tell from the hwinfo output that something isn't recognized as a block device? how can hwinfo know that something is a disk if the kernel doesn't recognize it as a block device?)
â Praxeolitic
Dec 26 '17 at 14:12
I am not an expert for hwinfo. But there are some sources for information:hwinfo --dump-db 1shows the content of the internal hardware database, which contains lots of information depending on device classes etc. For a removable device, you can rundmesg -wbefore attaching it, to see what information the kernel gets. Maybe from some of the device information (and maybe from the database)hwinfogets theHardware class: diskinformation. The device information itself seems to depend on the driver module, so there might be no device information (can't test, have no device not working).
â ridgy
Dec 26 '17 at 15:06
I digged a bit deeper, and when you runhwinfo | lessyou will see that there are lots of subsystems asked for information. Especiallyudevinfoshows full device information, and with some of them there are entries...FROM_DATABASE...
â ridgy
Dec 26 '17 at 15:25
@ridgy Good find. This is plenty good for an answer. I didn't mean to give the impression that I wanted a line-by-line explanation of the hwinfo source. hwinfo just happened to be the tool where I saw this behavior but I wanted to know in general how it's possible for a tool to do this and you've explained that.
â Praxeolitic
Dec 26 '17 at 15:54
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I recently ran into a situation where my kernel was missing a module necessary for accessing an external USB hard drive. The drive wasn't found by lsblk and didn't have a /dev/sdXY but strangely hwinfo --disk was still able to find it.
How does hwinfo search for disks and why can it find things that other tools miss? (I figured all these sorts of tools were just munging through the /dev filesystem in a very similar manner.)
usb disk
I recently ran into a situation where my kernel was missing a module necessary for accessing an external USB hard drive. The drive wasn't found by lsblk and didn't have a /dev/sdXY but strangely hwinfo --disk was still able to find it.
How does hwinfo search for disks and why can it find things that other tools miss? (I figured all these sorts of tools were just munging through the /dev filesystem in a very similar manner.)
usb disk
asked Dec 25 '17 at 18:27
Praxeolitic
6671017
6671017
1
hwinfo --diskshould give you the answer. Not recognized asblockdevice? As you said the kernel module was missing, so how could the kernel know much about the device?
â ridgy
Dec 26 '17 at 12:41
@ridgy Add some details and this is a good answer. (e.g. how can I tell from the hwinfo output that something isn't recognized as a block device? how can hwinfo know that something is a disk if the kernel doesn't recognize it as a block device?)
â Praxeolitic
Dec 26 '17 at 14:12
I am not an expert for hwinfo. But there are some sources for information:hwinfo --dump-db 1shows the content of the internal hardware database, which contains lots of information depending on device classes etc. For a removable device, you can rundmesg -wbefore attaching it, to see what information the kernel gets. Maybe from some of the device information (and maybe from the database)hwinfogets theHardware class: diskinformation. The device information itself seems to depend on the driver module, so there might be no device information (can't test, have no device not working).
â ridgy
Dec 26 '17 at 15:06
I digged a bit deeper, and when you runhwinfo | lessyou will see that there are lots of subsystems asked for information. Especiallyudevinfoshows full device information, and with some of them there are entries...FROM_DATABASE...
â ridgy
Dec 26 '17 at 15:25
@ridgy Good find. This is plenty good for an answer. I didn't mean to give the impression that I wanted a line-by-line explanation of the hwinfo source. hwinfo just happened to be the tool where I saw this behavior but I wanted to know in general how it's possible for a tool to do this and you've explained that.
â Praxeolitic
Dec 26 '17 at 15:54
add a comment |Â
1
hwinfo --diskshould give you the answer. Not recognized asblockdevice? As you said the kernel module was missing, so how could the kernel know much about the device?
â ridgy
Dec 26 '17 at 12:41
@ridgy Add some details and this is a good answer. (e.g. how can I tell from the hwinfo output that something isn't recognized as a block device? how can hwinfo know that something is a disk if the kernel doesn't recognize it as a block device?)
â Praxeolitic
Dec 26 '17 at 14:12
I am not an expert for hwinfo. But there are some sources for information:hwinfo --dump-db 1shows the content of the internal hardware database, which contains lots of information depending on device classes etc. For a removable device, you can rundmesg -wbefore attaching it, to see what information the kernel gets. Maybe from some of the device information (and maybe from the database)hwinfogets theHardware class: diskinformation. The device information itself seems to depend on the driver module, so there might be no device information (can't test, have no device not working).
â ridgy
Dec 26 '17 at 15:06
I digged a bit deeper, and when you runhwinfo | lessyou will see that there are lots of subsystems asked for information. Especiallyudevinfoshows full device information, and with some of them there are entries...FROM_DATABASE...
â ridgy
Dec 26 '17 at 15:25
@ridgy Good find. This is plenty good for an answer. I didn't mean to give the impression that I wanted a line-by-line explanation of the hwinfo source. hwinfo just happened to be the tool where I saw this behavior but I wanted to know in general how it's possible for a tool to do this and you've explained that.
â Praxeolitic
Dec 26 '17 at 15:54
1
1
hwinfo --diskshould give you the answer. Not recognized as blockdevice? As you said the kernel module was missing, so how could the kernel know much about the device?â ridgy
Dec 26 '17 at 12:41
hwinfo --diskshould give you the answer. Not recognized as blockdevice? As you said the kernel module was missing, so how could the kernel know much about the device?â ridgy
Dec 26 '17 at 12:41
@ridgy Add some details and this is a good answer. (e.g. how can I tell from the hwinfo output that something isn't recognized as a block device? how can hwinfo know that something is a disk if the kernel doesn't recognize it as a block device?)
â Praxeolitic
Dec 26 '17 at 14:12
@ridgy Add some details and this is a good answer. (e.g. how can I tell from the hwinfo output that something isn't recognized as a block device? how can hwinfo know that something is a disk if the kernel doesn't recognize it as a block device?)
â Praxeolitic
Dec 26 '17 at 14:12
I am not an expert for hwinfo. But there are some sources for information:
hwinfo --dump-db 1shows the content of the internal hardware database, which contains lots of information depending on device classes etc. For a removable device, you can run dmesg -w before attaching it, to see what information the kernel gets. Maybe from some of the device information (and maybe from the database) hwinfo gets the Hardware class: disk information. The device information itself seems to depend on the driver module, so there might be no device information (can't test, have no device not working).â ridgy
Dec 26 '17 at 15:06
I am not an expert for hwinfo. But there are some sources for information:
hwinfo --dump-db 1shows the content of the internal hardware database, which contains lots of information depending on device classes etc. For a removable device, you can run dmesg -w before attaching it, to see what information the kernel gets. Maybe from some of the device information (and maybe from the database) hwinfo gets the Hardware class: disk information. The device information itself seems to depend on the driver module, so there might be no device information (can't test, have no device not working).â ridgy
Dec 26 '17 at 15:06
I digged a bit deeper, and when you run
hwinfo | less you will see that there are lots of subsystems asked for information. Especially udevinfo shows full device information, and with some of them there are entries ...FROM_DATABASE...â ridgy
Dec 26 '17 at 15:25
I digged a bit deeper, and when you run
hwinfo | less you will see that there are lots of subsystems asked for information. Especially udevinfo shows full device information, and with some of them there are entries ...FROM_DATABASE...â ridgy
Dec 26 '17 at 15:25
@ridgy Good find. This is plenty good for an answer. I didn't mean to give the impression that I wanted a line-by-line explanation of the hwinfo source. hwinfo just happened to be the tool where I saw this behavior but I wanted to know in general how it's possible for a tool to do this and you've explained that.
â Praxeolitic
Dec 26 '17 at 15:54
@ridgy Good find. This is plenty good for an answer. I didn't mean to give the impression that I wanted a line-by-line explanation of the hwinfo source. hwinfo just happened to be the tool where I saw this behavior but I wanted to know in general how it's possible for a tool to do this and you've explained that.
â Praxeolitic
Dec 26 '17 at 15:54
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f413001%2fhow-can-hwinfo-find-disks-that-lsblk-cant-and-that-dont-show-up-as-a-dev-sdxy%23new-answer', 'question_page');
);
Post as a guest
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
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
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
1
hwinfo --diskshould give you the answer. Not recognized asblockdevice? As you said the kernel module was missing, so how could the kernel know much about the device?â ridgy
Dec 26 '17 at 12:41
@ridgy Add some details and this is a good answer. (e.g. how can I tell from the hwinfo output that something isn't recognized as a block device? how can hwinfo know that something is a disk if the kernel doesn't recognize it as a block device?)
â Praxeolitic
Dec 26 '17 at 14:12
I am not an expert for hwinfo. But there are some sources for information:
hwinfo --dump-db 1shows the content of the internal hardware database, which contains lots of information depending on device classes etc. For a removable device, you can rundmesg -wbefore attaching it, to see what information the kernel gets. Maybe from some of the device information (and maybe from the database)hwinfogets theHardware class: diskinformation. The device information itself seems to depend on the driver module, so there might be no device information (can't test, have no device not working).â ridgy
Dec 26 '17 at 15:06
I digged a bit deeper, and when you run
hwinfo | lessyou will see that there are lots of subsystems asked for information. Especiallyudevinfoshows full device information, and with some of them there are entries...FROM_DATABASE...â ridgy
Dec 26 '17 at 15:25
@ridgy Good find. This is plenty good for an answer. I didn't mean to give the impression that I wanted a line-by-line explanation of the hwinfo source. hwinfo just happened to be the tool where I saw this behavior but I wanted to know in general how it's possible for a tool to do this and you've explained that.
â Praxeolitic
Dec 26 '17 at 15:54