PDA

View Full Version : last log line:FATAL..can't initial. iptables table 'filter'



d_s_b
04-Apr-2015, 21:42
:) Hello !

This is my first message here.

Using SP3 since August, "3.0.101-0.47.52" currently displayed on boot menu.

Today I rebooted and I get :
(at least 4 times the 3 lines below)
FATAL: Module ip_tables not found.
iptables v1.4.6: cant't initialize iptables table 'filter': iptables who? (do you need to insmod?
Perhaps iptables or your kernel needs to be upgraded.


<green>done


Master Resource Control: runlevel 5 has been: <in white> reach
Failed services in runlevel 5: microcodee.ctl hp-wmi-sync
Skipped services in runlevel 5: nfs smbfs


Boots ok in failsafe mode, found the logs application in YaST, can look through the full log.

I have tried googling up the following (I am a 20 years Windows user):
- "suse sled failsafe network" (I usually install only security updates, and the "orange" updates that speak to me (time zones, a hardware driver), or when I launch all updates (red and orange) by accident (usually not all install because you have to do them in a certain order, so even then there are some if not all remaining). You can't hide them like in Windows.

Yesterday or the day before I was prompted with 24 orange updates, and I launched all by mistake. None installed, I carried on with other things. Then the reboot today and the problem above. I was therefore looking to get network in failsafe, and look up all the updates, and find the one that corrects this problem.

mikewillis
05-Apr-2015, 01:23
Using SP3 since August, "3.0.101-0.47.52" currently displayed on boot menu.


That's the kernel version you have installed and it's the most recently released one.




(I usually install only security updates, and the "orange" updates that speak to me (time zones, a hardware driver), or when I launch all updates (red and oranne) by accident (usually not all install because you have to do them in a certain order, so even then there are some if not all remaining).

Updates do not have to be installed in a certain order, at least they shouldn't need to be. Installing any update should cause any other updates it requires to be automatically installed. If you are finding you have to install updates in a certain order to mak them install it sounds like something is wrong wth your system. You will find things easier if you just install all updates. Is there a particular reason you're picking and chosing which updates to install?

Since you already have the latest kernel version there isn't an update that's going to fix your problem and since the problem is with iptables getting network up could be tricky.

When you're in failsafe mode is a FAT32 USB drive recognised? (I think it will but I don't have a machine I can boot to failsafe mode to check that right now.) If so, I'd try downloading the latest kernel packages on another machine then copy them over with the USB drive and re-install them.

SLED 11 SP3 updates can found at https://download.suse.com/patch/finder/#bu=suse&familyId=7260&productId=42044&dateRange=&startDate=&endDate=&priority=&architecture=&keywords=&xf=7260
For some reason the last kernel updates are inconsistently called 'Linux Kernel' for the 32bit (i586) version and 'Linux' for the 64bit (x86_64) version.

You don't need all the packages, just the ones you have installed. You can figure out which ones to download by running


$ rpm -qa | grep ^kernel
download whatever packages are listed on another machine, put them on the USB flash drive and plug that in to the SLED machines. It'll be mounted under /media somewhere. Then run


$ su -
to become root, then

$ rpm -ivh --replacepkgs /media/whatever/path/to/the/rpms/*rpm
If all looks good, reboot and hopefully all will be well. Assuming it is then become root again and run

$ zypper refresh
$ zypper verify
that will refresh the list of available packages and check that all package dependencies are met. If it finds problems, let it sort them out. Once that's done run

$ zypper up
which will install all outstanding updates.

d_s_b
05-Apr-2015, 22:36
Hi Mike !

Thanks for the long reply (no USB support in failsafe mode, transfered files by booting from a Gparted Live usb drive).

So:
rpm -qa | grep ^kernel gives 6 lines

kernel-default-3.0.101-0.47.50.1
kernel-default-extra-3.0.101-0.47.50.1
kernel-source-3.0.101-0.47.52.1
kernel-default-devel-3.0.101-0.47.50.1
kernel-default-base-3.0.101-0.47.52.1
kernel-firmware-20110923-0.52.3

Found only the three "50.1" through https://download.suse.com/Download?buildid=kvajMK7Upm0~

To find the other three I had to google to find the corresponding annoucement pages, which linked to the download pages with code search keywords (e.g. 8936b44d0ab968ebbb3e71a91083c825)

Noted the discrepencies ("50.1","52.1","52.3") but since I am new to this I thought maybe it is normal, and pushed on with rpm -ivh --replacepkgs ...

Got (the) two (expectable) "failed dependencies" errors :
....default-base(x86_64) = 3.0.....50.1 is needed by ...-default ....50.1
....source = 3.0.....50.1 is needed by ...-default-devel....50.1

I am too tired now to try and find the two requested "50.1", and anyway I feel I need a check point... (e.g. maybe the thing to do is get all packages in 52.x, etc.)

Looking forward to (your) lecture nb. 2) :-), Happy Easter !

mikewillis
06-Apr-2015, 22:10
So:
rpm -qa | grep ^kernel gives 6 lines

kernel-default-3.0.101-0.47.50.1
kernel-default-extra-3.0.101-0.47.50.1
kernel-source-3.0.101-0.47.52.1
kernel-default-devel-3.0.101-0.47.50.1
kernel-default-base-3.0.101-0.47.52.1
kernel-firmware-20110923-0.52.3

That's not good.




Found only the three "50.1" through https://download.suse.com/Download?buildid=kvajMK7Upm0~

To find the other three I had to google to find the corresponding annoucement pages, which linked to the download pages with code search keywords (e.g. 8936b44d0ab968ebbb3e71a91083c825)

All updates can be found via the Patch Finder that I linked to. If you want to narrow the list down to (mostly) kernel updates put 'kernel' in the keywords field.







Noted the discrepencies ("50.1","52.1","52.3") but since I am new to this I thought maybe it is normal, and pushed on with rpm -ivh --replacepkgs ...

Got (the) two (expectable) "failed dependencies" errors :
....default-base(x86_64) = 3.0.....50.1 is needed by ...-default ....50.1
....source = 3.0.....50.1 is needed by ...-default-devel....50.1

I am too tired now to try and find the two requested "50.1", and anyway I feel I need a check point... (e.g. maybe the thing to do is get all packages in 52.x, etc.)

kernel-firmware package aside, forget that package for the time being, all the packages should have the same version number. So as you suggest, the thing so do is get version 3.0.101-0.47.52.1 of all those packages. If you're using 32bit they are at https://download.suse.com/Download?buildid=6b0rh3ireuE~ if you're using 64bit they are at https://download.suse.com/Download?buildid=ktwnUnuB6pQ~

Once you have them you need to upgrade the packages that aren't already 3.0.101-0.47.52.1. You should be able to do that with

$ rpm -Fvh /media/whatever/path/to/the/rpms/*3.0.101-0.47.52.1*rpm
The F option means freshen, it upgrades packages but only if an earlier version of the package is installed.
Assuming that goes OK I'd be inclined to re-install the kernel-default-base-3.0.101-0.47.52.1 rpm.

$ rpm -ivh --replacepkgs /media/whatever/path/to/the/rpms/kernel-default-base-3.0.101-0.47.52.1.x86_64.rpm
Don't worry about kernel-source for the time being, that package doesn't provide anything required to make the system run.
Now reboot. Assuming all is well run the zypper commands I mentioned in previous post.I'd also be inclined to rip out the kernel-source package and re-install it just in case there's something wrong with it.


$ rpm -e --nodeps kernel-source
$ zypper in -y kernel-source
First command uninstalls the kernel-source package ignoring whether any other package has it as a dependency. Second command installs the package.



I just booted a SLED 11 SP3 in failsafe mode, the networking works. But this install isn't screwed up ;) I can't test using a USB flash drive in failsafe mode since I currently only have access to an install in a virtual machine or some reason I can't get the virtualisation software to attach a USB device to it :/ To be honest I don't think I've ever booted a machine in failsafe mode before.

mikewillis
08-Apr-2015, 11:26
I just booted a SLED 11 SP3 in failsafe mode, the networking works. But this install isn't screwed up ;) I can't test using a USB flash drive in failsafe mode since I currently only have access to an install in a virtual machine or some reason I can't get the virtualisation software to attach a USB device to it :/ To be honest I don't think I've ever booted a machine in failsafe mode before.

Just booted a SLED 11 SP3 in failsafe mode. Plugged in a FAT32 USB drive and it mounts and works fine.

d_s_b
09-Apr-2015, 15:48
Looks like I'm out the woods, many thanks. Only thing remaining (may have caused all this), is grub update still fails to install. Here are the errors I picked up along the way during the process:

Upon replacing default-base I got:
...
Bootsplash : SLED 800x600
44110 blocks
Perl-Bootloader ....<3> pbl-5827.2 FileIO::Readfile.90: Error Failed to open boot/grub/menu.lst No file or folder of this type.
(same line but with grub/device.map)
(same line but with ...27.2 Core::GRUB:: GrubDev2UnixDev.476: Error: did not find a match for hd0
in the device map (2 times, so 4 lines in total)

Upon reboot the regular boot option (1st in boot menu) froze near the end (worse than before), but in failsafe network was back, so I did the zypper commands, and got

36 packages
...
Instaling: grub-0.97-162.172.1 [error]
Failed install of grub...72.1
(with --nodeps --force) error: Subprocess failed. Error: RPM fail: error:

unpacking of archive failed on file /boot/boot;5526xxx: cpio: symlink failed

- Operation not permitted

All other packages installed. Upon reboot, at last the regular boot worked. Finished doing your instructions (rip/replace kerner-source), then tried the 3 zypper commands a couple of times, but no joy for this last grub packet.

I googled "grub unpacking the archive failed cpio symlink boot", found this thread https://forums.opensuse.org/showthread.php/485521-openSUSE-12-3-failure-of-GRUB-to-install (https://forums.opensuse.org/showthread.php/485521-openSUSE-12-3-failure-of-GRUB-to-install), did the ls -l / ls -ld boot in the /boot directory, I seem to be missing the boot --> . symbolic link [?] file in this directory that he has in this thread.

I would be tempted to ignore it, save for the fact that since talking to you I get the feeling that ignoring things is the best way to get into this situations. Will resume using my system and postpone a due cloning, and keep an eye on this thread.

mikewillis
09-Apr-2015, 21:30
Upon reboot the regular boot option (1st in boot menu) froze near the end (worse than before), but in failsafe network was back, so I did the zypper commands, and got

36 packages
...
Instaling: grub-0.97-162.172.1 [error]
Failed install of grub...72.1
(with --nodeps --force) error: Subprocess failed. Error: RPM fail: error:

unpacking of archive failed on file /boot/boot;5526xxx: cpio: symlink failed

- Operation not permitted

All other packages installed. Upon reboot, at last the regular boot worked. Finished doing your instructions (rip/replace kerner-source), then tried the 3 zypper commands a couple of times, but no joy for this last grub packet.

I googled "grub unpacking the archive failed cpio symlink boot", found this thread https://forums.opensuse.org/showthread.php/485521-openSUSE-12-3-failure-of-GRUB-to-install (https://forums.opensuse.org/showthread.php/485521-openSUSE-12-3-failure-of-GRUB-to-install), did the ls -l / ls -ld boot in the /boot directory, I seem to be missing the boot --> . symbolic link [?] file in this directory that he has in this thread.

I would be tempted to ignore it, save for the fact that since talking to you I get the feeling that ignoring things is the best way to get into this situations. Will resume using my system and postpone a due cloning, and keep an eye on this thread.

I've just look at five SLED 11 SP3 installs and /boot/boot exists on all of them and is provided by the grub package. E.g.

linux:~ # file /boot/boot
/boot/boot: symbolic link to `.'
linux:/boot # rpm -qf /boot/boot
grub-0.97-162.172.1
linux:/boot #

So odd that it's missing from yours. Try creating it

$ cd /boot/
$ ln -s . boot
then try installing updates again.


For future reference, CODE tags are the best thing to put around stuff like command output or file contents rather than changing the font colour. CODE tags help with readability and also prevent the forum software applying unwanted formatting. Look for the # button in the toolbar when composing. (If you don't see it click 'Go Advanced')

d_s_b
09-Jul-2015, 17:44
Hello again! :)

I took at last the time to try and fix the missing /boot/boot symbolic link that is blocking GRUB updates in YaST.


Try creating it

$ cd /boot/
$ ln -s . boot

It doesn't work even if I put sudo in front. I have a linux Live thumb drive (gparted): should I boot from the thumdrive, mount the volume containg /boot, and then try to create the symlink as instructed above?

jmozdzen
10-Jul-2015, 12:12
Hi d_s_b,

Hello again! :)

I took at last the time to try and fix the missing /boot/boot symbolic link that is blocking GRUB updates in YaST.



It doesn't work even if I put sudo in front. I have a linux Live thumb drive (gparted): should I boot from the thumdrive, mount the volume containg /boot, and then try to create the symlink as instructed above?

if you'd be a bit more specific on "it doesn't work", we might be able to sort it out ;) I.e. post a c&p of the session where we can see what command(s) you typed and what the resulting output is; adding calls to (and output of)
ls -l /boot;df -h /boot;mount | grep $(df /boot|tail -1|cut -d\ -f 1) (those are *two* blanks after the back-slash) after your attempt to link might help assessing the situation, too.

Regards,
Jens

d_s_b
17-Jul-2015, 11:27
It doesn't work even if [blah, blah] I

if you'd be a bit more specific on "it doesn't work", we might be able to sort it out ;) I.e. post a c&p of the session where [...]


Indeed, sorry about that. Here it is:



$ cd /boot/
$ ln -s . boot
ln: failed to create symbolic link «*boot*»: Permission not "awarded"
$ sudo ln -s . boot
ln: failed to create symbolic link «*boot*»: "Operation not permited"

(Note: text between "" above is word-for-word translation from French (my locale) - the beginning of the messages is in English as shown however.

Also, as suggested:



$ ls -l /boot
-rwxr-xr-x 1 root root 160 24 mai 2014 autoexec.bat
-rwxr-xr-x 1 root root 3525 6 nov. 2013 BNBXXXXRABL603.ini
-rwxr-xr-x 1 root root 1236 13 août 2014 boot.readme
-rwxr-xr-x 1 root root 65814 28 août 2006 command.com
-rwxr-xr-x 1 root root 131786 29 mai 14:46 config-3.0.101-0.47.55-default
-rwxr-xr-x 1 root root 110 24 mai 2014 fdconfig.sav
-rwxr-xr-x 1 root root 110 24 mai 2014 fdconfig.sys
-rwxr-xr-x 1 root root 272715 24 mai 2014 grldr
drwxr-xr-x 2 root root 1536 8 juil. 20:56 grub
-rwxr-xr-x 1 root root 290979 31 mars 2013 grub.exe
drwxr-xr-x 3 root root 512 6 nov. 2013 hp
-rwxr-xr-x 1 root root 9546337 9 juil. 19:18 initrd-3.0.101-0.47.55-default
-rwxr-xr-x 1 root root 45344 21 juin 2011 kernel.sys
-rwxr-xr-x 1 root root 190 24 mai 2014 menu.lst
-rwxr-xr-x 1 root root 442368 7 sept. 2014 message
-rwxr-xr-x 1 root root 4783 24 mai 2014 splash.gz
drwxr-xr-x 3 root root 512 12 avril 2013 swsetup
-rwxr-xr-x 1 root root 251994 6 mars 15:37 symsets-3.0.101-0.47.50-default.tar.gz
-rwxr-xr-x 1 root root 636638 6 mars 15:36 symtypes-3.0.101-0.47.50-default.gz
-rwxr-xr-x 1 root root 225516 29 mai 15:44 symvers-3.0.101-0.47.55-default.gz
-rwxr-xr-x 1 root root 2085430 29 mai 15:20 System.map-3.0.101-0.47.55-default
drwxr-xr-x 3 root root 1024 24 mai 2014 SYSTEM.SAV
-rwxr-xr-x 1 root root 4635059 29 mai 15:40 vmlinux-3.0.101-0.47.55-default.gz
-rwxr-xr-x 1 root root 3965216 29 mai 16:33 vmlinuz-3.0.101-0.47.55-default

$ df -h /boot
File syst. Size Used Avai l. % Mounted on
/dev/sda1 197M 23M 175M 12% /boot

$ mount | grep "sda1..."
/dev/sda1 on /boot type vfat (rw,relatime)

(Note: BNBXXXXRABL603.ini filename above looked like a password, so I changed 4 characters to "X"s when posting. Also man for tail does not list a "-l" option [...?] but I got from your command that it was meant to get the "sda1" out of df /boot, so I ran just mount and pasted just the line with sda1.
Thanks !

jmozdzen
20-Jul-2015, 11:03
Hi d_s_b,

> /dev/sda1 on /boot type vfat (rw,relatime)

your /boot is on a VFAT-formatted partition - which doesn't support all operations like an Ext3 file system would, hence the errors.

Is there any special reason you did not put /boot on a new, empty, Ext3-formatted partition?

Regards,
Jens

d_s_b
07-Aug-2015, 15:25
your /boot is on a VFAT-formatted partition [...]

Is there any special reason you did not put /boot on a new, empty, Ext3-formatted partition?


Thanks for your reply Jens!
Following your question, I took an old (june) clone of my hard disk, installed it in the laptop, and did a "factory recovery" (at boot screen). I then performed again the check on the /boot media format-type - still vfat (rw,relatime)

System is a HP ProBook bundled with SLED 11 SP3 (build 3.0.82-0.7.9.5887.3.PTF.835925)



#zypper sl
[...]
1 | HP-BNB-Dedicated Update Channel | [...] | rpm-md


What is your take on this? Should I:
- 'complain' to HP that their SLED repackaging is not 'standard' and 'demand' a correct install media?
or
- is there any security risk to continue living with /boot on a VFAT partition? If no, is there another (then the one you indicated in your first reply) way to fix my problem (aka missing /boot/boot symlink),
and
- This system was purchased in a [European][eastern] country (Full European (aka West-/developped countries waranty however). Should I suspect foulplay on the part of the reseller over there before my purchase?

jmozdzen
07-Aug-2015, 17:36
Hi d_s_b,

> - 'complain' to HP that their SLED repackaging is not 'standard' and 'demand' a correct install media?

does your system come with support? Then just open a ticket with HP. If without support, you might try to claim it defective, detailing the error, and asking for instructions on how to do updates.

> - is there any security risk to continue living with /boot on a VFAT partition? If no, is there another (then the one you indicated in your first reply) way to fix my problem (aka missing /boot/boot symlink),

If only grub cannot be updated, I wouldn't call it a security risk. OTOH, not being able to automatically update should be considered a security risk. Either way, I'd call it sort of a defect.

To fix the situation on your behalf, I'd recommend to save all the files from /boot in some other location and to recreate the file system as ext3, then move back all the files. Once done, you should be able to update grub, after creating the probably still missing symlink... but there are a number of potential pitfalls, testing this on your "receovered" system first would be a very good idea. ;)

> Should I suspect foulplay on the part of the reseller

No, probably more an oversight or lack of knowledge/testing.

Regards,
Jens

d_s_b
18-Feb-2016, 11:03
Hi d_s_b,
To fix the situation on your behalf, I'd recommend to save all the files from /boot in some other location and to recreate the file system as ext3, then move back all the files. Once done, you should be able to update grub, after creating the probably still missing symlink... but there are a number of potential pitfalls, testing this on your "recovered" system first would be a very good idea. ;)


Thanks again, got back to this.
Booted from a GParted Live USB (0.22.0-1-) and copied the files with

cp -r
Checked with

ls -alF
that all the files were there and the directory structure matched.
Then deleted the VFAT partition and with gparted, created the ext3 one. Added the "boot" label, copied back the files & checked the same way.
Then created the .boot symlink with
ln -s . boot When booting: blank screen (black). Happy I did not do it on the original drive but on the clone (which of course I tested fine before this operation) :-D. So I may have fallen in one of the pitfalls you mentioned.

Now I am considering that from my 11.3 there is a an upgrade to SUSE 12. Is this migration likely to recreate/replace the boot partition correctly (ext3)? Or will it keep the "bad" VFAT partition I currently have? Or it is likely the upgrade (or for that matter even installing service pack 11.4) will fail because of this missing .boot symlink. If it is the latter third option, then maybe you see what I did wrong above in implementing the fixing instructions.

Regards,