View previous topic :: View next topic |
Author |
Message |
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Sun Jul 19, 2020 10:53 pm Post subject: RPI 3A Kernel Panic on first boot (unable to mount root fs) |
|
|
I am following along with the 32 bit Gentoo installation on Raspberry Pi, guide here: https://wiki.gentoo.org/wiki/Raspberry_Pi/Quick_Install_Guide#Unmount_the_SD_card_and_boot_the_Raspberry_Pi
I got through the first four sections no problem, but when I go to boot the Pi I get a kernel panic. The exact message is:
Code: |
Kernel Panic - not syncing: VFS: Cannot mount root fs on block-unknown (0,0)
|
I found this article: https://wiki.gentoo.org/wiki/Knowledge_Base:Unable_to_mount_root_fs which suggests to chroot and recompile the kernel, which I would prefer not to do (the guide is written from the perspective of using the Foundation's kernel image. Do I have to? By the kernel image I downloaded was "stage3-armv7a_hardfp-20200509T210605Z.tar.xz".
Output of fdisk -l (just in case):
Code: |
gentoo ~ # fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 14.86 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x83815a47
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 2048 264191 262144 128M b W95 FAT32
/dev/mmcblk0p2 264192 4360191 4096000 2G 82 Linux swap / Solaris
/dev/mmcblk0p3 4360192 31115263 26755072 12.8G 83 Linux
|
Last edited by danielittlewood on Sat Sep 19, 2020 6:06 pm; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Sun Jul 19, 2020 11:05 pm Post subject: |
|
|
danielittlewood,
Code: | Kernel Panic - not syncing: VFS: Cannot mount root fs on block-unknown (0,0) | is a message from the kernel, so the kernel loaded.
unknown-block(0,0) means that the kernel cannot find the block device that the root filesystem in on. In your case that's /dev/mmcblk0.
The file stage3-armv7a_hardfp-20200509T210605Z.tar.xz does not contain a kernel, so where did your kernel come from?
You don't have to use the Pi Foundations binary kernel image. You can build your own kernel binary.
Its a really good idea to use the Pi Foundations kernel sources though as a lot of Raspberry Pi changes are not in the mainline kernel, so if you use gentoo-sources, lots of things don't work. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Sun Jul 19, 2020 11:06 pm Post subject: |
|
|
Moved from Installing Gentoo to Gentoo on ARM.
as its one of these _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Mon Jul 20, 2020 7:53 am Post subject: |
|
|
NeddySeagoon wrote: | danielittlewood,
Code: | Kernel Panic - not syncing: VFS: Cannot mount root fs on block-unknown (0,0) | is a message from the kernel, so the kernel loaded.
unknown-block(0,0) means that the kernel cannot find the block device that the root filesystem in on. In your case that's /dev/mmcblk0.
The file stage3-armv7a_hardfp-20200509T210605Z.tar.xz does not contain a kernel, so where did your kernel come from?
You don't have to use the Pi Foundations binary kernel image. You can build your own kernel binary.
Its a really good idea to use the Pi Foundations kernel sources though as a lot of Raspberry Pi changes are not in the mainline kernel, so if you use gentoo-sources, lots of things don't work. |
Thanks for the move! I understand, I mixed up the stage3 and the kernel image. i believe the kernel is installed here: https://wiki.gentoo.org/wiki/Raspberry_Pi/Quick_Install_Guide#Install_kernel_and_modules, and therefore that the kernel I got was from git://github.com/raspberrypi/firmware.
mmcblk0 is the name given to my microSD card when I connect it to my laptop. I guess I don't know whether the Pi will identify it with the same name (but if this could be a problem, then I don't think it's mentioned in the guide). |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Mon Jul 20, 2020 9:32 am Post subject: |
|
|
danielittlewood,
So far so good.
Put the SD card back in your laptop and redo the
Code: | mount /dev/mmcblk0p3 /mnt/gentoo
mount /dev/mmcblk0p1 /mnt/gentoo/boot | steps.
Run the command Code: | ls -l /mnt/gentoo/boot | and post the output here.
Post the content of
/mnt/gentoo/boot/cmdline.txt
and if you have it, the content of
/mnt/gentoo/boot/config.txt _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Mon Jul 20, 2020 9:54 am Post subject: |
|
|
Code: |
ls -l /mnt/gentoo/boot
total 53944
-rwxr-xr-x 1 root root 25033 Jul 19 23:17 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root 25296 Jul 19 23:17 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root 24644 Jul 19 23:17 bcm2708-rpi-b-rev1.dtb
-rwxr-xr-x 1 root root 24766 Jul 19 23:17 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root 24738 Jul 19 23:17 bcm2708-rpi-zero.dtb
-rwxr-xr-x 1 root root 25931 Jul 19 23:17 bcm2708-rpi-zero-w.dtb
-rwxr-xr-x 1 root root 26299 Jul 19 23:17 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root 26448 Jul 19 23:17 bcm2710-rpi-2-b.dtb
-rwxr-xr-x 1 root root 27946 Jul 19 23:17 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root 28565 Jul 19 23:17 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 26255 Jul 19 23:17 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root 47437 Jul 19 23:17 bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root 47542 Jul 19 23:17 bcm2711-rpi-cm4.dtb
-rwxr-xr-x 1 root root 52480 Jul 19 23:17 bootcode.bin
-rwxr-xr-x 1 root root 157 Jul 19 23:41 cmdline.txt
-rwxr-xr-x 1 root root 18693 Jul 19 23:17 COPYING.linux
-rwxr-xr-x 1 root root 3148 Jul 19 23:17 fixup4cd.dat
-rwxr-xr-x 1 root root 5407 Jul 19 23:17 fixup4.dat
-rwxr-xr-x 1 root root 8414 Jul 19 23:17 fixup4db.dat
-rwxr-xr-x 1 root root 8418 Jul 19 23:17 fixup4x.dat
-rwxr-xr-x 1 root root 3148 Jul 19 23:17 fixup_cd.dat
-rwxr-xr-x 1 root root 7274 Jul 19 23:17 fixup.dat
-rwxr-xr-x 1 root root 10266 Jul 19 23:17 fixup_db.dat
-rwxr-xr-x 1 root root 10266 Jul 19 23:17 fixup_x.dat
-rwxr-xr-x 1 root root 5599624 Jul 19 23:17 kernel7.img
-rwxr-xr-x 1 root root 5997544 Jul 19 23:17 kernel7l.img
-rwxr-xr-x 1 root root 15483392 Jul 19 23:17 kernel8.img
-rwxr-xr-x 1 root root 5247472 Jul 19 23:17 kernel.img
-rwxr-xr-x 1 root root 1594 Jul 19 23:17 LICENCE.broadcom
drwxr-xr-x 2 root root 16384 Jul 19 23:17 overlays
-rwxr-xr-x 1 root root 819100 Jul 19 23:17 start4cd.elf
-rwxr-xr-x 1 root root 3778856 Jul 19 23:17 start4db.elf
-rwxr-xr-x 1 root root 2277376 Jul 19 23:17 start4.elf
-rwxr-xr-x 1 root root 3036168 Jul 19 23:17 start4x.elf
-rwxr-xr-x 1 root root 819100 Jul 19 23:17 start_cd.elf
-rwxr-xr-x 1 root root 4850760 Jul 19 23:17 start_db.elf
-rwxr-xr-x 1 root root 3001440 Jul 19 23:17 start.elf
-rwxr-xr-x 1 root root 3759720 Jul 19 23:17 start_x.elf
|
Code: |
cat /mnt/gentoo/boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1
root=/dev/mmcblk0p3 rootfstype=ext4 elevator=deadline rootwait
|
and /mnt/gentoo/boot/config.txt doesn't exist. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Mon Jul 20, 2020 10:27 am Post subject: |
|
|
danielittlewood,
That all looks good. The boot process goes as follows.
The CPU is held reset while the GPU reads and executes bootcode.bin.
bootcode.bin sets up the hardware, draws the rainbow and looks around to see what what sort of Pi its on.
The same bootcode.bin is used on all the Pis except the Pi 4.
Having determined the hardware, it loads the start* files for that hardware. They in turn, read config.txt, if it exists, the kernel and the *.dtb.
After all that the CPU is released from reset and begins executing the kernel.
With no config.txt, /boot/kernel8.img will be loaded as the Pi3 is 64 bit capable.
If kernel8.img is missisg, it wall fall back to kernel7.img, which is the 32 bit kernel for the Pi3.
I suspect your kernel8.img is faulty. There are several things to try.
Rename kernel8.img, so its not found.
Create a config.txt file that says to use kernel7.img.
Rewrite the boot partition on your SD card.
If you have a small slow SD card, it can take a long time to write. Minutes.
Be careful not to remove it until all the data has been written.
On linux issue the sync command and wait for the prompt to return.
Then its safe to umount.
Thats belts and braces because umount forces a sync too. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Mon Jul 20, 2020 1:21 pm Post subject: |
|
|
Thank you for the additional detail!
NeddySeagoon wrote: | danielittlewood,
With no config.txt, /boot/kernel8.img will be loaded as the Pi3 is 64 bit capable.
If kernel8.img is missisg, it wall fall back to kernel7.img, which is the 32 bit kernel for the Pi3.
I suspect your kernel8.img is faulty. There are several things to try.
Rename kernel8.img, so its not found.
Create a config.txt file that says to use kernel7.img.
Rewrite the boot partition on your SD card.
|
OK, I think I understand. I first suspected that I had failed to properly clean the drive before installation (since I tried a 64 bit installation previously and failed), but I checked the source and kernel8.img is definitely meant to be there.
What I did exactly was to remount, and do
Code: |
rm -rf /mnt/gentoo/boot/*
cd /tmp/firmware/boot
cp -r * /mnt/gentoo/boot/
|
as before in the guide. I mention this because when I tried to boot again I got "unknown block (179,2)" rather than (0,0).
I've just done "mv kernel8.img kernel8.img.bak" and rebooting... same error (unknown block (179,2)). i'll try removing it altogether... same again.
Attempting to write a config.txt file, I guess this is the right resource: https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
it says that arm_64bit defaults to 0, and kernel defaults to kernel7.img. I'm going to try to set them explicitly just in case. same error again. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Mon Jul 20, 2020 2:06 pm Post subject: |
|
|
danielittlewood,
It got a bit further.
The numbers in unknown block (179,2) are the kernel major and minor device numbers.
(0,0) means it can't find any block devices at all.
less /usr/src/linux/Documentation/admin-guide/devices.txt
(179,2) means it found /dev/mmcblk0p2 but could not read it.
As the error keeps changing, I need to ask about the PSU you are using and what devices you have connected.
Erratic issues are often caused by a poor PSU or an overloaded Pi.
Mobile phone chargers are particularly bad.
Due to the way the USB power specification is written, the output voltage is measured at the terminals of the supply.
For PSUs with a detachable cable, that means at the PSU end of the cable.
For PSUs with a fixed cable, its at the end of the cable. The voltage drop in the cable is important.
Mobile phone charges are normally 4.7v, regardless of what it says on the label. That's already low for a Pi.
You ideally need 5.1v at the pins on the Pi. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Mon Jul 20, 2020 11:06 pm Post subject: |
|
|
NeddySeagoon wrote: | danielittlewood,
As the error keeps changing, I need to ask about the PSU you are using and what devices you have connected.
Erratic issues are often caused by a poor PSU or an overloaded Pi.
Mobile phone chargers are particularly bad. |
I did not expect this to be the relevant! But I am indeed using a phone charger for the Pi. I have two - a mains plug with a removable cable and a portable battery, also with a removable USB. The output is a HDMI cable to my monitor and a USB keyboard.
When I first bought it I was aware that it was important to get the power supply right, but I don't know much about electronics and couldn't find advice one way or the other about whether a phone charger would fit. I tried it out with Raspbian a long time ago and I'm completely sure it booted, but I can't be sure that it was with the same travel adapter (although it was definitely with one). I had a look at the plug and it claims to output 5.3V, but as you say it might not be telling the truth. (EDIT: On rereading, it sounds like you are actually suggesting that the 5.3V measurement is probably accurate at the plug end, but that the voltage drop of the USB cable means it might be too low at the pins of the Pi).
I was always under the impression that if the power supply was not sufficient, then the Pi just wouldn't turn on. But it sounds like you're suggesting that's not true?
EDIT: I had a look at the following video: https://www.smbaker.com/measuring-usb-power-cable-voltage-drop-with-my-dc-load which (in particular) shows a multimeter reading of the Pi drawing variable current (which is basically what I was asking above), as well as a maximum power draw some time during boot. This suggests that I may have previously been using a better quality cable previously, which would be consistent with what I can remember of successfully booting it in the past. I will root out my old cables in the morning and see if any of them work. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Mon Jul 20, 2020 11:35 pm Post subject: |
|
|
danielittlewood,
Simplistically, what you say is correct.
If the voltage is too low, the Pi will not turn on. If its too high the Pi will be destroyed.
There is a middle ground because the Pi is not a constant load on the power supply.
It starts out barely adequate, so the Pi starts. Then the Pi draws more power and the voltage falls so its no longer adequate. That makes something on the Pi not work properly.
The Red light on the Pi3 may help. It indicates if the power supply voltage is adequate or not.
If it visibly flickers, its certainly not adequate.
The LED driver takes time to respond, your eyes take time to respond, so even if you don't see the flicker, the PSU is still suspect.
Do you have a powered USB hub?
You can try powering the Pi from one of the USB ports. In theory, the Pi draws more power than a USB port is supposed to provide but most don't enforce the per port current limit.
Is the USB keyboard wired, or is it a wireless one, where the dongle plugs into the USB port?
The wireless sort will want a lot more power than a wired keyboard.
Your link in a good example of the problem, with the Pi being the variable load. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Tue Jul 21, 2020 7:21 pm Post subject: |
|
|
NeddySeagoon wrote: | danielittlewood,
The Red light on the Pi3 may help. It indicates if the power supply voltage is adequate or not.
If it visibly flickers, its certainly not adequate.
The LED driver takes time to respond, your eyes take time to respond, so even if you don't see the flicker, the PSU is still suspect.
Do you have a powered USB hub?
You can try powering the Pi from one of the USB ports. In theory, the Pi draws more power than a USB port is supposed to provide but most don't enforce the per port current limit.
|
Okay, I tried a number of combinations:
- USB connected to mains plug adapter.
- USB hub connected to my laptop.
- USB hub connected to mains plug adapter.
Is there a distinction between any old USB hub (which I basically think of as an USB port extender) and a powered one? If it helps, I believe this is the model I tried it with: https://www.ebay.co.uk/itm/Sabrent-4-Port-USB-2-0-Hub-with-Individual-Power-Switches-and-LEDs-HB-UMLS/233616117368?hash=item36649b0e78:g:vb8AAOSwFpBe4f20.
I have a few different cables so I tried them too, I guessed shorter ones would have lower voltage drop but I guess it depends on the quality of the cable. In any case, none of them seemed to work. I tried a few times and while the red LED was steady, I still got the kernel panic from previously.
NeddySeagoon wrote: |
Is the USB keyboard wired, or is it a wireless one, where the dongle plugs into the USB port?
The wireless sort will want a lot more power than a wired keyboard. |
The keyboard is wired, and it has LEDs under the keys but I have them turned off. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Tue Jul 21, 2020 10:03 pm Post subject: |
|
|
danielittlewood'
A powered USB hub has its own PSU. It presents no power load to the USB bus, in this case the Pi, so with a powered USB hub, the Pi no longer powers the keyboard, or anything else connected to the Hub.
Your link does not suggest it has a PSU.
Search amazon for "powered USB hub". If you search for "USB hub" instead, your hub shows up.
If all else fails, you need a Raspberry Pi 3 PSU.
Don't be tempted to get a Raspberry Pi 4 PSU, it has a USB-C connector, not micro USB. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Wed Jul 22, 2020 7:36 am Post subject: |
|
|
NeddySeagoon wrote: | danielittlewood'
A powered USB hub has its own PSU. It presents no power load to the USB bus, in this case the Pi, so with a powered USB hub, the Pi no longer powers the keyboard, or anything else connected to the Hub.
Your link does not suggest it has a PSU.
Search amazon for "powered USB hub". If you search for "USB hub" instead, your hub shows up.
If all else fails, you need a Raspberry Pi 3 PSU.
Don't be tempted to get a Raspberry Pi 4 PSU, it has a USB-C connector, not micro USB. |
Got it, thank you! I mentioned earlier that I had successfully booted the Pi using (for example) Raspbian, rather than Gentoo. Is this consistent with what you understand so far? In particular, would it make sense that different kernels would have different max power draws, and thus be sometimes vulnerable to this problem and sometimes not? |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Wed Jul 22, 2020 4:40 pm Post subject: |
|
|
danielittlewood,
Yes that's possible. I would split it more along the lines of 32 bit distros like Raspbian, will have a lower max power requirement than 64 bit distros, like Sakakias image.
If you are only going to use half the CPU, the maximun CPU power will be down too.
Further, Raspbian uses the Powersave CPU governor by default, Sakakias image uses Ondemand.
The former runs the CPU at 600Mhz permanently. Ondemand switches between 600Mhz when there is not much happening, to 1200MHz (its the CPU max clock) when the CPU is busy. That will increase the CPU power requirement by about a factor of two. In CMOS electronics the power requirement is proportional to clock speed and applied voltage.
The first time things get busy is during booting.
Your unknown-block(0.0) problem is consistent with the SD card not being available due to an undervoltage.
I'm not encouraging you to try this but like overvolting and overclocking to go faster, its possible to undervolt and underclock the Pi too.
If you want to try, read and understand these config.txt options.
Under/over clocking operates the Pi in the manufacturing safety margins. Some samples go better that others.
This may confirm the diagnosis of an inadequate PSU, but it won't make up for 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 |
|
|
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Wed Jul 22, 2020 8:00 pm Post subject: |
|
|
Okay, thank you once again for all your help! I think that's enough for me to get on with.
I plan to buy an official PSU to be sure, but I am keen to get the Pi to work under these conditions since it permits me to use the same battery pack I use for my phone, which is convenient for moving it around. I'm not planning on having it be totally mobile, but it means I don't have to worry about cable lengths and having a plug socket nearby. |
|
Back to top |
|
|
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Sat Sep 19, 2020 5:53 pm Post subject: New PSU didn't help |
|
|
I return with a new, official PSU - and sadly I still have issues.
To review: I am still following the 32-bit guide here: https://wiki.gentoo.org/wiki/Raspberry_Pi/Quick_Install_Guide
The error I see is still "Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)".
I temporarily saw "unknown-block(179,2)". I now understand that this changed when I recreated my boot directory, but did not recreate the cmdline.txt file.
It appears that if the cmdline.txt file does not exist, then the SD card tries to boot from partition 2. But if the option root=/dev/mmcblk0p3 is passed, then it fails to find anything at all.
I also changed the title - my Pi is a 3A, not a 3B+ as previously claimed. _________________ With man it is impossible, but with gcc all things are possible. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Sat Sep 19, 2020 6:36 pm Post subject: |
|
|
danielittlewood,
The kernel has a built in command line which is mostly not useful. Its used when you don't provide your own.
Code: | dwc_otg.lpm_enable=0 8250.nr_uarts=1 console=ttyAMA0,115200 console=tty root=/dev/sda3 rootfstype=ext4 rootwait |
Thats my /boot/cmdline.txt. Whatever you put there must be a single long line.
You will need to adjust the Code: | root=/dev/sda3 rootfstype=ext4 | for yourself.
rootwait takes care of slow devices providing the root filesystem.
The kernel waits for it to appear, or forever.
Use rootdelay=30 in place of rootwait while you investigate.
That gives the hardware 30 seconds to get root on line before it tries to mount it anyway. You get to see the panic message that way. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
danielittlewood n00b
Joined: 13 Apr 2020 Posts: 60
|
Posted: Sat Sep 19, 2020 6:53 pm Post subject: |
|
|
NeddySeagoon wrote: | danielittlewood,
Whatever you put there must be a single long line. |
That was the magic spell! I think my editor was hard-wrapping at 80 characters automatically.
For the avoidance of doubt, I tried this with my old power supply (phone charger) and it boots okay with that too, so I think this was the problem all along.
Thanks! _________________ With man it is impossible, but with gcc all things are possible. |
|
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
|
|