View previous topic :: View next topic |
Author |
Message |
Vandr0iy n00b
Joined: 30 May 2015 Posts: 35
|
Posted: Mon Jun 22, 2015 1:02 pm Post subject: boot issues on msata SSD |
|
|
Hi, gentoomen! I'd kindly like to ask you about a boot-related issue.
My recent gentoo installation was performed on a mSATA SSD, on my latitude e6440.
aside of an installation of win8, for gaming purposes.
fdisk -l output:
Code: |
Disk /dev/sdb: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 855C8DD5-778E-4464-87E2-DA62A779E1CE
Device Start End Sectors Size Type
/dev/sdb1 2048 264191 262144 128M Microsoft reserved # win reserved partition
/dev/sdb2 264192 122685439 122421248 58.4G Microsoft basic data # win8 partition
/dev/sdb3 122685440 123095039 409600 200M Linux filesystem # /boot/efi
/dev/sdb4 123095040 124119039 1024000 500M Linux filesystem # /boot
/dev/sdb5 124119040 164628479 40509440 19.3G Linux filesystem # /
/dev/sdb6 164628480 185599999 20971520 10G Linux filesystem # /var
/dev/sdb7 185600000 206571519 20971520 10G Linux filesystem # /opt
/dev/sdb8 206571520 500118158 293546639 140G Linux filesystem # /home
|
(I specified the mountpoints by hand, to add clarity)
The problem here is: due to the fact that probably the mSATA slot is the last to be read, this device is almost never detected as /dev/sda. Also, if there is another drive in the hdd bay, gentoo won't boot, saying that:
Code: | Block device /dev/sda5 is not a valid root device...
Could not find the root block device in .
Please specify another value, or press Enter for the same, type "shell" or "q" to skip
|
I assumed that it had something to do with the fact that there were 2 different EFI partitions, so I decided to merge them:
> I modified /etc/fstab, so it would mount /sdb1 instead of /sdb3 (by UUID), and placed all the content from /sdb3 in /sdb1 (which I had to repair, because for some reason windows corrupted it).
> This way, I backed up /sdb3 using dd and then formatted it, so it won't interfere.
And that's how the kernel panic happened, which was saying:
Code: | kernel panic - not syncing. VFS: unable to mount rootfs on (0,0) |
after that, I tried, like, almost everything: reinstalling grub, re-running grub-mkconfig, - nothing different from the precedent 2 results happened. I also had to start gentoo from grub CLI, - nothing.
I also tried to put all the files in the /dev/sdb1 and use id as the only EFI partition in the system. In fact, grub2 works now... but still kernel panics instead of booting (with or without the 2 hdd in the bay).
NOTE: I use debian's sources kernel from funtoo, so we can pretty much exclude any kernel issue. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54824 Location: 56N 3W
|
Posted: Mon Jun 22, 2015 5:47 pm Post subject: |
|
|
Vandr0iy,
Code: | VFS: unable to mount rootfs on (0,0) | tells that the kernel cannot see your hard drive at all.
The (0,0) is the kernel major and minor device IDs.
Quote: | NOTE: I use debian's sources kernel from funtoo, so we can pretty much exclude any kernel issue. |
debian sources from funtoo is a completely modular kernel that depends on an initrd to boot any hardware at all.
I suspect that your initrd is not being loaded by grub, so the kernel can't see any hardware at all, then its all down hill.
Put your grub.cfg onto a pastebin. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Vandr0iy n00b
Joined: 30 May 2015 Posts: 35
|
Posted: Mon Jun 22, 2015 6:38 pm Post subject: |
|
|
thank you for your reply,
here is the paste of my /boot/grub/grub.cfg
http://pastebin.com/9d9U6DEC |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54824 Location: 56N 3W
|
Posted: Mon Jun 22, 2015 7:09 pm Post subject: |
|
|
Vandr0iy,
Code: | echo 'Loading Linux x86_64-3.19.3-1~exp1 ...'
linux /kernel-debian-sources-x86_64-3.19.3-1~exp1 root=/dev/sdb5 ro |
There are two ways the initrd can be loaded. grub can do it, but there is no initrd line there.
It would follow immediately after the linux line, or it can be included in the kernel.
If the kernel and initrd are separate files, your boot will contain one or more initrd files. Thaty may be called initrd... or initramfs...
Have a look and see if you can find a matching one for your kernel-debian-sources-x86_64-3.19.3-1~exp1 kernel.
Make a note of its name.
If its there, add it to grub.cfg Code: | echo 'Loading Linux x86_64-3.19.3-1~exp1 ...'
linux /kernel-debian-sources-x86_64-3.19.3-1~exp1 root=/dev/sdb5 ro
initrd /<filename> |
You are not supposed to edit grub.cfg by hand but I don't use grub2 so I don't know how to do it properly.
Save grub.cfg and try it _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Vandr0iy n00b
Joined: 30 May 2015 Posts: 35
|
Posted: Wed Jun 24, 2015 1:25 am Post subject: worked!!! |
|
|
oooooh man, thank you so much!
It worked like a charm.
Now, since I had to edit a file which should remain untouched, what could I do to prevent this kind of situation? What did I do wrong?
I mean, why moving a partition by hand and regenerating grub.cfg resulted in loss of info about the initrd? It was still there, and I think that grub should have seen it...
P.S. out of curiosity, what bootloader do you use? |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|