Kernel Panic - not syncing: VFS: Unable to mount root fs - LFS
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I have created a LFS (linux from scratch). All the files is on a secondary hdd. ie. /dev/sdb There is no partition in that like sdb1 or sdb2. Both root and boot is in the same /dev/sdb . My host system is linux mint installed on /dev/sda. Grub is installed on /dev/sda as well. I followed a tutorial online, but that messed up my partitioning. Is there any possible solution? I have already tried changing grub config by tweaking hd0 to hd1 and all other possible partitions. Without losing anything can i make new partition and move everything according using another live disk? Or any better solution?
linux grub2 lfs partition-table
asked Feb 8 at 9:44
Susmith
437
add a comment |Â
up vote
1
down vote
favorite
I have created a LFS (linux from scratch). All the files is on a secondary hdd. ie. /dev/sdb There is no partition in that like sdb1 or sdb2. Both root and boot is in the same /dev/sdb . My host system is linux mint installed on /dev/sda. Grub is installed on /dev/sda as well. I followed a tutorial online, but that messed up my partitioning. Is there any possible solution? I have already tried changing grub config by tweaking hd0 to hd1 and all other possible partitions. Without losing anything can i make new partition and move everything according using another live disk? Or any better solution?
linux grub2 lfs partition-table
asked Feb 8 at 9:44
Susmith
437
1
Which tutorial did you follow? What exactly makes you think you "messed up your partitioning", as opposed to e.g. specifying an incorrectroot=boot option for the kernel or forgetting to include the correct filesystem driver in your kernel or initramfs? (All these things can cause the panic message in your question title.) Does your system use UEFI or a traditional BIOS? Was your /dev/sda disk partitioned using GPT or traditional MBR? Without any solid facts it's hard to offer any advice.
– telcoM
Feb 8 at 11:56
I said i messed up partition because. Disk /dev/sdb doesn't contain any partitions. It's written directly. Im using virtual machine (so its traditional bios). Followed this tutorial youtu.be/8WsDcW5SQ9Y see at 6:24
– Susmith
Feb 8 at 12:02
From your original question I assumed you meant you had directly made a filesystem on the disk /dev/sdb without making any partitions (i.e. a so-called "superfloppy" configuration) intentionally. So I could not see which part of your description was about the original state and which was about the damage done. First step would be to use testdisk to see if the old partition table could be reconstructed. I don't have time to view the video tutorial right now, more later.
– telcoM
Feb 8 at 12:10
Ohkay, thanks for the help. How to setup grub in "superfloppy" configuration ie. Where to install it. Installing on /dev/sdb failed. Any useful link will help.
– Susmith
Feb 8 at 12:13
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have created a LFS (linux from scratch). All the files is on a secondary hdd. ie. /dev/sdb There is no partition in that like sdb1 or sdb2. Both root and boot is in the same /dev/sdb . My host system is linux mint installed on /dev/sda. Grub is installed on /dev/sda as well. I followed a tutorial online, but that messed up my partitioning. Is there any possible solution? I have already tried changing grub config by tweaking hd0 to hd1 and all other possible partitions. Without losing anything can i make new partition and move everything according using another live disk? Or any better solution?
linux grub2 lfs partition-table
asked Feb 8 at 9:44
Susmith
437
I have created a LFS (linux from scratch). All the files is on a secondary hdd. ie. /dev/sdb There is no partition in that like sdb1 or sdb2. Both root and boot is in the same /dev/sdb . My host system is linux mint installed on /dev/sda. Grub is installed on /dev/sda as well. I followed a tutorial online, but that messed up my partitioning. Is there any possible solution? I have already tried changing grub config by tweaking hd0 to hd1 and all other possible partitions. Without losing anything can i make new partition and move everything according using another live disk? Or any better solution?
linux grub2 lfs partition-table
asked Feb 8 at 9:44
Susmith
437
asked Feb 8 at 9:44
Susmith
437
asked Feb 8 at 9:44
Susmith
437
asked Feb 8 at 9:44
Susmith
437
437
1
Which tutorial did you follow? What exactly makes you think you "messed up your partitioning", as opposed to e.g. specifying an incorrectroot=boot option for the kernel or forgetting to include the correct filesystem driver in your kernel or initramfs? (All these things can cause the panic message in your question title.) Does your system use UEFI or a traditional BIOS? Was your /dev/sda disk partitioned using GPT or traditional MBR? Without any solid facts it's hard to offer any advice.
– telcoM
Feb 8 at 11:56
I said i messed up partition because. Disk /dev/sdb doesn't contain any partitions. It's written directly. Im using virtual machine (so its traditional bios). Followed this tutorial youtu.be/8WsDcW5SQ9Y see at 6:24
– Susmith
Feb 8 at 12:02
From your original question I assumed you meant you had directly made a filesystem on the disk /dev/sdb without making any partitions (i.e. a so-called "superfloppy" configuration) intentionally. So I could not see which part of your description was about the original state and which was about the damage done. First step would be to use testdisk to see if the old partition table could be reconstructed. I don't have time to view the video tutorial right now, more later.
– telcoM
Feb 8 at 12:10
Ohkay, thanks for the help. How to setup grub in "superfloppy" configuration ie. Where to install it. Installing on /dev/sdb failed. Any useful link will help.
– Susmith
Feb 8 at 12:13
add a comment |Â
1
Which tutorial did you follow? What exactly makes you think you "messed up your partitioning", as opposed to e.g. specifying an incorrectroot=boot option for the kernel or forgetting to include the correct filesystem driver in your kernel or initramfs? (All these things can cause the panic message in your question title.) Does your system use UEFI or a traditional BIOS? Was your /dev/sda disk partitioned using GPT or traditional MBR? Without any solid facts it's hard to offer any advice.
– telcoM
Feb 8 at 11:56
I said i messed up partition because. Disk /dev/sdb doesn't contain any partitions. It's written directly. Im using virtual machine (so its traditional bios). Followed this tutorial youtu.be/8WsDcW5SQ9Y see at 6:24
– Susmith
Feb 8 at 12:02
From your original question I assumed you meant you had directly made a filesystem on the disk /dev/sdb without making any partitions (i.e. a so-called "superfloppy" configuration) intentionally. So I could not see which part of your description was about the original state and which was about the damage done. First step would be to use testdisk to see if the old partition table could be reconstructed. I don't have time to view the video tutorial right now, more later.
– telcoM
Feb 8 at 12:10
Ohkay, thanks for the help. How to setup grub in "superfloppy" configuration ie. Where to install it. Installing on /dev/sdb failed. Any useful link will help.
– Susmith
Feb 8 at 12:13
1
1
Which tutorial did you follow? What exactly makes you think you "messed up your partitioning", as opposed to e.g. specifying an incorrect
root= boot option for the kernel or forgetting to include the correct filesystem driver in your kernel or initramfs? (All these things can cause the panic message in your question title.) Does your system use UEFI or a traditional BIOS? Was your /dev/sda disk partitioned using GPT or traditional MBR? Without any solid facts it's hard to offer any advice.– telcoM
Feb 8 at 11:56
Which tutorial did you follow? What exactly makes you think you "messed up your partitioning", as opposed to e.g. specifying an incorrect
root= boot option for the kernel or forgetting to include the correct filesystem driver in your kernel or initramfs? (All these things can cause the panic message in your question title.) Does your system use UEFI or a traditional BIOS? Was your /dev/sda disk partitioned using GPT or traditional MBR? Without any solid facts it's hard to offer any advice.– telcoM
Feb 8 at 11:56
I said i messed up partition because. Disk /dev/sdb doesn't contain any partitions. It's written directly. Im using virtual machine (so its traditional bios). Followed this tutorial youtu.be/8WsDcW5SQ9Y see at 6:24
– Susmith
Feb 8 at 12:02
I said i messed up partition because. Disk /dev/sdb doesn't contain any partitions. It's written directly. Im using virtual machine (so its traditional bios). Followed this tutorial youtu.be/8WsDcW5SQ9Y see at 6:24
– Susmith
Feb 8 at 12:02
From your original question I assumed you meant you had directly made a filesystem on the disk /dev/sdb without making any partitions (i.e. a so-called "superfloppy" configuration) intentionally. So I could not see which part of your description was about the original state and which was about the damage done. First step would be to use testdisk to see if the old partition table could be reconstructed. I don't have time to view the video tutorial right now, more later.
– telcoM
Feb 8 at 12:10
From your original question I assumed you meant you had directly made a filesystem on the disk /dev/sdb without making any partitions (i.e. a so-called "superfloppy" configuration) intentionally. So I could not see which part of your description was about the original state and which was about the damage done. First step would be to use testdisk to see if the old partition table could be reconstructed. I don't have time to view the video tutorial right now, more later.
– telcoM
Feb 8 at 12:10
Ohkay, thanks for the help. How to setup grub in "superfloppy" configuration ie. Where to install it. Installing on /dev/sdb failed. Any useful link will help.
– Susmith
Feb 8 at 12:13
Ohkay, thanks for the help. How to setup grub in "superfloppy" configuration ie. Where to install it. Installing on /dev/sdb failed. Any useful link will help.
– Susmith
Feb 8 at 12:13
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
If you followed that tutorial exactly, then you've now overwritten the bootloader on /dev/sda with the new bootloader of your LFS installation.
The partitioning on /dev/sda should be fine: if you want to restore the Mint installation, you'll just need to boot the system from some live-Linux ISO, mount the root and /boot filesystems from /dev/sda*, chroot to the Mint installation and run grub-install /dev/sda. Since the GRUB configuration files of the Mint installation are untouched, that should be enough to restore the Mint installation to full working order.
The new bootloader attempts to load the OS kernel from /dev/sdband is actually successful at that: the Kernel Panic message is coming from the kernel of the LFS installation, not the bootloader.
(The bootloader installation is described in Chapter 11 of the video tutorial at time 15:30 onwards.)
At Chapter 11 time 16:12 the tutorial talks about creating /boot/grub/grub.cfg, and there is a line:
linux /boot/vmlinuz-4.7.2-lfs-7.10 root=<something> ro
In your case, the <something> should be /dev/sdb. If you got this wrong, this could have caused the error. At Chapter 11 time 18:20 the tutorial discusses about how to fix that: when you see the GRUB boot menu, press e to edit the boot options at boot time. You'll see the same line mentioned above and can make temporary changes to make your LFS installation boot.
Another possible error is not having the driver for your root filesystem compiled in to your LFS kernel: this would be specified in the kernel configuration phase in Chapter 11 time 14:32, but the tutorial pretty much glosses over it.
In other words, in the kernel configuration menus, in the File systems sub-menu, the line The Extended 4 (ext4) filesystem should be selected as Y (represented as an asterisk), not as M. If you missed this step, then having the root=/dev/sdb correct on the boot options line won't help: in that case, your best option would be to recover the Mint installation, use it to reconfigure & recompile your LFS kernel, and then place the recompiled vmlinuz-4.7.2-lfs-7.10 file to the /boot directory on /dev/sdb, and finally reinstall the LFS's GRUB.
Having said that, in my opinion the tutorial made a fundamental mistake of not partitioning /dev/sdb in the beginning. Instead they used the whole disk for a single filesystem (mkfs /dev/sdb = the "superfloppy" configuration). That makes it impossible to install GRUB2 on /dev/sdb: GRUB2 needs a few disk blocks after the MBR, which are normally unused on a partitioned disk, but would overwrite the beginning of the filesystem on a "superfloppy". As a result, they're forced to install the bootloader on /dev/sda instead, breaking the Mint host installation in the process.
The minimal changes I would have done:
- make
/dev/sdba single big partition (/dev/sdb1) and create a filesystem on it - do everything else using
/dev/sdb1instead of/dev/sdbexcept thegrub-installcommand: that would begrub-install /dev/sdb. - in
/boot/grub/grub.cfgof the LFS, the GRUB root device should then be specified asset root=(hd0,1)and the Linux root filesystem boot option should beroot=/dev/sdb1. This is because of a quirk of BIOS: whichever disk you select to boot from at the BIOS level will normally be(hd0)for GRUB, even if it is/dev/sdbfor Linux.
With these changes, you would avoid breaking the bootloader of the Mint installation, and should be able to use VirtualBox's boot menu to select which installation you boot from: either Mint or your LFS. It should also allow you to completely remove the /dev/sda from the configuration (making /dev/sdb the new /dev/sda) with just changes to /boot/grub/grub.conf of the LFS, to prove that the new LFS installation is completely capable of stand-alone operation.
How to salvage your current situation?
I would first work on recovering the Mint bootloader on /dev/sda using a live-Linux ISO. Once that is fixed, I would boot to Mint, mount /dev/sdb and pack up everything on it into a tar.bz2 package:
mount /dev/sdb /mnt
cd /mnt
tar jcvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2 *
cd /
umount /mnt
Then I would partition /dev/sdb, create an ext4 filesystem on /dev/sdb1, mount it and restore everything that was on /dev/sdb onto it:
fdisk /dev/sdb
<set up one partition to cover the whole disk>
mkfs -v -t ext4 /dev/sdb1
mount /dev/sdb1 /mnt
cd /mnt
tar xvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2
The next steps would be the necessary preparations and chrooting into the LFS environment, much like Chapter 6 2:40-4:05 of the tutorial but now the directories should already be there. Then the bootloader can be installed to /dev/sdb, as described earlier.
answered Feb 9 at 9:15
telcoM
10.7k11132
Thanks a lot, brother.i think, driver for root filesystem is not included during linux kernel compilation. after getting back to linux mint host system i need to chroot to LFS and recompile it. should i delete the previously installed linux kernel? if yes then how ? or all have to do is make and make install ?
– Susmith
Feb 9 at 13:46
1
The compilation process will automatically overwrite an older version of the kernel, so you don't need to delete it.
– telcoM
Feb 9 at 13:51
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
If you followed that tutorial exactly, then you've now overwritten the bootloader on /dev/sda with the new bootloader of your LFS installation.
The partitioning on /dev/sda should be fine: if you want to restore the Mint installation, you'll just need to boot the system from some live-Linux ISO, mount the root and /boot filesystems from /dev/sda*, chroot to the Mint installation and run grub-install /dev/sda. Since the GRUB configuration files of the Mint installation are untouched, that should be enough to restore the Mint installation to full working order.
The new bootloader attempts to load the OS kernel from /dev/sdband is actually successful at that: the Kernel Panic message is coming from the kernel of the LFS installation, not the bootloader.
(The bootloader installation is described in Chapter 11 of the video tutorial at time 15:30 onwards.)
At Chapter 11 time 16:12 the tutorial talks about creating /boot/grub/grub.cfg, and there is a line:
linux /boot/vmlinuz-4.7.2-lfs-7.10 root=<something> ro
In your case, the <something> should be /dev/sdb. If you got this wrong, this could have caused the error. At Chapter 11 time 18:20 the tutorial discusses about how to fix that: when you see the GRUB boot menu, press e to edit the boot options at boot time. You'll see the same line mentioned above and can make temporary changes to make your LFS installation boot.
Another possible error is not having the driver for your root filesystem compiled in to your LFS kernel: this would be specified in the kernel configuration phase in Chapter 11 time 14:32, but the tutorial pretty much glosses over it.
In other words, in the kernel configuration menus, in the File systems sub-menu, the line The Extended 4 (ext4) filesystem should be selected as Y (represented as an asterisk), not as M. If you missed this step, then having the root=/dev/sdb correct on the boot options line won't help: in that case, your best option would be to recover the Mint installation, use it to reconfigure & recompile your LFS kernel, and then place the recompiled vmlinuz-4.7.2-lfs-7.10 file to the /boot directory on /dev/sdb, and finally reinstall the LFS's GRUB.
Having said that, in my opinion the tutorial made a fundamental mistake of not partitioning /dev/sdb in the beginning. Instead they used the whole disk for a single filesystem (mkfs /dev/sdb = the "superfloppy" configuration). That makes it impossible to install GRUB2 on /dev/sdb: GRUB2 needs a few disk blocks after the MBR, which are normally unused on a partitioned disk, but would overwrite the beginning of the filesystem on a "superfloppy". As a result, they're forced to install the bootloader on /dev/sda instead, breaking the Mint host installation in the process.
The minimal changes I would have done:
- make
/dev/sdba single big partition (/dev/sdb1) and create a filesystem on it - do everything else using
/dev/sdb1instead of/dev/sdbexcept thegrub-installcommand: that would begrub-install /dev/sdb. - in
/boot/grub/grub.cfgof the LFS, the GRUB root device should then be specified asset root=(hd0,1)and the Linux root filesystem boot option should beroot=/dev/sdb1. This is because of a quirk of BIOS: whichever disk you select to boot from at the BIOS level will normally be(hd0)for GRUB, even if it is/dev/sdbfor Linux.
With these changes, you would avoid breaking the bootloader of the Mint installation, and should be able to use VirtualBox's boot menu to select which installation you boot from: either Mint or your LFS. It should also allow you to completely remove the /dev/sda from the configuration (making /dev/sdb the new /dev/sda) with just changes to /boot/grub/grub.conf of the LFS, to prove that the new LFS installation is completely capable of stand-alone operation.
How to salvage your current situation?
I would first work on recovering the Mint bootloader on /dev/sda using a live-Linux ISO. Once that is fixed, I would boot to Mint, mount /dev/sdb and pack up everything on it into a tar.bz2 package:
mount /dev/sdb /mnt
cd /mnt
tar jcvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2 *
cd /
umount /mnt
Then I would partition /dev/sdb, create an ext4 filesystem on /dev/sdb1, mount it and restore everything that was on /dev/sdb onto it:
fdisk /dev/sdb
<set up one partition to cover the whole disk>
mkfs -v -t ext4 /dev/sdb1
mount /dev/sdb1 /mnt
cd /mnt
tar xvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2
The next steps would be the necessary preparations and chrooting into the LFS environment, much like Chapter 6 2:40-4:05 of the tutorial but now the directories should already be there. Then the bootloader can be installed to /dev/sdb, as described earlier.
answered Feb 9 at 9:15
telcoM
10.7k11132
Thanks a lot, brother.i think, driver for root filesystem is not included during linux kernel compilation. after getting back to linux mint host system i need to chroot to LFS and recompile it. should i delete the previously installed linux kernel? if yes then how ? or all have to do is make and make install ?
– Susmith
Feb 9 at 13:46
1
The compilation process will automatically overwrite an older version of the kernel, so you don't need to delete it.
– telcoM
Feb 9 at 13:51
add a comment |Â
up vote
1
down vote
accepted
If you followed that tutorial exactly, then you've now overwritten the bootloader on /dev/sda with the new bootloader of your LFS installation.
The partitioning on /dev/sda should be fine: if you want to restore the Mint installation, you'll just need to boot the system from some live-Linux ISO, mount the root and /boot filesystems from /dev/sda*, chroot to the Mint installation and run grub-install /dev/sda. Since the GRUB configuration files of the Mint installation are untouched, that should be enough to restore the Mint installation to full working order.
The new bootloader attempts to load the OS kernel from /dev/sdband is actually successful at that: the Kernel Panic message is coming from the kernel of the LFS installation, not the bootloader.
(The bootloader installation is described in Chapter 11 of the video tutorial at time 15:30 onwards.)
At Chapter 11 time 16:12 the tutorial talks about creating /boot/grub/grub.cfg, and there is a line:
linux /boot/vmlinuz-4.7.2-lfs-7.10 root=<something> ro
In your case, the <something> should be /dev/sdb. If you got this wrong, this could have caused the error. At Chapter 11 time 18:20 the tutorial discusses about how to fix that: when you see the GRUB boot menu, press e to edit the boot options at boot time. You'll see the same line mentioned above and can make temporary changes to make your LFS installation boot.
Another possible error is not having the driver for your root filesystem compiled in to your LFS kernel: this would be specified in the kernel configuration phase in Chapter 11 time 14:32, but the tutorial pretty much glosses over it.
In other words, in the kernel configuration menus, in the File systems sub-menu, the line The Extended 4 (ext4) filesystem should be selected as Y (represented as an asterisk), not as M. If you missed this step, then having the root=/dev/sdb correct on the boot options line won't help: in that case, your best option would be to recover the Mint installation, use it to reconfigure & recompile your LFS kernel, and then place the recompiled vmlinuz-4.7.2-lfs-7.10 file to the /boot directory on /dev/sdb, and finally reinstall the LFS's GRUB.
Having said that, in my opinion the tutorial made a fundamental mistake of not partitioning /dev/sdb in the beginning. Instead they used the whole disk for a single filesystem (mkfs /dev/sdb = the "superfloppy" configuration). That makes it impossible to install GRUB2 on /dev/sdb: GRUB2 needs a few disk blocks after the MBR, which are normally unused on a partitioned disk, but would overwrite the beginning of the filesystem on a "superfloppy". As a result, they're forced to install the bootloader on /dev/sda instead, breaking the Mint host installation in the process.
The minimal changes I would have done:
- make
/dev/sdba single big partition (/dev/sdb1) and create a filesystem on it - do everything else using
/dev/sdb1instead of/dev/sdbexcept thegrub-installcommand: that would begrub-install /dev/sdb. - in
/boot/grub/grub.cfgof the LFS, the GRUB root device should then be specified asset root=(hd0,1)and the Linux root filesystem boot option should beroot=/dev/sdb1. This is because of a quirk of BIOS: whichever disk you select to boot from at the BIOS level will normally be(hd0)for GRUB, even if it is/dev/sdbfor Linux.
With these changes, you would avoid breaking the bootloader of the Mint installation, and should be able to use VirtualBox's boot menu to select which installation you boot from: either Mint or your LFS. It should also allow you to completely remove the /dev/sda from the configuration (making /dev/sdb the new /dev/sda) with just changes to /boot/grub/grub.conf of the LFS, to prove that the new LFS installation is completely capable of stand-alone operation.
How to salvage your current situation?
I would first work on recovering the Mint bootloader on /dev/sda using a live-Linux ISO. Once that is fixed, I would boot to Mint, mount /dev/sdb and pack up everything on it into a tar.bz2 package:
mount /dev/sdb /mnt
cd /mnt
tar jcvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2 *
cd /
umount /mnt
Then I would partition /dev/sdb, create an ext4 filesystem on /dev/sdb1, mount it and restore everything that was on /dev/sdb onto it:
fdisk /dev/sdb
<set up one partition to cover the whole disk>
mkfs -v -t ext4 /dev/sdb1
mount /dev/sdb1 /mnt
cd /mnt
tar xvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2
The next steps would be the necessary preparations and chrooting into the LFS environment, much like Chapter 6 2:40-4:05 of the tutorial but now the directories should already be there. Then the bootloader can be installed to /dev/sdb, as described earlier.
answered Feb 9 at 9:15
telcoM
10.7k11132
Thanks a lot, brother.i think, driver for root filesystem is not included during linux kernel compilation. after getting back to linux mint host system i need to chroot to LFS and recompile it. should i delete the previously installed linux kernel? if yes then how ? or all have to do is make and make install ?
– Susmith
Feb 9 at 13:46
1
The compilation process will automatically overwrite an older version of the kernel, so you don't need to delete it.
– telcoM
Feb 9 at 13:51
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
If you followed that tutorial exactly, then you've now overwritten the bootloader on /dev/sda with the new bootloader of your LFS installation.
The partitioning on /dev/sda should be fine: if you want to restore the Mint installation, you'll just need to boot the system from some live-Linux ISO, mount the root and /boot filesystems from /dev/sda*, chroot to the Mint installation and run grub-install /dev/sda. Since the GRUB configuration files of the Mint installation are untouched, that should be enough to restore the Mint installation to full working order.
The new bootloader attempts to load the OS kernel from /dev/sdband is actually successful at that: the Kernel Panic message is coming from the kernel of the LFS installation, not the bootloader.
(The bootloader installation is described in Chapter 11 of the video tutorial at time 15:30 onwards.)
At Chapter 11 time 16:12 the tutorial talks about creating /boot/grub/grub.cfg, and there is a line:
linux /boot/vmlinuz-4.7.2-lfs-7.10 root=<something> ro
In your case, the <something> should be /dev/sdb. If you got this wrong, this could have caused the error. At Chapter 11 time 18:20 the tutorial discusses about how to fix that: when you see the GRUB boot menu, press e to edit the boot options at boot time. You'll see the same line mentioned above and can make temporary changes to make your LFS installation boot.
Another possible error is not having the driver for your root filesystem compiled in to your LFS kernel: this would be specified in the kernel configuration phase in Chapter 11 time 14:32, but the tutorial pretty much glosses over it.
In other words, in the kernel configuration menus, in the File systems sub-menu, the line The Extended 4 (ext4) filesystem should be selected as Y (represented as an asterisk), not as M. If you missed this step, then having the root=/dev/sdb correct on the boot options line won't help: in that case, your best option would be to recover the Mint installation, use it to reconfigure & recompile your LFS kernel, and then place the recompiled vmlinuz-4.7.2-lfs-7.10 file to the /boot directory on /dev/sdb, and finally reinstall the LFS's GRUB.
Having said that, in my opinion the tutorial made a fundamental mistake of not partitioning /dev/sdb in the beginning. Instead they used the whole disk for a single filesystem (mkfs /dev/sdb = the "superfloppy" configuration). That makes it impossible to install GRUB2 on /dev/sdb: GRUB2 needs a few disk blocks after the MBR, which are normally unused on a partitioned disk, but would overwrite the beginning of the filesystem on a "superfloppy". As a result, they're forced to install the bootloader on /dev/sda instead, breaking the Mint host installation in the process.
The minimal changes I would have done:
- make
/dev/sdba single big partition (/dev/sdb1) and create a filesystem on it - do everything else using
/dev/sdb1instead of/dev/sdbexcept thegrub-installcommand: that would begrub-install /dev/sdb. - in
/boot/grub/grub.cfgof the LFS, the GRUB root device should then be specified asset root=(hd0,1)and the Linux root filesystem boot option should beroot=/dev/sdb1. This is because of a quirk of BIOS: whichever disk you select to boot from at the BIOS level will normally be(hd0)for GRUB, even if it is/dev/sdbfor Linux.
With these changes, you would avoid breaking the bootloader of the Mint installation, and should be able to use VirtualBox's boot menu to select which installation you boot from: either Mint or your LFS. It should also allow you to completely remove the /dev/sda from the configuration (making /dev/sdb the new /dev/sda) with just changes to /boot/grub/grub.conf of the LFS, to prove that the new LFS installation is completely capable of stand-alone operation.
How to salvage your current situation?
I would first work on recovering the Mint bootloader on /dev/sda using a live-Linux ISO. Once that is fixed, I would boot to Mint, mount /dev/sdb and pack up everything on it into a tar.bz2 package:
mount /dev/sdb /mnt
cd /mnt
tar jcvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2 *
cd /
umount /mnt
Then I would partition /dev/sdb, create an ext4 filesystem on /dev/sdb1, mount it and restore everything that was on /dev/sdb onto it:
fdisk /dev/sdb
<set up one partition to cover the whole disk>
mkfs -v -t ext4 /dev/sdb1
mount /dev/sdb1 /mnt
cd /mnt
tar xvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2
The next steps would be the necessary preparations and chrooting into the LFS environment, much like Chapter 6 2:40-4:05 of the tutorial but now the directories should already be there. Then the bootloader can be installed to /dev/sdb, as described earlier.
answered Feb 9 at 9:15
telcoM
10.7k11132
If you followed that tutorial exactly, then you've now overwritten the bootloader on /dev/sda with the new bootloader of your LFS installation.
The partitioning on /dev/sda should be fine: if you want to restore the Mint installation, you'll just need to boot the system from some live-Linux ISO, mount the root and /boot filesystems from /dev/sda*, chroot to the Mint installation and run grub-install /dev/sda. Since the GRUB configuration files of the Mint installation are untouched, that should be enough to restore the Mint installation to full working order.
The new bootloader attempts to load the OS kernel from /dev/sdband is actually successful at that: the Kernel Panic message is coming from the kernel of the LFS installation, not the bootloader.
(The bootloader installation is described in Chapter 11 of the video tutorial at time 15:30 onwards.)
At Chapter 11 time 16:12 the tutorial talks about creating /boot/grub/grub.cfg, and there is a line:
linux /boot/vmlinuz-4.7.2-lfs-7.10 root=<something> ro
In your case, the <something> should be /dev/sdb. If you got this wrong, this could have caused the error. At Chapter 11 time 18:20 the tutorial discusses about how to fix that: when you see the GRUB boot menu, press e to edit the boot options at boot time. You'll see the same line mentioned above and can make temporary changes to make your LFS installation boot.
Another possible error is not having the driver for your root filesystem compiled in to your LFS kernel: this would be specified in the kernel configuration phase in Chapter 11 time 14:32, but the tutorial pretty much glosses over it.
In other words, in the kernel configuration menus, in the File systems sub-menu, the line The Extended 4 (ext4) filesystem should be selected as Y (represented as an asterisk), not as M. If you missed this step, then having the root=/dev/sdb correct on the boot options line won't help: in that case, your best option would be to recover the Mint installation, use it to reconfigure & recompile your LFS kernel, and then place the recompiled vmlinuz-4.7.2-lfs-7.10 file to the /boot directory on /dev/sdb, and finally reinstall the LFS's GRUB.
Having said that, in my opinion the tutorial made a fundamental mistake of not partitioning /dev/sdb in the beginning. Instead they used the whole disk for a single filesystem (mkfs /dev/sdb = the "superfloppy" configuration). That makes it impossible to install GRUB2 on /dev/sdb: GRUB2 needs a few disk blocks after the MBR, which are normally unused on a partitioned disk, but would overwrite the beginning of the filesystem on a "superfloppy". As a result, they're forced to install the bootloader on /dev/sda instead, breaking the Mint host installation in the process.
The minimal changes I would have done:
- make
/dev/sdba single big partition (/dev/sdb1) and create a filesystem on it - do everything else using
/dev/sdb1instead of/dev/sdbexcept thegrub-installcommand: that would begrub-install /dev/sdb. - in
/boot/grub/grub.cfgof the LFS, the GRUB root device should then be specified asset root=(hd0,1)and the Linux root filesystem boot option should beroot=/dev/sdb1. This is because of a quirk of BIOS: whichever disk you select to boot from at the BIOS level will normally be(hd0)for GRUB, even if it is/dev/sdbfor Linux.
With these changes, you would avoid breaking the bootloader of the Mint installation, and should be able to use VirtualBox's boot menu to select which installation you boot from: either Mint or your LFS. It should also allow you to completely remove the /dev/sda from the configuration (making /dev/sdb the new /dev/sda) with just changes to /boot/grub/grub.conf of the LFS, to prove that the new LFS installation is completely capable of stand-alone operation.
How to salvage your current situation?
I would first work on recovering the Mint bootloader on /dev/sda using a live-Linux ISO. Once that is fixed, I would boot to Mint, mount /dev/sdb and pack up everything on it into a tar.bz2 package:
mount /dev/sdb /mnt
cd /mnt
tar jcvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2 *
cd /
umount /mnt
Then I would partition /dev/sdb, create an ext4 filesystem on /dev/sdb1, mount it and restore everything that was on /dev/sdb onto it:
fdisk /dev/sdb
<set up one partition to cover the whole disk>
mkfs -v -t ext4 /dev/sdb1
mount /dev/sdb1 /mnt
cd /mnt
tar xvf /somewhere/with/plenty/of/space/LFS-recovery.tar.bz2
The next steps would be the necessary preparations and chrooting into the LFS environment, much like Chapter 6 2:40-4:05 of the tutorial but now the directories should already be there. Then the bootloader can be installed to /dev/sdb, as described earlier.
answered Feb 9 at 9:15
telcoM
10.7k11132
answered Feb 9 at 9:15
telcoM
10.7k11132
answered Feb 9 at 9:15
telcoM
10.7k11132
answered Feb 9 at 9:15
telcoM
10.7k11132
10.7k11132
Thanks a lot, brother.i think, driver for root filesystem is not included during linux kernel compilation. after getting back to linux mint host system i need to chroot to LFS and recompile it. should i delete the previously installed linux kernel? if yes then how ? or all have to do is make and make install ?
– Susmith
Feb 9 at 13:46
1
The compilation process will automatically overwrite an older version of the kernel, so you don't need to delete it.
– telcoM
Feb 9 at 13:51
add a comment |Â
Thanks a lot, brother.i think, driver for root filesystem is not included during linux kernel compilation. after getting back to linux mint host system i need to chroot to LFS and recompile it. should i delete the previously installed linux kernel? if yes then how ? or all have to do is make and make install ?
– Susmith
Feb 9 at 13:46
1
The compilation process will automatically overwrite an older version of the kernel, so you don't need to delete it.
– telcoM
Feb 9 at 13:51
Thanks a lot, brother.i think, driver for root filesystem is not included during linux kernel compilation. after getting back to linux mint host system i need to chroot to LFS and recompile it. should i delete the previously installed linux kernel? if yes then how ? or all have to do is make and make install ?
– Susmith
Feb 9 at 13:46
Thanks a lot, brother.i think, driver for root filesystem is not included during linux kernel compilation. after getting back to linux mint host system i need to chroot to LFS and recompile it. should i delete the previously installed linux kernel? if yes then how ? or all have to do is make and make install ?
– Susmith
Feb 9 at 13:46
1
1
The compilation process will automatically overwrite an older version of the kernel, so you don't need to delete it.
– telcoM
Feb 9 at 13:51
The compilation process will automatically overwrite an older version of the kernel, so you don't need to delete it.
– telcoM
Feb 9 at 13:51
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f422757%2fkernel-panic-not-syncing-vfs-unable-to-mount-root-fs-lfs%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Which tutorial did you follow? What exactly makes you think you "messed up your partitioning", as opposed to e.g. specifying an incorrect
root=boot option for the kernel or forgetting to include the correct filesystem driver in your kernel or initramfs? (All these things can cause the panic message in your question title.) Does your system use UEFI or a traditional BIOS? Was your /dev/sda disk partitioned using GPT or traditional MBR? Without any solid facts it's hard to offer any advice.– telcoM
Feb 8 at 11:56
I said i messed up partition because. Disk /dev/sdb doesn't contain any partitions. It's written directly. Im using virtual machine (so its traditional bios). Followed this tutorial youtu.be/8WsDcW5SQ9Y see at 6:24
– Susmith
Feb 8 at 12:02
From your original question I assumed you meant you had directly made a filesystem on the disk /dev/sdb without making any partitions (i.e. a so-called "superfloppy" configuration) intentionally. So I could not see which part of your description was about the original state and which was about the damage done. First step would be to use testdisk to see if the old partition table could be reconstructed. I don't have time to view the video tutorial right now, more later.
– telcoM
Feb 8 at 12:10
Ohkay, thanks for the help. How to setup grub in "superfloppy" configuration ie. Where to install it. Installing on /dev/sdb failed. Any useful link will help.
– Susmith
Feb 8 at 12:13