Dne Pá 5. září 2014 21:18:35, Basil Chupin napsal(a):

On 05/09/14 20:37, Carlos E. R. wrote:

...

On 2014-09-05 12:17, Basil Chupin wrote:

...

I need to check the condition of the file system to determine whether my HDD is failing or it is the ext4 file system is corrupted.

I use a rescue usb stick.

Thank you Carlos, but I do not have a 'rescue usb stick' :-) .

Download ISO, dd it to the USB stick and go on. ;-) You only need to be able to boot from USB stick. ;-) Good luck, Vojtěch -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/

On 09/05/2014 07:37 AM, Basil Chupin wrote:

On 05/09/14 21:23, Vojtěch Zeisek wrote:

...

Dne Pá 5. září 2014 21:18:35, Basil Chupin napsal(a):

...

On 05/09/14 20:37, Carlos E. R. wrote:

...

On 2014-09-05 12:17, Basil Chupin wrote:

...

I need to check the condition of the file system to determine whether my HDD is failing or it is the ext4 file system is corrupted. I use a rescue usb stick. Thank you Carlos, but I do not have a 'rescue usb stick' :-) . Download ISO, dd it to the USB stick and go on. ;-) You only need to be able to boot from USB stick. ;-) Good luck, Vojtěch

So what you are saying is that the old and trusted 'e2fsck' performed on a system by going to level #1 is now no longer a working proposition and that one needs the Rescue DVD/schtik to do this check of the file system? :-) .

If so, the more we progress the further we move back ;-) .

No, what he's saying is that you can't run fsck on the file system you're running from. Running from a usb stick or liveCD guarantees that the HDD you are checking is not in use. If the HDD *is* corrupted you don't want to be running from it when you check it. You want to be running from something that you have confidence in. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Fri, 05 Sep 2014, Basil Chupin wrote:

So what you are saying is that the old and trusted 'e2fsck' performed on a system by going to level #1 is now no longer a working proposition and that one needs the Rescue DVD/schtik to do this check of the file system? :-) .

Press 'e' on the grub entry, add init=/bin/bash at the end of the "linux" line. You'll end up in a bash. mount -o remount,ro / e2fsck -v -C 0 /dev/sdXY Tested with 13.1 in a vm. Rebooting is a problem though, shutdown, reboot, halt --reboot don't work (because systemd is not running! WHAT A STUPID setup!), exit/ctrl-d, ends in a kernel-panic in the vm. Haven't checked it out more now. HTH, -dnh -- 6.9 is a good thing interupted by a period. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-09-06 07:39, Felix Miata wrote:

On 2014-09-05 20:32 (GMT+0200) David Haller composed:

...

Press 'e' on the grub entry, add

...

init=/bin/bash

...

Tested with 13.1 in a vm. Rebooting is a problem though, shutdown, reboot, halt --reboot don't work (because systemd is not running! WHAT A STUPID setup!), exit/ctrl-d, ends in a kernel-panic in the vm. Haven't checked it out more now.

Fails in same manner on Rawhide, even using fullpath commands, though error from latter is different: "Failed to talk to init daemon". C-A-D doesn't work either. Great thing that systemd. :-(

Hey. If you use "init=/bin/bash" there is no systemd in use. It is completely out of the picture, so don't blame it when it ain't done nothing. You'd have exactly the same problem with systemv, because it is not running. There is just one process running: bash. And of course there is not init daemon, that's bash. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-09-06 13:39, Anton Aylward wrote:

On 09/06/2014 07:14 AM, Carlos E. R. wrote:

+1

The systemd bashing in this thread is completely unjustified.

It is possible, though, to design a script or sequence that halts or powers down the machine, and which can be called when "init=/bin/bash" was used. Calling the system halt program will not work if it tries to call systemd, because it is not running... Telcontar:~ # l /sbin/halt /sbin/poweroff /sbin/shutdown lrwxrwxrwx 1 root root 18 Jun 25 04:00 /sbin/halt -> /usr/bin/systemctl* lrwxrwxrwx 1 root root 18 Jun 25 04:00 /sbin/poweroff -> /usr/bin/systemctl* lrwxrwxrwx 1 root root 18 Jun 25 04:00 /sbin/shutdown -> /usr/bin/systemctl* I think that there is something you can write to some file in proc and powerdown? Instantly, no umount, no nothing. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-09-06 19:42, Cristian Rodríguez wrote:

El 06/09/14 a las #4, Carlos E. R. escribió:

...

I think that there is something you can write to some file in proc and powerdown? Instantly, no umount, no nothing.

That's what sysrq magic keys and /proc/sysrq-trigger are all about.

But those are difficult to remember, and, IIRC, do not work by default because you have to enable those keys. We could instead write up a script of this type of emergency powerdown. Maybe later I can have a look at 11.4 to figure it out. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-09-06 19:57, Cristian Rodríguez wrote:

El 06/09/14 a las #4, Carlos E. R. escribió:

...

On 2014-09-06 19:42, Cristian Rodríguez wrote:

...

...

That's what sysrq magic keys and /proc/sysrq-trigger are all about.

But those are difficult to remember, and, IIRC, do not work by default because you have to enable those keys.

Whatever..if you want to repair the root filesystem..you have to break from the initrd booting with rd.shell or rd.break

They are using "init=/bin/bash". I don't know what rd.shell or rd.break is. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 09/06/2014 12:47 PM, Felix Miata wrote:

On 2014-09-06 13:14 (GMT+0200) Carlos E. R. composed:

...

On 2014-09-06 07:39, Felix Miata wrote:

...

...

On 2014-09-05 20:32 (GMT+0200) David Haller composed:

...

...

...

Press 'e' on the grub entry, add

...

...

...

init=/bin/bash

...

...

...

Tested with 13.1 in a vm. Rebooting is a problem though, shutdown, reboot, halt --reboot don't work (because systemd is not running! WHAT A STUPID setup!), exit/ctrl-d, ends in a kernel-panic in the vm. Haven't checked it out more now.

...

...

Fails in same manner on Rawhide, even using fullpath commands, though error from latter is different: "Failed to talk to init daemon". C-A-D doesn't work either. Great thing that systemd. :-(

...

If you use "init=/bin/bash" there is no systemd in use. It is completely out of the picture, so don't blame it when it ain't done nothing.

You mean besides subsuming everything it can into the monolith that it is, and forcing changes to other things that make them incompatible with sysvinit?

...

You'd have exactly the same problem with systemv, because it is not running. There is just one process running: bash. And of course there is not init daemon, that's bash.

In 11.4 booted with init=/bin/bash on cmdline:

/sbin/reboot reboots the box /sbin/halt -p turns the box off C-A-D reboots the box

None do more than produce error message with Lennart's wonderfully evolved sysvinit replacement on Rawhide. :-(

I think you are missing something here. First, this is a decidedly unnatural situation that has been contrived. You are not starting things with systemd so of course they can't be stopped by systemd. What the old 'halt/reboot' did was essentially pull the carpet of the OS from under the processes. Kaboom! Gone! If you ran though each of the sysvinint "K" series and all that was set up properly, many functions got shut down, but it was still possible to bypass all this. At the end of it, well, you have the 11.4 system, go look at what the final instruction was. You could run that and anyway and Kaboom! Gone! A point of systemd was to get around various problems the sysvinit had with communicating state to various processes. Its there in the design discussions and it clearly explains he problems surrounding the sysvinit style of shutdown and how many things can be left in an indeterminate state. I can't say if a fringe case like this entered into the scope of the design of systemd, but rather than just bemoaning and besmirching systemd, what not ask Lennart?

Interestingly, C-A-D does produce reboot on 13.1, but not on 13.2. :-p

Yes that is interesting. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/09/14 04:32, David Haller wrote:

Hello,

On Fri, 05 Sep 2014, Basil Chupin wrote:

...

So what you are saying is that the old and trusted 'e2fsck' performed on a system by going to level #1 is now no longer a working proposition and that one needs the Rescue DVD/schtik to do this check of the file system? :-) . Press 'e' on the grub entry, add

init=/bin/bash

at the end of the "linux" line. You'll end up in a bash.

mount -o remount,ro / e2fsck -v -C 0 /dev/sdXY

Tested with 13.1 in a vm. Rebooting is a problem though, shutdown, reboot, halt --reboot don't work (because systemd is not running! WHAT A STUPID setup!), exit/ctrl-d, ends in a kernel-panic in the vm. Haven't checked it out more now.

HTH, -dnh

Thanks to all who responded about how to run e2fsck on (my) HDDs. I ran e2fsck by using the 13.1 Rescue DVD. @ David: Using what you suggested above resulted in an error message stating that, "init=/bin/bash is not system, terminate plymouth". @Cristian: Booting with "systemd.unit=rescue.target" simply took me to the normal login screen. Anyway, running e2fsck showed that there were not problems with the file systems. BC -- Using openSUSE 13.1, KDE 4.14.0 & kernel 3.16.2-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-09-12 00:36, David Haller wrote:

Oh. You'll need to disable that then too. There should be a boot parameter for that.

Try "plymouth.enable=0"

I never used bootsplash, much less plymouth.

I remove plymouth from all my systems. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/5/2014 9:09 AM, Carlos E. R. wrote:

On 2014-09-05 13:18, Basil Chupin wrote:

...

On 05/09/14 20:37, Carlos E. R. wrote:

...

On 2014-09-05 12:17, Basil Chupin wrote:

...

I need to check the condition of the file system to determine whether my HDD is failing or it is the ext4 file system is corrupted. I use a rescue usb stick.

Thank you Carlos, but I do not have a 'rescue usb stick' :-) .

Why on earth not!? :-O

After bed and breakfast, that's the next thing you absolutely must have...

But rescue CDs are so much cheaper, and you won't be tempted to use them in a pinch to store pictures of the grand kids on. I keep two different varieties of rescue CDs: 1 under my pillow, and one near my box of cereal. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAlQJ7SkACgkQv7M3G5+2DLJHKQCfTioL5d8V+uBfuQoA+L9wrhja VSkAn1pwLNupwPFWVi2CddXwSRZD/Nfk =djhg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-09-05 23:16 (GMT+0200) Carlos E. R. composed:

...

...

...

Thank you Carlos, but I do not have a 'rescue usb stick' :-) .

...

...

Why on earth not!? :-O

...

...

After bed and breakfast, that's the next thing you absolutely must have...

...

But rescue CDs are so much cheaper, and you won't be tempted to use them in a pinch to store pictures of the grand kids on. I keep two different varieties of rescue CDs: 1 under my pillow, and one near my box of cereal.

LOL, yes, you can't reuse a CD. However, the openSUSE 13.1 rescue image (XFCE) on a USB stick can save files, configs, and you can even install some new packages on it. Ie, you can customize the rescue image, and use it for almost actual work in a pinch :-)

OMs fit in cases that are hard to loose between couch cushions or inside slippers. (nuf said) OMs are big enough to write legibly on them why they exist. (nuf said) OMs work in puters that don't boot USB. (I still have many in use that won't.) OMs are cheap. (no need to decide what stick can be erased to provide home to latest iso) I don't need separate rescue media often, as reduced need is one of the pleasures of multiboot systems, of which virtually all my own are. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/05/2014 07:24 AM, Basil Chupin wrote:

On 05/09/14 20:39, Patrick Shanahan wrote:

...

* Basil Chupin [09-05-14 06:19]:

...

In the past I would boot into oS in Level #1 and then execute, as root, the command-

mount -o remount,ro /dev/sda<x>

followed by

e2fsck dev/sda<x>

However, when I try to do same at the moment I get the 'error' message stating that "sda<x> is BUSY. lsof |grep sda

man lsof lsof --help

Thanks Patrick. Will try this after the backup of part of the system is finished.

But I cannot imagine what file could be running because I simply boot the system into level #1 and therefore do not expect to have any files open.

But then there is global warming.........

BC

No, then there is this: "In the past I would boot into oS in Level #1 and then execute, as root, the command- mount -o remount,ro /dev/sda<x> " Shouldn't fsck be run on an unmounted filesystem? It's been so long I can't remember.-- Ken Schneider -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org