- This topic has 5 replies, 2 voices, and was last updated Nov 17-1:39 pm by masinick.
November 17, 2019 at 8:45 am #29419MemberBobC
I’m not sure if they also panic from a Debian based install.
The only way I have found that works is to install Arcolinux or Manjaro and let them manage the Grub boot, but maybe I am doing something wrong to cause it. It is happening on 3 different laptops, all different flavors of Dell, XPS15, M2400, and D620. Both EFI and legacy…
Boot repair doesn’t fix it.
Is there a known problem or workaround, or something I am not doing right?
- This topic was modified 7 months, 2 weeks ago by BobC.
Attachments:November 17, 2019 at 10:58 am #29428Moderatormasinick
Hi BobC, just out of curiosity, have you tried to compare the boot entries that these distributions create?
One possibility is that there are different boot parameters.
A more likely scenario is that the disk partitions are either using a disk partition format that differs from the antiX available disk partition formats: ext3, ext4, JFS, ReiserFS, XFS. Another equally likely possibility is that the disk partitions created in these distributions are not easily mounted from another boot loader – there may be mounting, loading, or device partition parameters that must be modified in order to make these partitions accessible from another distribution, or in other words, these distributions don’t automatically make it easy for their distribution to interoperate.
It’s also possible that either antiX or one, or all of these distributions have some hidden defect that makes mounting them from another source malfunction. The “unknown block” and the “tainted” comment suggests that however the disk partition is identified, the methods used between the distributions differ and therefore the blocks referenced in the mount request are being interpreted incorrectly because they are identified differently. My best guess is that the other distributions are not naming the disk format type with ext3, ext4… either another disk format is being used or the other distribution failed to enter the partition format.
If you load a live USB and look at the disk partitions, can you see any identifying information?
That may assist in diagnosing what is actually taking place.
Brian MasinickNovember 17, 2019 at 11:12 am #29429MemberBobC
I was first seeing if:
1. loading Arcolinux and installing it would fix it again. Yes, it did.
2. loading Debian 10 live gnome would allow me to boot Arcolinux or not. Yes, it did work.
3. loading stock antiX 19 64 bit full and installing it would make it so I can’t boot Arcolinux or not?
Since at this point, Debian is installed and Arcolinux is still able to boot, I can do as you asked and grab a copy of what Debian built in the /boot directory. If antiX stock doesn’t work, then I can compare what it created.November 17, 2019 at 12:05 pm #29430MemberBobC
I don’t know why, but now its not happening. I installed grub and updated again from my modified antiX19 and Arcolinux boots now.
I think it had something to do with flex??? software it found in sector 32 of the boot which it has complained about on each machine. I had to use dd to remove it.November 17, 2019 at 12:20 pm #29432MemberBobC
and btw, thanks for jumping in to help 🙂November 17, 2019 at 1:39 pm #29436Moderatormasinick
Good job, you figured it out!
- You must be logged in to reply to this topic.