Unbootable 2.6.28 kernel
Dear All, When I try to boot into kernel 2.6.28, I get a kernel panic with message `VFS: Cannot open root device "hda1" or unknown block (0,0)', followed by a list of available partitions which suggests that, between kernels 2.6.27.10 and 2.6.28, the drive on which I keep my root filesystem has changed its name from /dev/hda to /dev/sda. Is this expectable behavior? Should I edit my "root" boot option and fstab accordingly? Or does it indicate something wrong? -- Thanks, Dan
On Sun, 2009-01-18 at 18:20 +0000, Dan Hatton wrote:
the drive on which I keep my root filesystem has changed its name from /dev/hda to /dev/sda. Is this expectable behavior? Should I edit my "root" boot option and fstab accordingly? Or does it indicate something wrong?
No it is possible...it might be as simple as some storage driver was using a legacy ATA emulation fallback to access SATA drives and is now in native mode. If you are going to have to edit the boot options and fstab anyway why not move over to UUID's ?
hi 2009/1/18 Wayne Stallwood <ALUGlist@digimatic.co.uk>:
On Sun, 2009-01-18 at 18:20 +0000, Dan Hatton wrote:
the drive on which I keep my root filesystem has changed its name from /dev/hda to /dev/sda. Is this expectable behavior? Should I edit my "root" boot option and fstab accordingly? Or does it indicate something wrong?
No it is possible...it might be as simple as some storage driver was using a legacy ATA emulation fallback to access SATA drives and is now in native mode.
I think (but am not 100% sure) that the kernel team has moved over to libata as per default, so all disk devices will be visible as sdX. There's probably a way to change this back to the previous default. Dan, did you compile the kernel and mess it up a bit? Just have a look at the config and disable libata as default. (I think also normal SATA/SCSI devices don't use libata... but I would probably be wrong - I'm sure Dan can look at the kernel config and see if that's the case). Srdj
On Sun, 18 Jan 2009, Srdjan Todorovic wrote:
Dan, did you compile the kernel and mess it up a bit?
At least one of those things ;-).
Just have a look at the config and disable libata as default.
I vaguely remember reading on t'web that the migration to libata as default promised some kind of performance improvement. ?
(I think also normal SATA/SCSI devices don't use libata... but I would probably be wrong - I'm sure Dan can look at the kernel config and see if that's the case).
diff config-2.6.27.10-tuxonice config-2.6.28-tuxonice | grep -i 'ata'
# CONFIG_MTD_DATAFLASH_WRITE_VERIFY is not set CONFIG_MTD_DATAFLASH_OTP=y CONFIG_IDE_GD_ATA=y CONFIG_IDE_GD_ATAPI=y
Any of those sound relevant? -- Thanks, Dan
Hi, 2009/1/19 Dan Hatton <vi5u0-alug@yahoo.co.uk>:
On Sun, 18 Jan 2009, Wayne Stallwood wrote:
why not move over to UUID's ?
Tell me more...
http://en.wikipedia.org/wiki/Uuid AFAIK, the UUIDs for disks are unique to filesystems. ls -l /dev/disk/by-uuid/ You can use this in fstab as such: UUID=b824e09e-e582-45ba-81aa-3b49733e82ee /data ext3 defaults 0 0 This way, it doesn't matter if you swap over the cables and the disk becomes sdb rather than sda, mount will still find the correct filesystem to mount by UUID. -Srdj
On Mon, 19 Jan 2009, Srdjan Todorovic wrote:
ls -l /dev/disk/by-uuid/
You can use this in fstab as such: UUID=b824e09e-e582-45ba-81aa-3b49733e82ee /data ext3 defaults 0 0
Ah, OK, thank you. So I've put the UUIDs in fstab, and /dev/sda? in the 2.6.28 entry in grub.conf, keeping /dev/hda? in the 2.6.27.10 entry in grub.conf. (An aside: is there any way UUIDs can be made to work in grub.conf?) Now both kernels boot just fine. And, re my earlier question about performance improvement, I'm pretty sure it's not just wishful thinking on my part that TuxOnIce hibernate/resume is considerably faster in 2.6.28 than it was in 2.6.27.10. So all is well. One more thing: in the old kernel, USB sticks etc. used to appear consistently as /dev/sda - and I had some appropriate noauto entries in fstab for them. Now, presumably, they have to compete with the hard drive for that name. What to do? -- Regards, Dan
On Mon, 2009-01-19 at 17:23 +0000, Dan Hatton wrote:
On Mon, 19 Jan 2009, Srdjan Todorovic wrote:
ls -l /dev/disk/by-uuid/
You can use this in fstab as such: UUID=b824e09e-e582-45ba-81aa-3b49733e82ee /data ext3 defaults 0 0
Ah, OK, thank you. So I've put the UUIDs in fstab, and /dev/sda? in the 2.6.28 entry in grub.conf, keeping /dev/hda? in the 2.6.27.10 entry in grub.conf. (An aside: is there any way UUIDs can be made to work in grub.conf?)
Yes there is, although the specific way you specify them escapes me at the moment. You will have to google or RTM
One more thing: in the old kernel, USB sticks etc. used to appear consistently as /dev/sda - and I had some appropriate noauto entries in fstab for them. Now, presumably, they have to compete with the hard drive for that name. What to do?
They will get something higher up the alphabet than sda like sdb etc..plug one in and watch /var/log/messages to see. Of course this *can* change depending on how many usb storage devices you have on the system or when you add more hard drives.
Hi Dan
One more thing: in the old kernel, USB sticks etc. used to appear consistently as /dev/sda - and I had some appropriate noauto entries in fstab for them. Now, presumably, they have to compete with the hard drive for that name. What to do?
Google for "udev rules", which are a way of giving consistent names to (typically USB) devices, although the rules are also useful for other things, such as making sure Ethernet adaptors have a consistent ethx number.
On Mon, 2009-01-19 at 21:14 +0000, Keith Edmunds wrote:
Google for "udev rules", which are a way of giving consistent names to (typically USB) devices, although the rules are also useful for other things, such as making sure Ethernet adaptors have a consistent ethx number.
Can't that only be done for a specific device ? i.e it is ok if you have a specific USB keydrive or set of them but you will have to manually add them if you get more. Also what happens if you end up with two drives with the same vendor and product strings plugged in at the same time ?
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On Mon, 19 Jan 2009, Keith Edmunds wrote:
Google for "udev rules", which are a way of giving consistent names to (typically USB) devices, although the rules are also useful for other things, such as making sure Ethernet adaptors have a consistent ethx number.
Nice idea. But what was primarily troubling me was the potential for the following process, which would be done and dusted before udev runs: - Boot computer with USB stick already plugged in - USB stick grabs id "/dev/sda", relegating hard drive to "/dev/sdb" - "resume=/dev/sda2" boot parameter from grub.conf kicks in - at best, second partition on USB stick doesn't contain a TuxOnIce image and system continues with a fresh boot - at worst, it's a maliciously crafted USB stick, which inserts an image into RAM that does untold nasty things to my computer - "root=/dev/sda1" boot parameter from grub.conf kicks in - at best, I get a root filesystem other than the intended one, which presumably won't contain /etc/init.d and therefore won't proceed with boot - at middling, it's a non-ext3 filesystem that won't mount and causes a kernel panic - at worst, it's a maliciously crafted USB stick etc etc... Is any of this a possibility? -- Thanks, Dan
Hi 2009/1/19 Dan Hatton <vi5u0-alug@yahoo.co.uk>:
On Mon, 19 Jan 2009, Keith Edmunds wrote:
Google for "udev rules", which are a way of giving consistent names to (typically USB) devices, although the rules are also useful for other things, such as making sure Ethernet adaptors have a consistent ethx number.
Nice idea. But what was primarily troubling me was the potential for the following process, which would be done and dusted before udev runs:
- Boot computer with USB stick already plugged in - USB stick grabs id "/dev/sda", relegating hard drive to "/dev/sdb"
I don't think this is possible. If you take a look at dmesg output, you will notice that the disk drive controllers are initialised BEFORE any USB HCI drivers are loaded.
- at worst, it's a maliciously crafted USB stick, which inserts an image into RAM that does untold nasty things to my computer
Err. You do realise that if anyone has direct physical access to your machine, they can do more damage than that? And if you are the one using the machine at the time (and not some cyber criminal), then don't boot USB pen drives that you don't know if you can trust. Srdjan
On Mon, 2009-01-19 at 22:13 +0000, Dan Hatton wrote:
Nice idea. But what was primarily troubling me was the potential for the following process, which would be done and dusted before udev runs:
- Boot computer with USB stick already plugged in - USB stick grabs id "/dev/sda", relegating hard drive to "/dev/sdb" - "resume=/dev/sda2" boot parameter from grub.conf kicks in - at best, second partition on USB stick doesn't contain a TuxOnIce image and system continues with a fresh boot - at worst, it's a maliciously crafted USB stick, which inserts an image into RAM that does untold nasty things to my computer
As Srdjan says in his reply there are always security issues when someone has access to the machine itself. If someone wanted to break in and couldn't do it there and then he could always steal the machine and attack it at leisure. If you want to me more secure about USB sticks accidentally left in I would investigate the boot order settings in the BIOS. For this reason, and to save a few seconds during boot, I usually either disable booting non-hard-disk media or set the hard disk as the first device in the boot order. On the very rare occasion I need to boot from something else I can go into the BIOS and temporarily change the settings to favour the device I want to boot from and then, when I am happy with the way the system boots from the hard disk again, change it back. If you want to make it harder for someone to sabotage the boot process you could also set a password of the BIOS settings, if you BIOS supports this. Regards, Steve.
Hi 2009/1/20 Steve Fosdick <lists@pelvoux.nildram.co.uk>:
If you want to make it harder for someone to sabotage the boot process you could also set a password of the BIOS settings, if you BIOS supports this.
This is an excellent idea, and one I've been implementing for a few years now. But be advised, that it is possible to erase the passwords (and other settings) within Linux, by calling a certain ioctl() on /dev/nvram ;) Srdjan
On Tue, 2009-01-20 at 10:34 +0000, Srdjan Todorovic wrote:
Hi
But be advised, that it is possible to erase the passwords (and other settings) within Linux, by calling a certain ioctl() on /dev/nvram ;)
Which would require root access, which means you have enough access to the box to not bother with booting it from something else :) Other tricks exist...I have a magic floppy somewhere that causes a cmos checksum error and therefore generally gives you access past the bios setup password. Toshiba's up to about '98 needed just a loopback plug on the parallel port at POST (thanks to the Toshiba engineer who left his toolkit near me once, long enough for me to meter out the pins and see what the dongle with "password reset" actually did) Thinkpads and some server kit can be *fun* most Compaqs just need the usual bios reset. Encrypted volumes and Hard drive passwords aside the only system I am aware of that makes it even sightly difficult if you have physical access is AS/400's and even then it is possible.
On Tue, Jan 20, 2009 at 02:33:57PM +0000, Wayne Stallwood wrote:
Thinkpads and some server kit can be *fun* most Compaqs just need the usual bios reset.
Most dell laptops require taking to bits, bridging a couple of pins on the motherboard and powering on for a couple of seconds, or erm, using the magick reset disc that dell supply for "engineers only" which of course means you have to be able to change the boot order. Of course being nice to a dell type person when they are repairing laptops might mean you get hold of a copy of that disc. Adam -- jabberid = quinophex@jabber.earth.li
participants (6)
-
Adam Bower -
Dan Hatton -
Keith Edmunds -
Srdjan Todorovic -
Steve Fosdick -
Wayne Stallwood