/dev/sd* missing

[PPC601]

I'm trying to update the custom kernel on my NSA325 from 4.0.4 to 4.4.21, and it's failing because my partitions don't show up:
The disks are recognized*, but there are no entries in /dev (neither disk nor partitions).
When I connect a USB-drive, the behavior is similar.

Although the try-and-error cycle takes quite a long time (compiling the kernel takes hours), there's hardly any option in the block device, ata and scsi-sections left that looks like worth trying, and I changed parameters for mkinitcpio as well.

I'm using btrfs for everything but /boot, and the standard-kernel did not work with this setup - and a kernel-config extracted from the standard-kernel had the same issues of missing sd*...

Does someone have a link to a working configuration, or a theory what's happening here?

*
[ 10.669410] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[ 10.689609] ata1.00: ATA-9: WDC WD40EFRX-68WT0N0, 80.00A80, max UDMA/133
[ 10.696343] ata1.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[ 10.709401] usb 1-1: new high-speed USB device number 2 using orion-ehci
[ 10.719609] ata1.00: configured for UDMA/133
[ 10.739745] scsi 0:0:0:0: Direct-Access ATA WDC WD40EFRX-68W 0A80 PQ: 0 ANSI: 5

[summers]

thought that dev files were created by udev automatically - mhh wondr if I'm rembering that correctly - I'll log onto my NSA325 and check.

[PPC601]

Thanks - I was used to see the files created automatically as well
I'm quite sure it's not a driver problem, so I fiddled with uboot, ramdisk and kernel parameters as well; I'm looking forward that CMDLINE_PARTITION helps (it just takes so long to build all that stuff... if I knew in advance how many tries I had to make, I'd thought about setting up distcc to speed up compilation)

[WarheadsSE]

This is a new one to me. Sadly, my 325 has bitten the proverbial dust, and does not even begin to boot. (Won't really even power on)

[summers]

Oops forgot to update this thread.

Anyway on my 325, I have the device files as expected.

If I had to guess, udev has died for some reason. You should be able to probe with the udevadm command - but for the life of me can't work out how to get it to list everything installed.

I'm likely to be quite busy this week - so probably won't get a chance to look into this ....

... anyway when time comes back I'll dig some more if its still an issue ...

[PPC601]

Just found a "solution" (it's a solution, but I'm not happy with it):
I'm running the default kernel with a custom ramdisk - and several days of stupid compiling will tame my curiosity to find out why my kernel failed (I hope at least until the next major upgrade

At least, there are only 3 options left:
I made an error when I extracted the .config from the default kernel
I had the wrong source
ccache messed things up (don't think so).

Thanks for your interest - if the reason for the problem isn't to embarrassing , I'll write about it here when I find it.

[summers]

Managed 5 minutes looking at my NSA325 last night if you do "udevadm monitor" and plug in a USB stick, you should get a shed load of messages. That should at least say if udev is up ....

If udev is down that will be the problem, so give you something to dig into.

Yes a bad initramfs would cause problems like that. WHat I guess happened is that the kernel had a reasonable root passed on the command line - that was enough to bring the machine up. However udev didn't manage to come up and bring up the mounbt points. So udev not working correctly in initramfs would cause the problem.

ANyway hope you get to the bottom of the problem.