Start-Execute Script with root permissions-Reboot

[piquadrat]

I'm looking for some guidance with the following project:
I want to add ata-password support to my desktop computer as BIOS does not offer this functionality.
It is necessary for my FDE encrypted drive.
As it seems that the security state is preserved during reboot and unlocked drive remains unlocked (until full power down/up cycle of course) I'm thinking about using flash-drive with grub to boot chainloaded windows7 system on encrypted drive or microcore on flash-drive.
If default booting option (win7) fails (drive locked) 'fallback' function boots microcore only for one thing: to enter password for encrypted drive (and sending it to device with 'hdparm' utility), then reboots and grub chainloads win7 on already security unlocked device.

To sum things up:

-I need microcore to auto executed bash script which uses 'hdparm' and 'dialog' for password entering and immediately reboots the computer.

-The script must be executed with root privileges. Required by 'hdparm'

-Ideally the user needs to see no more than password dialog window. No other output. Nothing. Only pass window and next reboot loads Windows system.

Is it feasible with microcore?

[gerald_clark]

Just modify and backup /root/.profile.

[piquadrat]

Thanks for useful tip.
I have one problem with booting messages. When I'm trying to boot microcore with system disk in the lock state (right after powering up the computer) I'm getting this on the screen:

Code: [Select]

Apr 19 11:32:01 (none) user.err kernel: ata5.00: failed command: READ DMA
Apr 19 11:32:01 (none) user.err kernel: ata5.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
Apr 19 11:32:01 (none) user.err kernel:          res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
Apr 19 11:32:01 (none) user.err kernel: ata5.00: status: { DRDY ERR }
Apr 19 11:32:01 (none) user.err kernel: ata5.00: error: { ABRT }
Apr 19 11:32:01 (none) user.info kernel: ata5.00: configured for UDMA/133
Apr 19 11:32:01 (none) user.info kernel: ata5: EH complete
Apr 19 11:32:01 (none) user.err kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 19 11:32:01 (none) user.err kernel: ata5.00: BMDMA stat 0x25
Apr 19 11:32:01 (none) user.err kernel: ata5.00: failed command: READ DMA
Apr 19 11:32:01 (none) user.err kernel: ata5.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
Apr 19 11:32:01 (none) user.err kernel:          res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
Apr 19 11:32:01 (none) user.err kernel: ata5.00: status: { DRDY ERR }
Apr 19 11:32:01 (none) user.err kernel: ata5.00: error: { ABRT }
Apr 19 11:32:01 (none) user.info kernel: ata5.00: configured for UDMA/133
Apr 19 11:32:01 (none) user.info kernel: ata5: EH complete
Apr 19 11:32:01 (none) user.err kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 19 11:32:01 (none) user.err kernel: ata5.00: BMDMA stat 0x25
Apr 19 11:32:01 (none) user.err kernel: ata5.00: failed command: READ DMA
Apr 19 11:32:01 (none) user.err kernel: ata5.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
Apr 19 11:32:01 (none) user.err kernel:          res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
.
(...)
.
Apr 19 11:32:02 (none) user.err kernel: ata5.00: BMDMA stat 0x25
Apr 19 11:32:02 (none) user.err kernel: ata5.00: failed command: READ DMA
Apr 19 11:32:02 (none) user.err kernel: ata5.00: cmd c8/00:08:00:10:00/00:00:00:00:00/e0 tag 0 dma 4096 in
Apr 19 11:32:02 (none) user.err kernel:          res 51/04:08:00:10:00/00:00:00:00:00/e0 Emask 0x1 (device error)
Apr 19 11:32:02 (none) user.err kernel: ata5.00: status: { DRDY ERR }
Apr 19 11:32:02 (none) user.err kernel: ata5.00: error: { ABRT }
Apr 19 11:32:02 (none) user.info kernel: ata5.00: configured for UDMA/133
Apr 19 11:32:02 (none) user.info kernel: sd 4:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
Apr 19 11:32:02 (none) user.info kernel: sd 4:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
Apr 19 11:32:02 (none) user.warn kernel: Descriptor sense data with sense descriptors (in hex):
Apr 19 11:32:02 (none) user.info kernel:         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
Apr 19 11:32:02 (none) user.info kernel:         00 00 10 00
Apr 19 11:32:02 (none) user.info kernel: sd 4:0:0:0: [sda] ASC=0x0 ASCQ=0x0
Apr 19 11:32:02 (none) user.info kernel: sd 4:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 00 00 10 00 00 00 08 00
Apr 19 11:32:02 (none) user.err kernel: end_request: I/O error, dev sda, sector 4096
Apr 19 11:32:02 (none) user.info kernel: ata5: EH complete
Apr 19 11:32:02 (none) daemon.info init: starting pid 599, tty '/dev/tty1': '/sbin/rungetty tty1 --autologin root'
Apr 19 11:32:02 (none) auth.info login[599]: root login on 'tty1'
Apr 19 11:32:02 (none) local2.notice sudo:       tc : TTY=tty1 ; PWD=/home/tc ; USER=root ; COMMAND=/usr/bin/tee /etc/sysconfig/backup
Apr 19 11:44:10 (none) local2.notice sudo:       tc : TTY=tty1 ; PWD=/var/log ; USER=root ; COMMAND=/bin/sh

There are about five thousand lines where system is trying persistently to get to the drive which is obviously not possible as the drive is in the locked state at that moment and responding only to a very limited set of ATA commands.
How to prevent kernel (maybe it is one particular module I can switch off) from displaying these messages?
It takes about 20 seconds. 20 seconds wasted, added unnecessarily to boot time which I'm trying to reduce as far as possible.

[curaga]

Hm, you'd need to use "tce=sdaX restore=sdaX" if that's from TC's scan.

If it's from the kernel's scans, see kernel-parameters.txt.

[piquadrat]

If I set (sdb1 - is my usb TC install partition):
tce=sdb1 restore=sdb1
nothing changes.
If I change the console output with: 'console=tty12' parameter I can silence typical system msgs during boot and shutdown but not those 5 thousand error lines. They appear nevertheless.
Switching off error logging with: 'loglevel=0' stops them from displaying but...
there is still around 20 seconds pause during the boot process.
If my non-linux system drive (sda) is unlocked booting microcore takes about 4-5 seconds but if it is locked (cold start) that time rises to 30 seconds.
Now my grub entry looks like:

Code: [Select]

kernel /boot/bzImage quiet loglevel=0 console=tty12 tce=sdb1 restore=sdb1 waitusb=5
I'd really appreciate any suggestions. Any way to short that 20 seconds pause?

[tinypoodle]

There are 2 approaches, either at runtime (boot), or at compile time (kernel config).

For first see Reply #3 and experiment with all related parameters, for second check kernel configuration options.

[piquadrat]

I'm fighting with this thing for last few days but gain absolutely nothing.
Those several thousand lines of errors are filling the dmesg buffer completely along with log files in /var/log. I simply cannot even provide boot messages history prior to those errors to investigate what exactly is causing that. Early boot msgs are kicked out from logs completely.
Complete mess.
I can suspect that those errors starting somewhere between these lines:

Code: [Select]

Apr 25 01:11:11 (none) user.info kernel: forcedeth 0000:00:0a.0: ifname eth0, PHY OUI 0x3f1 @ 1, addr 00:01:29:d4:3a:86
Apr 25 01:11:11 (none) user.info kernel: forcedeth 0000:00:0a.0: highdma csum gbit lnktim desc-v3
Apr 25 01:11:11 (none) user.notice kernel: scsi 6:0:0:0: Direct-Access     PIXIKA   USB Flash Drive  5.00 PQ: 0 ANSI: 2
Apr 25 01:11:11 (none) user.notice kernel: sd 6:0:0:0: Attached scsi generic sg1 type 0
Apr 25 01:11:11 (none) user.notice kernel: sd 6:0:0:0: [sdb] 999424 512-byte logical blocks: (511 MB/488 MiB)
Apr 25 01:11:11 (none) user.notice kernel: sd 6:0:0:0: [sdb] Write Protect is off
Apr 25 01:11:11 (none) user.debug kernel: sd 6:0:0:0: [sdb] Mode Sense: 0b 00 00 08
Apr 25 01:11:11 (none) user.err kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through
Apr 25 01:11:11 (none) user.err kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through
Apr 25 01:11:11 (none) user.info kernel:  sdb: sdb1
Apr 25 01:11:11 (none) user.err kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through
Apr 25 01:11:11 (none) user.notice kernel: sd 6:0:0:0: [sdb] Attached SCSI removable disk
Apr 25 01:11:11 (none) user.info kernel: loop: module loaded
Apr 25 01:11:11 (none) user.info kernel: ramzswap: num_devices not specified. Using default: 1
Apr 25 01:11:11 (none) user.info kernel: ramzswap: disk size not provided. You can use disksize_kb module param to specify size.
Apr 25 01:11:11 (none) user.info kernel: Using default: (25% of RAM).
Apr 25 01:11:11 (none) user.info kernel: ramzswap: /dev/ramzswap0 initialized: disksize_kb=518448
Apr 25 01:11:11 (none) user.info kernel: Adding 518440k swap on /dev/ramzswap0.  Priority:-1 extents:1 across:518440k SS
Apr 25 01:11:11 (none) user.info kernel: squashfs: version 4.0 (2009/01/31) Phillip Lougher
Apr 25 01:11:11 (none) local2.notice sudo:     root : TTY=console (deleted) ; PWD=/ ; USER=root ; COMMAND=/bin/busybox tar -C / -zxf /mnt/sdb1//mydata.tgz
Apr 25 01:11:11 (none) user.notice kernel: scsi 7:0:0:0: Direct-Access     Brother  DCP-357C         1.00 PQ: 0 ANSI: 2
Apr 25 01:11:11 (none) user.notice kernel: sd 7:0:0:0: Attached scsi generic sg2 type 0
                                                                                <---- probably the errors start here
Apr 25 01:11:11 (none) daemon.info init: starting pid 502, tty '/dev/tty1': '/sbin/rungetty tty1 --autologin root'
Apr 25 01:11:11 (none) auth.info login[502]: root login on 'tty1'
Apr 25 01:11:11 (none) user.notice kernel: sd 7:0:0:0: [sdc] Attached SCSI removable disk
Apr 25 01:11:11 (none) local2.notice sudo:       tc : TTY=tty1 ; PWD=/home/tc ; USER=root ; COMMAND=/usr/bin/tee /etc/sysconfig/backup
Apr 25 01:34:57 (none) local2.notice sudo:       tc : TTY=tty1 ; PWD=/home/tc ; USER=root ; COMMAND=/bin/sh


This is a part of the log when the drive is unlocked so boot process is not interrupted.
Note that there is no mention about sda in it. That's strange because sda causing all the trouble and I'm sure of that.
I tried to add bootcode to switch off ide probing but sda=noprobe and hda=noprobe changed nothing.

Now I'm stuck and close to giving this thing up.

Half a minute is simply too long and it is completely wasted.
With or without those errors the drive is still accessible through disk utilities like hdparm.
Why is kernel trying to get access to the drive for so long. One, two tries but almost thousand?
And I am still do not know what exactly is it trying to do with the drive. Without that info I cannot even start to prevent it from doing that.

Any ideas?

[Rich]

Hi piquadrat
Try ide-core.noprobe=0.0 for hda, 0.1 for hdb, 1.0 for hdc, 1.1 for hdd.

     [EDIT]: Corrected syntax from   ide_core   to   ide-core

[piquadrat]

It seems that libata's error handler (EH) is producing these errors.
The bad news is that neither ide_core.noprobe= nor hdX/sdX=noprobe won't work as they were used in older IDE driver and now are ignored.
I can't find a way to prevent libata from probing the drive (sda) during boot. noscsi bootcode is not implemented in tiny/microcore.
But I think that there should be a way. Omitting device probe is sometimes useful.
The drive scan (when it is unlocked) during boot producing the following:

Code: [Select]

pr 25 01:11:11 (none) user.info kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Apr 25 01:11:11 (none) user.info kernel: ata5.00: ATA-8: INTEL SSDSA2CW080G3, 4PC10302, max UDMA/133
Apr 25 01:11:11 (none) user.info kernel: ata5.00: 156301488 sectors, multi 16: LBA48 NCQ (depth 0/32)
Apr 25 01:11:11 (none) user.info kernel: ata5.00: configured for UDMA/133
Apr 25 01:11:11 (none) user.info kernel: usb 1-5: new high speed USB device using ehci_hcd and address 4
Apr 25 01:11:11 (none) user.info kernel: ata4: SATA link down (SStatus 0 SControl 300)
Apr 25 01:11:11 (none) user.notice kernel: scsi 4:0:0:0: Direct-Access     ATA      INTEL SSDSA2CW08 4PC1 PQ: 0 ANSI: 5
Apr 25 01:11:11 (none) user.notice kernel: sd 4:0:0:0: Attached scsi generic sg0 type 0
Apr 25 01:11:11 (none) user.notice kernel: sd 4:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
Apr 25 01:11:11 (none) user.notice kernel: sd 4:0:0:0: [sda] Write Protect is off
Apr 25 01:11:11 (none) user.debug kernel: sd 4:0:0:0: [sda] Mode Sense: 00 3a 00 00
Apr 25 01:11:11 (none) user.notice kernel: sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Apr 25 01:11:11 (none) user.info kernel:  sda: sda1
Apr 25 01:11:11 (none) user.notice kernel: sd 4:0:0:0: [sda] Attached SCSI diskand I think this is the place where exceptions starting when disk is in ATA-lock state.
Maybe there is a way to set the probe timer? Now it is set around 30 seconds.
But how?

[Rich]

Hi piquadrat
Re-reading your second post you say that in the locked state it responds to a very limited set of ATA
commands. I also see you are getting a lot of DMA errors. So try libata.dma=0 and see if anything
changes.
From what I could find there is no way to prevent libata from probing the drive.
Just to be clear, if you boot into Microcore with the drive unlocked, does it do the same thing?

[tinypoodle]

If it's that important you could try and see what happens if you recompile the kernel, changing current

Code: [Select]

CONFIG_ATA_VERBOSE_ERROR=y

[piquadrat]

Hi piquadrat
Re-reading your second post you say that in the locked state it responds to a very limited set of ATA
commands. I also see you are getting a lot of DMA errors. So try libata.dma=0 and see if anything
changes.
From what I could find there is no way to prevent libata from probing the drive.
Just to be clear, if you boot into Microcore with the drive unlocked, does it do the same thing?

If the drive is unlocked none of the DMA errors are present. Log looks ok, boot is fast. The code placed in my previous message comes exactly from booting in such 'normal' conditions. As you can see, the drive is recognized as Intel SSDSA2CW08 with id: ata5.00. If the drive is locked all logs are filled with exceptions and I can't even tell when exactly during boot process they started but I assume that right there because the only thing that changed was that Intel ssd disk's security status.

If it's that important you could try and see what happens if you recompile the kernel, changing current

Code: [Select]

CONFIG_ATA_VERBOSE_ERROR=y

I could try but I'm affraid it would not help. I can silence those errors even right now with 'loglevel=0' bootcode but that 25-30seconds probe pause remains. At least after some time ata driver stops for querying drive so I suspect that there is some kind of timer used during the probing. But can I set it somewhere?

I've found some scsi related bootcodes (at least my intel ssd drive seems to be categorized as scsi):
scsi_mod.scan=none / async / sync
but it seems they are not implemented in tiny/microcore according to the documentation. Will try them anyway.

[Rich]

Hi piquadrat
Does the boot code  libata.dma=0  help any with the drive locked?

[piquadrat]

Adding boot code libata.dma=0 results in this:

Code: [Select]

Apr 25 23:36:41 (none) user.info kernel: ata5: EH complete
Apr 25 23:36:41 (none) user.err kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 25 23:36:41 (none) user.err kernel: ata5.00: failed command: READ MULTIPLE
Apr 25 23:36:41 (none) user.err kernel: ata5.00: cmd c4/00:08:38:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
Apr 25 23:36:41 (none) user.err kernel:          res 51/04:08:38:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
Apr 25 23:36:41 (none) user.err kernel: ata5.00: status: { DRDY ERR }
Apr 25 23:36:41 (none) user.err kernel: ata5.00: error: { ABRT }
Apr 25 23:36:41 (none) user.info kernel: ata5.00: configured for PIO4
Apr 25 23:36:41 (none) user.info kernel: ata5: EH complete
Apr 25 23:36:41 (none) user.err kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 25 23:36:41 (none) user.err kernel: ata5.00: failed command: READ MULTIPLE
Apr 25 23:36:41 (none) user.err kernel: ata5.00: cmd c4/00:08:38:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
Apr 25 23:36:41 (none) user.err kernel:          res 51/04:08:38:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
Apr 25 23:36:41 (none) user.err kernel: ata5.00: status: { DRDY ERR }
Apr 25 23:36:41 (none) user.err kernel: ata5.00: error: { ABRT }
Apr 25 23:36:41 (none) user.info kernel: ata5.00: configured for PIO4
Apr 25 23:36:41 (none) user.info kernel: ata5: EH complete
Apr 25 23:36:41 (none) user.err kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 25 23:36:41 (none) user.err kernel: ata5.00: failed command: READ MULTIPLE
Apr 25 23:36:41 (none) user.err kernel: ata5.00: cmd c4/00:08:38:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
Apr 25 23:36:41 (none) user.err kernel:          res 51/04:08:38:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
Apr 25 23:36:41 (none) user.err kernel: ata5.00: status: { DRDY ERR }
Apr 25 23:36:41 (none) user.err kernel: ata5.00: error: { ABRT }
Apr 25 23:36:41 (none) user.info kernel: ata5.00: configured for PIO4
Apr 25 23:36:41 (none) user.info kernel: ata5: EH complete
Apr 25 23:36:41 (none) user.err kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 25 23:36:41 (none) user.err kernel: ata5.00: failed command: READ MULTIPLE
Apr 25 23:36:41 (none) user.err kernel: ata5.00: cmd c4/00:08:38:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
Apr 25 23:36:41 (none) user.err kernel:          res 51/04:08:38:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
Apr 25 23:36:41 (none) user.err kernel: ata5.00: status: { DRDY ERR }
Apr 25 23:36:41 (none) user.err kernel: ata5.00: error: { ABRT }
Apr 25 23:36:41 (none) user.info kernel: ata5.00: configured for PIO4
Apr 25 23:36:41 (none) user.info kernel: ata5: EH complete
Apr 25 23:36:41 (none) user.err kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 25 23:36:41 (none) user.err kernel: ata5.00: failed command: READ MULTIPLE
Apr 25 23:36:41 (none) user.err kernel: ata5.00: cmd c4/00:08:38:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
Apr 25 23:36:41 (none) user.err kernel:          res 51/04:08:38:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
Apr 25 23:36:41 (none) user.err kernel: ata5.00: status: { DRDY ERR }
Apr 25 23:36:41 (none) user.err kernel: ata5.00: error: { ABRT }As you can see the same happens, only the protocol has changed, disk is in Pio4 mode now.
I am able to stop all scsi discovery procedure during bootup with scsi_mod.scan=none parameter but that ends with no mounting points present and I cannot refer to disk drive with /dev/sda so cannot use hdparm to unlock it. I'm suspect that one can do manual scsi discovery and get /dev/name for device connected to ata controller but I don't know how to do it. At least at the moment.
What really bugs me is that I have found module parameters which should be usefull.
libata - has 'ata_probe_timeout' parameter
scsi_mod - has 'inq_timeout' and 'scsi_logging_level'
The thing is when I use them as boot parameters in constructions such as:

Code: [Select]

scsi_mod.scsi_logging_level=0
scsi_mod.inq_timeout=1 (or 0)
libata.ata_probe_timeout=1 (or 0)nothing changed. Nothing. It looks like kernel ignores them completely. Especially scsi_logging_level is a big disappointment. I could swear that this is exactly it. scsi_logging_level has a very tricky way to set a value but 0 should mean no logging at all (during scan also).
I'm beginning to belive that scsi scan alone is not a cause of the problem. If i issue:

Code: [Select]

fdisk -l dmesg is filled again with errors exactly the same as during boot but the thing is: the output is almost instants (no 25 second pause). Something else is trying to get access to the drive during boot, something else issuing  fdisk-like command not one time but repeatedly for 25 seconds. Or I'm wrong completely.

[Rich]

Hi piquadrat
If you think some of the scsi parameters may help try

scsi_logging_level=0
scsi_mod.scan=none  or  scsi_mod.scan=async