The first time linux really let me down. A couple of months ago I installed Linux on a new Toshiba laptop, erasing all windows partitions. I was not an easy installation, I had to find out about EFI and change BIOS settings which took some time.
Now after months of working without any problem the system will not boot anymore. The normal boot screen comes up, but after some time it hangs after displaying these messages:
udevadm: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
Trying manual resume from /dev/disk/by-id/ata/-TOSHIBA_MQ01ABD100_93FWTDIRT-part2
udevadm: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
resume device /dev/disk/by-id/ata/-TOSHIBA_MQ01ABD100_93FWTDIRT-part2 not found (ignoring)
Trying manual resume from /dev/disk/by-id/ata/-TOSHIBA_MQ01ABD100_93FWTDIRT-part2
udevadm: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
resume device /dev/disk/by-id/ata/-TOSHIBA_MQ01ABD100_93FWTDIRT-part2 not found (ignoring)
Waiting for device /dev/root to appear: …… Could not find /dev/root
Want me to fall back to /dev/disk/by-id/ata/-TOSHIBA_MQ01ABD100_93FWTDIRT-part3? (Y/n)
I tried the rescue disk with some success - could start up and save vital data. However, during start op, amongst many other messages this one appeared:
partition 1 on /dev/sr does not appear … fatal!
I tried to re-install grub2-efi with Yast but that did not work, giving the message:
Path ‘boot/grub2’ is not readable by GRUB on boot. Installation is impossible
I conclude from this there’s something wrong with the EFI boot partition (/dev/sda1). However mounting it, showed everything in place.
Unmounting and trying fsck does not indicate any errors. However when I mount it again and try fsck, it indicates that the ‘Dirty bit’ is set because the filesystem was not properly unmounted.
My questions:
Has anyone seen this boot failure before and found a solution?
Can I simply let fsck remove this dirty bit and hope it solves the problem (I’m a bit wary here - afraid to do further damage)
I saw in in other thread a similar problem (e.g. mentioning failure to load libz.so.1 during boot) and it was mentioned that ‘remake initrd’ had solved the problem. But could not find any useful further reference to that. Does anyone know if this could be useful?
If you used your system - that as you said was installed months ago - in a usual way,
and didn’t fiddle about system files recently, then a hardware error is the most likely cause,
I would guess.
Now here I have a problem: /dev/sr must be your USB stick or pendrive - am I wrong?
Either that boots or not!
There is only black or white here, if it is plugged well !
Please boot the rescue system from your USB stick / pendrive, say
parted -l
in a terminal
(if you’re not already on the command line - I never booted the rescue system yet),
save the output on some USB device in a text file (using the command line or a text editor),
and post that here.
It actually sounds more like it is a CD or DVD drive.
However, the nature of the problem actually sounds like the HD is failing, or there is intermittence in the data path from the HD to the PC, or there is a faulty RAM module.
I agree.
The USB stick would normally be recognized as hard disk, i.e. /dev/sdX.
Is there an entry for /dev/sr in the /etc/fstab? That would explain that error.
You could remove/comment that, shouldn’t be necessary anyway.
However, the nature of the problem actually sounds like the HD is failing, or there is intermittence in the data path from the HD to the PC, or there is a faulty RAM module.
Or just a faulty initrd, probably caused by a full /boot partition.
So please check that /boot has enough space left, and try to re-create the initrd by chrooting into the system and running “mkinitrd”.
That apparently solved the problem in the other thread you mentioned.
Thanks for the suggestions so far. The problem with re-installing the boot manager looks like Yast tries to install it on the rescue CD. Also the ‘fatal’ error message is indeed related to CD or USB stick, so may not be related to the hard disk problem. I also did a fsck on dev/sda3 but nothing seems to be wrong. parted -l gives a list of the partitions, nr 3 is the primary boot partition, type ext4, size 21.5 GB (wolfi323, do you mean with ‘/boot has enough space left’ that this partition may need a resize?
I tried to re-create the initrd but that is not so simple. After starting the from the rescue CD I mounted /dev/sda3 on /mnt, chroot-ed to /mnt and ran mkinitrd. However, mkinitrd complains that it cannot unmount /sys and then quits with an error.
mount /dev/sda3 /mnt
mount /dev/sda? /mnt/boot/efi ## fill in the '?' with correct efi partition value
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
chroot /mnt
mkinitrd
But I don’t think reinstalling the boot loader will help in your situation.
parted -l gives a list of the partitions, nr 3 is the primary boot partition, type ext4, size 21.5 GB (wolfi323, do you mean with ‘/boot has enough space left’ that this partition may need a resize?
So you don’t have a separate /boot partition?
21.5 GB for / should be enough normally, but that doesn’t mean of course that it cannot get full.
Please mount /dev/sda3 and run “df -h /mnt” (or wherever you mounted it to) to verify the free space.
The initrd needs 24MB on my system, so if there is less than that free you have to delete something to free up space. (tmp/, var/tmp/, var/log and var/cache/zypp/ are good candidates)
I tried to re-create the initrd but that is not so simple. After starting the from the rescue CD I mounted /dev/sda3 on /mnt, chroot-ed to /mnt and ran mkinitrd. However, mkinitrd complains that it cannot unmount /sys and then quits with an error.
You have to mount /dev, /proc and /sys first, like you do for the boot loader installation.
So see above, but run “mkinitrd” instead of “grub2-mkconfig” and “grub2-install” as the last step.
Thanks again. On /dev/sda3 30% of the space was still available, so that could not be the problem. The partitions are not BTRFS formatted.
Thanks to your tips I could recreate the initrd. Unfortunately that still did not solve the problem.
>:(:(" title="Angry" border="">
It is getting a bit uncomprehensible to me. No indication of a harddisk failure - fsck does not show any errors. Initrd re-installed. The file libz.so.1 [FONT=arial]which is complained about during startup is simply available in the lib directory on /dev/sda3.[/FONT]
I’m afraid I have to re-install the whole system and see then what happens.
I still think it is HD or Memory, or poor cable connections.
For HD, get & run the manufacturer’s diagnostics, check the cable connections (disconnect, clean, reconnect), and possibly test with another HD, or test the same HD in another PC, if you can.
For Memory:
If you have more than one stick and are not required in pairs, remove one module. If that works, then you have a failing module.
If not, replace the module and remove another. Do this until you have tested all modules.
Usually, in a 4-stick system, I will pull one pair and test, then pull the other pair and test. If the problem disappears, then at least one of the pulled pair is faulty.
I find this way quicker than running lengthy memtest+ sessions.
I did memory checks and harddisk checks again - no problem showed up. Finally I have re-installed the system - it is running again flawless.
The only thing I changed with the new installation was moving to booting using MBR from the root partition (after changing the firmware setting of the laptop to non-EFI boot).
I still wonder what may have caused the trouble. The last time I shut down the system there were no visible problems. The only unusual thing was that it hat been running for at least two weeks without shutting down or rebooting.
Anyway, thanks all for your helpful tips, I learned a lot from this!