kernel 2.6.28 only--cannot find root slice at boot

[jcc3]

I have two machines which I keep bitwise as identical as possible, an Intel P4 tower & an IBM Thinkpad T42p. Both machines are at or very near daily current, and both have large /boot slices which contain all (gen)kernels (and associated files) from 2.6.24 through 2.6.28.

Both machines run all kernels perfectly, up through 2.6.28--but with /one/ exception: the T42p Thinkpad, when running the 2.6.28 kernel, encounters at boot:

[outermeasure]

[jcc3]

Thanks for the reply. I will certainly try that, but if that works, since all other kernels boot fine using traditional device names, the indication would be that this behavior is unique to 2.6.28 (certainly possible).

With regard to js0n's post at

https://forums.gentoo.org/viewtopic-p-4588037.html#4588037

I duplicate his behavior, in that the USB bus is seen as the "zero-th" bus, before the ATA bus which contains the internal hard drive of the laptop. Once we're beyond grub, the internal drive appears on the "first" bus, as /dev/hda, not as /dev/sdb.

I also hack both OpenSolaris and FreeBSD on other, model-identical copies of this Maxtor external usb disk device, and in Solaris for example, the USB external disk is seen as

/dev/dsk/c0t0d0

while the internal hard disk is

/dev/dsk/c1d0

The appearance of the 't0' (target 0) is the first case tells us that Solaris is also using a SCSI hardware abstraction to see the external USB drive, but not for the internal drive, c1d0 (the 'c1' indicating bus 1). And this is consistent with my Gentoo observations above.

And yes I do agree that 'slices' is not Linux terminology. There turns out to be a gnarly confusion in the literature, where some authors use 'partition' to mean (in x86 at least) one of the classical four MBR table entries, while others use 'slice' for /that/, and 'partition' for a subdivision of an MBR chunk! It appears that the mixup started with the first porting of Solaris to x86, since SPARC boxes had no exact counterpart of the Intel MBR, and things went downhill from there.

I'll try the UUID approach tomorrow--thanks for the suggestion.

[lugo]

i have exactly the same problem, with the exception that my "invalid" root-sector is on an interal drive
/dev/hda1;
also had no luck with uuid.. :/

edit: a weird behaviour is that, 2.6.27 took about an hour to compile with my configuration; and 2.6.28 compiled successfully, as in without errors, in under 15min with a comparable config...as if it's skipping to build some modules

[jcc3]

For lugo, if you reply to the "root block device" prompt (when the error occurs) with the /same/ device that it complained about (which is presumably the actual root partition), does the boot then resume and come up the rest of the way successfully?

That works for me, and since this is an easy circumvention, the severity of this problem is pretty much reduced to an annoyance, unless you need to be able to boot the machine "unattended."

BTW, keep in mind that we are talking about the root partition here (in Gentoo, normally 2), not the boot partition (1).

[NeddySeagoon]

Guys,

Please post your

[jcc3]

Neddy,

Thanks for the input. I apologize if this thread becomes long--on the scale of OS engineering problems, I would put this at around 0.5 out of 10. I'm confident the solution is straightforward; the fault is probably mine, and the problem is easily circumventable anyway. As someone who has had the misfortune of having a colleague walk into my office at 8pm on a Friday and announce that the university biweekly payroll just cored, and it's up to me to save it before it has to get transmitted to the bank in three hours so that the hourly people can buy formula for their babies, this is not so bad.

As far as libata, libata.ko is built on all kernels on the affected machine; it is indeed in the respective /lib/modules/<version>/... These kernels are 2.6.24-r4, 2.6.24-r5, 2.6.25-r8 2.6.26-r2, 2.6.27-r2, 2.6.27-r7, and 2.6.28, all in /boot, along with their corresponding files appropriately versioned in their file names, thus putting 57 or so files in /boot. All are built via genkernel using default generated .config's, and installed via genkernel --install.

I do not treat 2.6.28 any differently than any of the of other kernels, but this problem only occurs on .28. All kernels have a grub entry in the legacy canonical form

[NeddySeagoon]

jcc3,

I did the old manual method and it JustWorked(tm)

That was copy the .config file,
run make oldconfig in the new kernel
make
make modules_install
mount /boot
cp arch/x86/boot/bzImage /boot/<nice_name>
Add boot stanz to grub
Reboot
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[jburns]

From /usr/src/linux/Documentation/kernel-parameters.txt. You could try adding the rootdelay= or rootwait parameter to the kernel line in grub.conf.

[NeddySeagoon]

jcc3,

Please post the output of lspci and your 2.6.28 kernel .config file
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[jcc3]

Neddy,

Ok, will do a bit later (I'm not at the systems at the moment). But it hits me that I failed to stress that 2.6.28, as configured in my previous post, exhibits this problem ONLY on the Thinkpad, with its external USB disk. Essentially this identical setup of 2.6.28, /does/ JustWork 100% on an older Intel P4 (Socket 478) tower with the usual 4 ATA internal drives.

The weather vane of suspicion creaks around to point to 2.6.28 and the Thinkpad's USB!

ALL kernels /prior/ to 2.6.28 JustWork everywhere, including the Thinkpad.

[waw]

Hello,

I have the same problem on my ASUS F9S laptop using gentoo kernel 2.6.24-r5 on an external usb drive.
https://forums.gentoo.org/viewtopic-t-695553.html

Regards

[arjay]

[arjay]

it's working! I am now able to boot 2.6.29 on my T42p without any problems after the bios update. I also changed the order of boot in bios however, so I'm not sure which was creating the problem. I changed it back to the internal HD before any external HD when I was making sure that the bios update was correct. Anyhow, if anyone has the same problem:

1. Check your boot order. If you are using an external USB HD, make sure it falls AFTER the internal HD. If that doesn't help;

2. Check for a bios update. If available, update it.

Worked for me.