Kernel: cannot open /proc/partitions
-
Take a look at your fog servers mysql system. Check that the bind-address field is set for your servers IP address rather than 127.0.0.1
You’ll have to restart mysql server, but it may help in communicating across the network. This is what, I’ve found, it usually has the issue with.
-
Hey, as written in the PM the bin address is the correct local one and not 127.0.0.1.
-
is it finally able to open /proc/partitions or are you still having this error.
-
If I use another kernel it works but with my self compiled one I got the error, so I think I have done something wrong while compiling the kernel by myself. I also think that the guide on how to compile it is not complete at all (I mean I read it at another place here at the forum) or not working for me with this tut.
-
Which config file did you use? Also, did you do make ARCH=i386 menuconfig and make ARCH=i386 bzImage?
-
I used the one mentioned in the tutorial: [FONT=monospace][COLOR=#000000]cp /opt/fog-setup/fog_0.29/kernel/kitchensink.config /usr/src/linux-2.6.35.3/.config[/COLOR][/FONT]
[FONT=monospace][COLOR=#000000]But the file from the 0.33B installation instead, from the system the FOG is running on.[/COLOR][/FONT]
[FONT=monospace][COLOR=#000000]Yes, I used the [/COLOR][/FONT]ARCH=i386 menuconfig and make ARCH=i386 bzImage!
-
Are you running FOG 0.33? The init.gz has a few changes to it which may be causing the issue. I don’t when I followed the build a custom init information, using a newer version of buildroot, I ran into the same type of issue because it never even copied the right file structure to the host.
-
Yes, the current 899 revision of 0.33 Beta.
I only followed the tutorial how to build a custom kernel and after doing all things mentioned I got the named error.
-
Okay,
The FOG 0.33 hdparm, not registering issue you’re seeing, I don’t know how to help out with that completely, unless you can let me in remotely to assess the issue, but even if you’re able to get past the hdparm issue, you still won’t be able to register the host. 0.33b has removed the host association of the OS field, and now the OS is assigned to the image file itself. This makes perfect sense, except the auto.register.php file still has references to inputting the hostOS which it fails because that table doesn’t exist. I’m going to upload my auto.register.php script, this file goes in:
<fogwebdir>/service/auto.register.php
Also, if you know how to modify the init.gz system -> follows:
cd /tftpboot/fog/images; mkdir tmp; gunzip init.gz; mount -o loop init tmp; cd tmp/bin
Then you’ll have to modify the fog.man.reg file to remove the hostOS input field. I’ll post a copy of that file as well.
You can remove the file fog.man.reg then do:
vi fog.man.reg
Then type the letter i
Then paste the contents fog.man.txt file here into that file. (sorry i can’t just give fog.man.reg, but they don’t allow uploading an extension of .reg)
Once pasted in:
Type the key esc, then type:
:wq
Then:
chmod +x fog.man.regThen:
cd …/…/
umount tmp
gzip -9 initThen you should be good to go without inputting host os.
If all of the init.gz editing seems too complicated, at the very least get rid of the auto.register.php file in fog/service/ and insert the one I’ve provided.
When I first started with fog 0.33b I had the same hdparm issue as you are experiencing, but my exact issue, seemingly, was due to the system not reading the right areas because of my pxe default file missing the trailing slashes as needed. Then I ran into the full registration issue with it and found out about the hostOS field missing from the hosts table in the fog database.
Hopefully this helps you out.
[url=“/_imported_xf_attachments/0/387_auto.register.php?:”]auto.register.php[/url][url=“/_imported_xf_attachments/0/388_fog.man.txt?:”]fog.man.txt[/url]
-
Thank you very very much, it works like a charm!
Did both steps auto.register.php and init.gz.
The error message appears again with the ioctl but the registering is done without problems.
-
You’re welcome then!
-
The IOCTL error isn’t particularly important then. I see it with my home-made kernel because it has RAID drivers built in, but the devices don’t have raid drives. If you’re having issues with imaging a specific drive, it may point you in the right direction, but by itself it’s perfectly fine.
