Roman Stöckl-Schmidt wrote:
Hi fellow debianists!I've compiled a kernel from the up-to-date kernel-source-2.6 package with the aim to be able to build realtime linux security module. To do this I followed the instructions from the README.Debian in the realtime-lsm documentation. I got the linux-2.6_2.6.18-7 sources, unpacked them in /usr/src, copied the config of my running kernel from /boot/config-2.6.18-3-686 to /usr/src/linux-2.6-2.6.18/.config and updated it to say CONFIG_SECURITY_CAPABILITIES=m.Now when i try to boot it it sits there "wating for root filesystem", after some t&a i figured out that somehow the new kernel (or the initrd.img, don't know which is responsible here) registers my external usb hdd as sda and my internal sata hdd as sdb which is usually the other way round. if i turn off the usb disk and boot again it works, but that is not really a viable option and also i discovered that my internet or rather network device doesn't work as well. If I keep the usb drive turned on and change the grub boot option to say"kernel /boot/vmlinuz-2.6.18-1-lsm root=/dev/sdb3 ro"instead of root=/dev/sda3, the boot process continues until the devices from fstab.fstab: # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0/dev/sda3 / ext3 defaults,errors=remount-ro 0 1/dev/sda9 /home ext3 defaults 0 2 /dev/sda8 /tmp ext3 defaults 0 2 /dev/sda5 /usr ext3 defaults 0 2 /dev/sda6 /var ext3 defaults 0 2 /dev/sda7 none swap sw 0 0 /dev/hde /media/cdrom0 udf,iso9660 user,noauto 0 0/dev/sdb1 /daten vfat user,auto,uid=1000,gid=1000 0 2but of course fails, because sda should be sdb and vice versa.Any help would be greatly appreciated. It would be possible to load different /boot/grub/menu.lst and /etc/fstab files at boot via some shell scripts, but that wouldnt be a really good solution and the ethernet problem remains.Thanks in advance, Roman.
Hi, Roman,I've made several posts in the past year or so, on using the LABEL feature of fstab and the kernel to "fix" this issue. Searching on my name should find the more detailed posts.
Bottom line is that, with the various sub-systems possible and differences in the scan sequence for BIOS versus Grub versus the kernel, it's difficult sometimes to get the right order based on the device name.
By labeling the devices in a unique manner and using the LABEL=mylabel, you can get the system to always use the "right" disk(s) for booting and mounting filesystems.
Bob
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature