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.
please disable any automated I/O WRITES to a foreign system
please disable any automated I/O WRITES to a foreign system
Last edited by costinel on 08 Aug 2012, 07:47, edited 1 time in total.
Re: disable lvm, md and dmraid at boot, let me start manually
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.
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.
Re: disable lvm, md and dmraid at boot, let me start manuall
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
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
Re: disable lvm, md and dmraid at boot, let me start manuall
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.
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.
Re: please disable any automated I/O WRITES to a foreign sys
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.
If you make a patch that implements an option to change the behaviour I will look at it.
Re: please disable any automated I/O WRITES to a foreign sys
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?
So why not use menu of scripts that the user can start manually after he booted which would perform any extra action?
Re: please disable any automated I/O WRITES to a foreign sys
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.
Re: please disable any automated I/O WRITES to a foreign sys
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.
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.
Re: please disable any automated I/O WRITES to a foreign sys
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....
Mod edit :-) last warning....
Who is online
Users browsing this forum: No registered users and 2 guests