please disable any automated I/O WRITES to a foreign system

[costinel]

the reason would be:

1. avoid supplemental possibly unwanted specific actions (ex. md automatic rebuilding)
2. possible configuration errors present on system
3. shorter boot time

i know i can disable them at boottime manually passing supplemental options, but i believe is in the interest of everyone for these to be disabled BY DEFAULT. after all, he who uses system rescue cd already knows what to do and how to manually modprobe and init subsystems.

[admin]

In general all the linux distributions want to enable these sort of things in the initramfs. If we don't when most users will complain because they can't see their raid disk for instance. Most users probably don't know all these tools I think.

I think it's better to take a specific action when we want to avoid md automatic rebuilding. This is just my opinion, I understand why you prefer having that disabled by default. I just think it's not the best option for most users.

[costinel]

IMHO a system rescue cd should try to avoid at maximum to WRITE any bit of data to a foreign system.
normally when you load the md module, if it finds a desync-ed array it starts to resync, which means WRITING data.

most of the time you really don't want to have the system perform automated write operations without user consent, especially in the case when you boot with sysrcd to inspect a DAMAGED system.

I hope my point is clearer now. at least that's what i use sysrcd for.
if i wanted a portable linux system, i'd go for something *-live, no to sysrcd.

users wanting automagic WRITE stuff are probably not part of the userbase of sysrcd

[costinel]

hi
can you at least switch to md_mod.start_ro=1 as default?
quoting from:
https://wiki.archlinux.org/index.php/RA ... _read-only

"When an md array is started, the superblock will be written, and resync may begin. To start read-only set the kernel module md_mod parameter start_ro. When this is set, new arrays get an 'auto-ro' mode, which disables all internal io (superblock updates, resync, recovery) and is automatically switched to 'rw' when the first write request arrives."

I'd also like to hear your reply to my previous post which seems to have passed without getting your attention.

[costinel]

up

[admin]

I understand your point but I still think it is best to keep the current behaviour by default.
If you make a patch that implements an option to change the behaviour I will look at it.

[Linuxuser]

I support it and i think indeet it should not do anything on the main disk automatical.

So why not use menu of scripts that the user can start manually after he booted which would perform any extra action?

[sciurus]

Costinel, you may be interested in GRML, it does not activate RAID or LVM by default. From their FAQ:

Where are my LVM devices?

LVM (Logival Volumes) is not started by default to avoid any possible damage to your data. To get access to present LVM devices just execute:

# /etc/init.d/lvm2 start

If you want to enable LVM by default just boot using the 'lvm' bootoption which automatically enables LVM.
Where are my Software-RAID devices?

Software-RAID (usually known as the mdadm stuff) is not started by default to avoid any possible damage to your data. To get access to present SW-RAID devices just execute:

# /etc/init.d/mdadm-raid start

If you want to enable SW-RAID by default just boot using the 'swraid' bootoption which enables automatic assembling of software raid arrays.

[kerframil]

The OP has a point. There's a certain degree of automation and magic where it starts to become counter-productive in view of what the user of a live distro intended for rescue and recovery is actually trying to achieve.

Regarding RAID arrays, they really should not be automatically assembled. To do so runs a definite risk of complicating rescue and recovery scenarios and, in some situations, making things worse. This is not a hypothetical statement. I don't want to document the scenario that I recently went through here, suffice to say that I have practical experience of the problems that it can cause.

Aside from my problems, I have seen it cause a problem for other Linux users on no less than three occasions while hanging out in just one channel on IRC. Specifically, if a 0.90 superblock array is automatically assembled, it can wreck the preferred super-minor field, subsequently causing boot problems. It causes significant stress and confusion for users who understand neither the cause nor the solution.

The real offender is udev, specifically "/lib/udev/rules.d/64-md-raid.rules" which implements incremental assembly. This has previously been raised as a complaint in Gentoo as bug 401707. Putting aside the fact that the person who filed the bug argued his point in an abrasive manner, I believe that the idea to be able to control the installation of the rules could have been useful. In any case, Gentoo could not accept the idea because they have a policy of not allowing USE flags to control optional config files.

To the maintainer of SystemRescueCd, I would strongly advise to include an empty file as "/etc/udev/rules.d/64-md-raid.rules" as part of its environment. This would be quite sufficient to prevent udev from being unnecessarily 'helpful' while not being as drastic as forcing a read-only mode for the md subsystem. That set, being able to set "md_mod.start_ro=1" would be a useful option to have in some situations.

[costinel]

dear maintainer of sysrcd, if you are so :-) to busy to modify defaults or add option PLEASE AT LEAST add a text entry in the F1-F7 boot screen mentioning md_mod.start_ro=1 and this thread

Mod edit :-) last warning....