I have finally decided to try and find what I believe is a kernel bug that is affecting my netbook. If the wireless is being managed by NetworkManager, WICD, etc and I suspend the netbook, it will not resume properly. It will power up but the screen will not turn on, and it is not responsive to http or ssh requests. This behaviour exists in ArchLinux, and Debian (and derivatives). It appeared to have been an issue with between Wheezy(w/3.2) and Jessie(w/3.16)
To decrease the build time, bisecting, errors and extra ‘noise’, I am attempting to build a slimmed down kernel with just needed configs to run my laptop. (This will also insure it is not just a conflict).
I am building a vanilla kernel from linux-stable with the make deb-pkg target. I install the resulting package, it builds the initrd, and only have some warnings and one fatal about not having modules (which I don’t).
Restart with default GRUB settings, and boot:
ALERT! /dev/disk/by-uuid/xxxxx does not exist.
Dropped to a busybox shell.
Removing quiet boot parameter shows it is looping on scripts/local-block, trying to access my root partition which of course it cannot. Nothing looks wobbly.
/dev does not contain a /disk directory that is true. But it does have sda[1-4], which is correct. Udev seems to not be doing its job and following its persistent storage rules and creating the by-uuid symlink. If I run udevadm test on /dev/sda2 (which is my root directory) no errors or warnings and it creates the by-uuid symlink as it should.
Filling in my ignorance a bit with reading, it seems like it could be a udev timing problem. Under the generic 3.16 kernel, system-udved gets called at least a tenth of second before the kernel detects my SCSI SSD. With my custom kernel, system-udved is called well after the kernel detects my SSD. But according to some OpenSUSE documentation the kernel should just queue these messages in uevent files in /sys and udev trigger will collect these cold-plugged devices.
This doesn’t seem to be happening, and manually calling udevadm trigger --action=add or udevadm trigger doesn’t seem run the rules for /dev/sda either.
Copying the generic config file and rebuilding the generic kernel does not exhibit this issue.
Could I be missing some device drivers, kernel config needed for udev? Which doesn’t seem likely as I can just manually make udev load the rules. Some assistance would be of great thanks.
Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230